text:
Opened 6 years ago
Last modified 6 days ago
#12706 assigned task (blessed)
Custom post status bugs in the admin
|Reported by:
|Owned by:
|Future Release
|Posts, Post Types
|has-patch westi-likes needs-testing needs-unit-tests editorial-flow
Description (last modified by nacin)
A developer should be able to register a custom post status using register_post_status(). The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API.
All existing arguments to register_post_status() should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.
Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status).
Attachments (12)
Change History (233)
6 years ago
Related: #12567
6 years ago
- Cc sbressler@… added
6 years ago
- Milestone changed from 3.0 to 3.1
- Severity changed from blocker to normal
Don't have time for this so I'm pushing it back for 3.1 unless someone can tackle it :)
6 years ago
- Type changed from defect (bug) to enhancement
I don't see this as a bug. We simply never completed the API here.
Very similar to how we started custom post types in 2.9 then went through it with 3.1.
Moving to enhancement... Will probably end up as a task though.
6 years ago
- Cc johnkolbert added
Related and in progress: http://core.trac.wordpress.org/ticket/12567
6 years ago
Just to let those know who are following this ticket, I just updated the diff file to this related trac ticket (http://core.trac.wordpress.org/ticket/12567) and would enjoy any feed back.
6 years ago
- Cc johnbillion@… added
6 years ago
- Milestone changed from Awaiting Triage to 3.1
- Type changed from enhancement to task (blessed)
Someone is free to start working on this before I get to it.
I want post statuses to be registered to a post type. That's one thing that gets me.
We also have like 18 properties but still need more based on things I noticed when trying to utilize what was there. So we should figure out a way to properly handle everything.
6 years ago
- Cc mikeschinkel@… added
6 years ago
- Cc andreasnrb added
Think we need to do a write up of what the different options actually do.
Supposed difference between public, private, protected. _builtin and internal etc.
Public,private,protected makes custom post type with that status show up on its listings page.
The All(x) link always show the total count for the post type even with a unregistered post_status but the page display No post types found.
6 years ago
- Cc piemanek@… added
6 years ago
Alright, let's get this ticket moving. There's a few args in the current version of register_post_status that either make no sense, are redundant, or ones that I just don't understand and could use some clarification.
Here's the new params for the register function:
register_post_status( $post_status, $post_type, $args = array() );
- $post_status (string) - Name of the post status.
- $post_type (mixed) - string or array of post types to assign to the post status.
- $args (array) - Optional.
Public args:
- label - A descriptive name for the post status. Defaults to $post_status
- label_count - Label used in the admin status links to display the post status' singular/plural count label. Defaults to label
- post_type - An array containing post types this post status is associated with. Defaults to 'any'.
- exclude_from_search - Whether to exclude posts with this post status from search results. Defaults to null.
- public - Whether posts of this type should be shown in the admin UI. Defaults to null.
- internal - Whether the post status is internal. Removes from any ui/query listing.
- protected - User must have edit permissions on the draft to preview. Defaults to null.
- private - Limited to viewing by the author of a post or someone who has caps to read private states. Defaults to null.
- publicly_queryable - Whether post status queries can be performed from the front page. Defaults to null.
- show_ui - Whether to show the post status in the admin UI. Defaults to null.
- edit_cap: changing the post status can be limited by capability. If set, users must have the declared capability to change change posts to this post status. Defaults to null.
Internal args: (Used by WP core built-in post statuses)
- _builtin - If this post status is a native or "built-in".
Args I left out: (can anyone explain the need for these?)
- show_in_admin_all
- show_in_admin_status_list
- show_in_admin_all_list (uses show_ui instead)
- single_view_cap
- capability_type
- hierarchical
- _edit_link
Functions that (most likely) need updates:
- get_available_post_statuses
- wp_edit_posts_query
- get_post_statuses
- get_page_statuses
- post_submit_meta_box
Files that need updates
- edit.php:261
- export.php:55,:132 (do we need a can_export arg?)
- query.php:2234
- script-loader.php & post.dev.js
See #12567
6 years ago
There shouldn't be a separate function for page statuses. Pages are now just another post type other than WordPress needs to support features from when they were distinct.
The post type already has a can_export flag. The post status should depend on the post type flag for this. Though, this raises the issue of conditionally showing the post status on the export screen when it only applies to specific post types.
6 years ago
get_page_statuses() is for back compat. I think get_page_statuses() and get_post_statuses() are only used in XML-RPC. They have hard-coded stati for that reason.
↓ 19
6 years ago
Can we please default post_type to null? This is the standard approach for everything except the query variable, making
! empty ($status_obj->post_type)
sufficient to detect post_type customization in 3.0 and 3.1+
in reply to:
↑ 18
↓ 20
6 years ago
Replying to kevinB:
Can we please default post_type to null? This is the standard approach for everything except the query variable, making
! empty ($status_obj->post_type)
sufficient to detect post_type customization in 3.0 and 3.1+
The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.
in reply to:
↑ 19
↓ 21
6 years ago
Replying to ptahdunbar:
Replying to kevinB:
Can we please default post_type to null? This is the standard approach for everything except the query variable, making
! empty ($status_obj->post_type)
sufficient to detect post_type customization in 3.0 and 3.1+
The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.
That breaks the API for plugins and themes which were written for WP 3.0. Why not make post_type part of the args array? Then calling code can associate the status with all post types if the property is defaulted null or not set.
in reply to:
↑ 20
6 years ago
Replying to kevinB:
Replying to ptahdunbar:
The post_type param is required as your registering a post status to a post type. Defaulting to null means that the post status shouldn't register.
That breaks the API for plugins and themes which were written for WP 3.0. Why not make post_type part of the args array? Then calling code can associate the status with all post types if the property is defaulted null or not set.
By calling code, I mean consumers of the resulting status object.
6 years ago
plugin to demonstrate custom stati "Approved" and "Secret". Corresponding roles of "Reviewer" and "Super Editor"
6 years ago
Just uploaded a patch for the first issue. This is mostly comprehensive, supporting use of the following type of stati:
- private type, indicated by $status_obj->private. Some functionality as normal private, but a separate set of capability requirements which may include all or some of the following: "read_secret_posts", "edit_secret_posts", "delete_secret_posts", "set_secret_posts" (the "publish" equivalent). If a status-specific caps is not defined for some operation, the normal private status equivalent is used.
- pending type, indicated by $status_obj->moderation. Enables additional multi-step moderation, optionally with status-specific capabilities. A new filter is applied to allow plugins to customize the default moderation status for the main Submit button:
$moderation_status = apply_filters( 'post_moderation_status', 'pending', $post->ID );
Remaining Issues:
- I didn't touch xml-rpc or map_meta_cap (but see meta mapping in attached plugin for ideas)
- Custom public stati now have some backend support but no Edit Form UI integration. The complication-to-benefit ratio seems much higher here; at this point I'm not eager to push it.
- The js I moved into edit-form-advanced.php should be reviewed for optimal delivery method.
- I don't know the WP way to compress js files. post.js and inline-edit-post.js in this patch are a copy of uncompressed dev.js
Demo Plugin:
I also attached a plugin to demonstrate two custom stati via the following roles:
- "Reviewer" - has edit_approved, delete_approved, set_approved, edit_others, delete_others for all post types
- "Super Editor" (name='super') - has read_secret, edit_secret, delete_secret, set_secret for all post types (in addition to regular editor caps)
The WP roles definitions will be added to your DB, but db-stored capabilities are only that of Contributor and Editor, respectively.
6 years ago
For the second issue (statuses should be registered to one or more post types), I suggest following the pattern set for taxonomies:
function register_taxonomy_for_object_type( $taxonomy, $object_type) { global $wp_taxonomies; if ( !isset($wp_taxonomies[$taxonomy]) ) return false; if ( ! get_post_type_object($object_type) ) return false; $wp_taxonomies[$taxonomy]->object_type[] = $object_type; return true; }
I would be able to implement that type of solution early next week if nobody else has it done by then.
6 years ago
Hi kevinB, for compressed scripts, only edit the .dev.js versions, and omit the compressed versions. We will then handle compression on commit.
I've asked Ptah to review this patch as I know he is also working on a patch, so let's see what we can grab from each to continue.
↓ 27
6 years ago
I'm thinking we should group the arguments into patches instead of writing up one big diff.
register_post_status() needs a labels arg for all of these:
- name
- count
- caption
- published (maybe a better wording?)
- save_as (maybe a better wording?)
For the post_type arg, we need to be loop through the post_type arg and register_post_status_for_type()
- post_type
There also needs to be a new post_status arg in register_post_type() that calls register_post_status_for_type(). If the post_status arg isn't passed, it registers all the builtin post statuses to that post type.
We'll need a post_type_has_status() (similar to what johnkolbert wrote in #12567) and use that throughout post_submit_meta_box() to turn features on/off.
I'm not exactly 100% sure on how public, private, and protected work in terms of what functionality they add outside of what's in the post_submit_meta_box() metabox.
- public
- private
- protected
- internal
And finally post status capability. Can anyone elaborate how this should work?
in reply to:
↑ 26
↓ 28
6 years ago
Replying to ptahdunbar:
I'm not exactly 100% sure on how public, private, and protected work in terms of what functionality they add outside of what's in the post_submit_meta_box() metabox.
- public
- private
- protected
- internal
public stati are published and readable by default to all logged and anonyomous users (an abstraction of the "publish" status).
private stati are published but readable based on possession of the appropriate capability (an abstraction of the "private" status).
protected means a status is not currently readable to any user on the front end, except for previews.
internal means never readable on the front end, post are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)
My patch includes another proposed status type:
moderation means a status is part of an editorial moderation process. Not readable on the front end, except for previews (an abstraction of the "pending" status).
And finally post status capability. Can anyone elaborate how this should work?
If the existing pattern is followed, capabilities for custom stati would be specified by setting
$type_object->cap->edit_{$status}_posts = ... $type_object->cap->delete_{$status}_posts = ...
... and if the status is of private type:
$type_object->cap->read_{$status}_posts = ...
In addition, there is a need for a "publish" capability specific to custom public, private and moderation stati:
$type_object->cap->set_{$status}_posts = ...
If there is sentiment for a different model such that $type_obj->status_cap is a status-keyed array property, now is the time. Thoughts?
in reply to:
↑ 27
6 years ago
Replying to kevinB:
protected means a status is not currently readable to any user on the front end, except for previews.
internal means never readable on the front end, post are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)
protected means not readable to any user on the front end, except for previews.
internal means not readable on the front end, posts are not set to it by "normal" wp-admin UI, and is not included in wp-admin post filtering unless specified (show_in_admin_status_list)
6 years ago
The updated patch also fixes some core bugs which may deserve their own ticket. I included them as part of this patch because my overall custom stati solution depends on the fix, or vice versa:
- wp_list_filter() : 'or' argument does not work, always returns all members. This function is called by get_post_stati(), get_post_types() and get_taxonomies()
- Users lacking publish capability can change an existing post of any status to Privately Published status via Quick Edit
- On visibility or publish date change, js recaptions publish button as "Update Post" or "Update Page" (versus initial caption of "Update")
6 years ago
A few other anomalies I noticed:
1) Contributors can "edit" their own privately published posts, but saving throws it Pending Review status. I'm guessing this is not intended, and can address it as part of #14122 unless someone objects.
2) Contributors can save a post password to a Pending Post via Quick Edit, but not via the full edit form. The post remains in Pending Review status but retains the password if it is published. What is the intended behavior?
3) Setting the post date to future recaptions the publish button to "Schedule" if visibility is set public. But for private visibility, it retains the "Update" caption. Wouldn't it be better to show "Schedule" regardless of visibility - as a visual cue that the privately published post is about to be unpublished until the selected date?
6 years ago
I've scrutinized the patch quite extensively and believe it to be cleanly coded, logically consistent and functionally correct. If ptah, nacin and others have just not had time to look at it, no problem. But I'd like to know if you're seeing issues with it.
What else should I do to bring it toward commit eligibility? I know it seems like a big diff, but the changes all fit together toward the goal of custom stati in the post submit UI and a backend that makes those selections a reality.
#14122 would be easier to address if I knew whether my $status_obj->moderation property and status caps approach will fly.
I can explain the reasons for each change file by file, or further describe motivations and use cases. Would either of those be helpful?
6 years ago
plugin to demonstrate custom stati "Approved" and "Secret". Corresponding roles of "Reviewer" and "Super Editor". v 1.1 adds registration of custom public status "Alternate" for post type and custom private status "Confidential" for page type.
6 years ago
Just updated the patch and demo plugin to:
- support type-specific status registration
- fully support custom public stati in the post edit UI, Edit Posts listing and everywhere else
- support scheduled publishing to any public or private status. Previously, selection of private visibility forced post to be published immediately despite selection (and storage) of future date
Type-specific stati (governed by $status_obj->object_type array) can be registered in two ways:
- register_post_status now supports object_type in $args array; registers the status to all object types by default
- register_status_for_object_type( $post_status, $object_type ) - Add an already registered post status to an object type
Enforcement is via
// $post_type may be an individual value or an array $private_stati = get_post_stati( array( 'object_type' => $post_type, 'private' => true ) );
To make that work, I had to modify function wp_list_filter to support the array value intersection:
function wp_list_filter( $list, $args = array(), $operator = 'and' ) { if ( empty( $args ) ) return $list; $count = count( $args ); $filtered = array(); foreach ( $list as $key => $obj ) { $matched = array_intersect_assoc( (array) $obj, $args ); foreach( array_keys( $matched ) as $_key ) { if ( is_array( $args[$_key] ) ) { if ( ! array_intersect( $args[$_key], $matched[$_key] ) ) unset( $matched[$_key] ); } } $num_matched = count( $matched ); if ( ( 'and' == $operator && $num_matched == $count ) || ( 'or' == $operator && $num_matched ) ) { $filtered[$key] = $obj; } } return $filtered; }
get_post_stati() and get_taxonomies() cast object_type argument to array to ensure the special treatment.
Please let me know what needs further explanation.
6 years ago
comprehensive support for custom stati (public, private and moderation). RevC tightens code, fixes patch js bugs and a few core bugs (see comments). RevD registers and enforces type-specific stati, fleshes out custom public stati, allows scheduling to any public or private status. RevE is a 1-liner to include all readable stati in Recent Posts widget. RevF (15 Oct) fixes patch bugs related to sticky posts; supports custom public stati for sticky posts, term count, comment feed, archives, find posts, nav menu metabox & display
6 years ago
Updated patch fixes patch bugs related to sticky posts, defaults recent posts query to public stati only, and adds custom public stati support for:
- sticky posts
- term count
- comment feed
- archives
- find posts
- nav menu metaboxes and display
Also adds filters to support adjustment of those included stati:
- 'posts_sticky_stati'
- 'term_count_stati'
- 'comment_feed_stati'
- 'getarchives_stati'
- 'find_posts_stati'
- 'nav_menu_stati'
Also adds filters for default stati in the posts query (to support plugins dealing with content permissions):
- 'posts_public_stati'
- 'posts_private_stati'
in reply to:
↑ description
6 years ago
Replying to ptahdunbar:
Registering a post status via register_post_status() doesn't show the new status anywhere in the admin. [...] Post statuses should be registered to one or more post types.
Got a BIG +1 from me, interesting stuff happening though!
6 years ago
- Keywords has-patch dev-feedback added; needs-patch removed
There are just a few days left before freeze, so asking committers to take a look and see if it can be finished off for 3.1 or not.
6 years ago
- Keywords dev-feedback removed
- Milestone changed from 3.1 to Future Release
- Type changed from task (blessed) to feature request
This is a huge undertaking, but I don't think we should rush this into 3.1. This looks like a great starting point. I'll support it as a task for 3.2 and I would be willing to work through it once we branch.
6 years ago
- Cc ninnypants added
↓ 47
5 years ago
One thing I should note, there should be an argument to hide a post status and an argument to limit what post types it can be used with, especially now that we have custom post types, maybe I want a status just for my custom post type. Or maybe I want a staus that can manually be selected it must be added by my plugin for whatever reason.
Just my 2 cents.
5 years ago
what is the status of this ticket? as in, any idea when it will be completed and implemented? i'm writing a plugin for a client that allows the author of the post to set an expiration date, so i've created a post status called "expire" using register_post_status, and i would like to see this ticket implemented into wordpress soon. so, any news?
5 years ago
- Cc danielbachhuber@… added
5 years ago
- Cc r@… added
5 years ago
- Cc zack@… added
in reply to:
↑ 38
↓ 48
5 years ago
Replying to ryan_b:
...and an argument to limit what post types it can be used with, especially now that we have custom post types, maybe I want a status just for my custom post type...
Support. There needs to be an argument to register_post_status() whose value is an array of already-registered post_types to which the new post_status applies.
Alternately, register_post_type() could take an argument whose value is an array of already registered post_status values.
Furthermore, as of v3.1.3, the preamble to post.php contains eight calls to register_post_status, which are ignored by get_post_statuses() and get_page_statuses() -- which both are hard-coded, not to mention which line 109 says:
register_post_status( 'pending', array( 'label' => _x( 'Pending', 'post' ),
while line 589 disagrees, returning the label:
'pending' => __('Pending Review'),
Regardless, surely both get_post_statuses() and get_page_statuses() should simply return the data created by register_page_status() and register_post_type().
in reply to:
↑ 47
5 years ago
Replying to wlindley:
Regardless, surely both get_post_statuses() and get_page_statuses() should simply return the data created by register_page_status() and register_post_type().
I believe those are just used for XML-RPC. The function to fetch statuses would be get_post_stati().
5 years ago
- Cc me@… added
5 years ago
- Cc d@… added
5 years ago
Related: #18578 (didn't spot this when I submitted mine)
5 years ago
- Cc simon@… added
5 years ago
- Cc lightningspirit@… added
5 years ago
- Cc sidewindernet added
5 years ago
- Cc alexkingorg@… added
5 years ago
The patch functionality (custom privacy and moderation statuses) is now implemented via plugin.
5 years ago
How is the status os this patch? Will this be implemented in 3.4? Do you need any help testing and implementing it? I can help with anything implementing this API, but I don't know where to start it.
Can you please nacin or anyone else give me some directions?
5 years ago
- Keywords westi-likes 3.4-early added
This has a lot of discussion and patch work that we should consider what we want to do API wise to improve post_status support in core and what we don't want to support.
4 years ago
Please also add new function post_status_exists( $post_status ) - sometimes it may be handy to check if particular post status is registered. You can also add 2nd param $post_type, to check if post status exists for given post type (optional param, defaults to all post types).
4 years ago
- Cc marko@… added
4 years ago
When this will be implemented this should also be implemented in xml-rpc. At this moment it is hardcoded.
4 years ago
- Cc stephenh1988 added
4 years ago
- Keywords needs-refresh added
This needs a dedicated sub-team, if it's ever going to get off the ground.
4 years ago
I'm happy to help on a subteam... I've done a lot of work with custom statuses and have a good understanding of where the weaknesses are.
4 years ago
- Keywords 3.4-early removed
I'm also willing to help, but it's too late for this in 3.4 (we're theoretically past freeze: http://wpdevel.wordpress.com/version-3-4-project-schedule/).
4 years ago
- Cc xoodrew@… added
4 years ago
Hi to all,
I really would like to help this topic and be also part of this subteam.
I think we need this feature in WordPress. I made some developments about this stuff in my instalations and I have some custom post types using this "meta" feature. I would like to contribute with them.
How can we join efforts to proceed with this?
4 years ago
- Cc philipjohn added
I brushed up the Codex article on this today and subsequently found this ticket. Adding myself to updates.
4 years ago
Why is this ticket keep sending me notices when I've removed myself from the cc list?
4 years ago
Because trac starts sending you notices the minute you do anything on a ticket: add a tag, add yourself to cc.
Please open a new ticket with the WordPress.org component to discuss this further.
4 years ago
- Cc Ben@… added
4 years ago
Updated patch to run with trunk, few bug fixes here and there
4 years ago
- Keywords needs-testing added; needs-refresh removed
Uploaded attachment:12706.diff which ports the existing patch forward to work with trunk (r20434).
Also fixed a few bugs, and in the process, created a new get_object_stati() function (mirrored off of get_object_taxonomies()) to deal with wp_list_filter not liking nested arrays (specifically the object_type arg).
Still testing, and I'm sure there's stuff I missed, but worksforme.
↓ 82
4 years ago
Although custom moderation and private stati are clearly useful and mesh well with the existing post_status implementation, custom public stati seem questionable. Can anyone think of a scenario in which they would be beneficial? All that comes to mind is:
- a single-term pseudo-taxonomy (probably unnecessary)
- allowing for distinctions in editing access without altering read access (potentially useful but arguably cludgy)
I'm not arguing for or against; just think it should be discussed before any code commits.
Another suggested topic for conversation: capability definitions and requirements related to custom stati. Any solution needs to regulate read, edit, delete and set (i.e. publish) of each custom post status, for each post type. The current patch does address these (just inviting further ideas).
in reply to:
↑ 81
↓ 83
4 years ago
Replying to kevinB:
Although custom moderation and private stati are clearly useful and mesh well with the existing post_status implementation, custom public stati seem questionable. Can anyone think of a scenario in which they would be beneficial?
Anything that's not a blog post; that you don't "publish." If the final step of my workflow is "submitted" (think malange with applications) or "final" (think alfresco with press releases). If I'm a news organization and want to have a "breaking" post status at an intermediate step in my editorial process to display a teaser on the front-end. If I'm a car dealership (think autorader) and use my cars custom post type as either "available" (listed) or "sold" (not listed). If I have a coupon site (think retailmenot) in which everything is either valid or expired. Anytime a post isn't a blog post. (not to mention it's kinda silly to abstract 2/3s and hard code 1/3 which makes building queries, etc. a bit less intuitive).
in reply to:
↑ 82
4 years ago
Replying to benbalter:
Anything that's not a blog post; that you don't "publish."
I don't follow the correlation between being a blog post and having 'publish' status. Pages and other custom types have post_status = 'publish' too.
My working concept of the three post_status types:
- $status_obj->public : published to everyone
- $status_obj->private : published to those with sufficient capabilities
- $status_obj->moderation : not published at all, and editable based on capabilities
Maybe you would rather rename (3) to "workflow" or something else, but I don't see "something you don't publish" as a public status.
If the final step of my workflow is "submitted" (think malange with applications) or "final" (think alfresco with press releases).
"Submitted" is a moderation status in my book (not yet public).
"Final" would mean public but no longer editable by anyone, right? If so, that says my scenario (2) is real world and there are usages where a sequential post_status workflow that retains visibility but changes editability is not a cludge. Glad to hear it.
If I'm a news organization and want to have a "breaking" post status at an intermediate step in my editorial process to display a teaser on the front-end.
That's a compelling feature, but how would you retain that "breaking" flag and track progress through various steps of moderation, all with a single post_status field? Or do you have some other schema in mind to implement these stati?
If I'm a car dealership (think autorader) and use my cars custom post type as either "available" (listed) or "sold" (not listed).
If you want it for display customization, that sounds like a good job for a custom taxonomy. If for suppression (non-publishing), it sounds like a workflow status, not a public status.
If I have a coupon site (think retailmenot) in which everything is either valid or expired.
Same as above.
(not to mention it's kinda silly to abstract 2/3s and hard code 1/3 which makes building queries, etc. a bit less intuitive).
Yeah, I already wrote the code to implement custom public stati. Just wanted some confirmation that it's worthwhile and optimal.
↓ 86
4 years ago
@kevinB: in fact post statuses are a special kind of taxonomy, dedicated to manage "post" workflow. In addition they have extra support for visibility in core - depending on status post may or may not be displayed on front side. In general that extra support in core should let you decide what is better: custom post status(es) or custom taxonomy.
Few extra examples:
- product page: draft, published, not available (temporarily), production stopped (page not visible);
- ticket workflow: new, assigned, resolved, verified, closed, rejected;
- movie page (for cinema): draft, screening/preview (there may be few of these), released, end of the screening;
4 years ago
I see status as internal workflow data. If you want to store data for decorating posts, that's where you want to use post meta. If you want to store data to use to query for specific posts, that would be a good place to use a custom taxonomy.
in reply to:
↑ 84
4 years ago
Currently, post_status is used to track workflow until publication. Then, upon publication it is primarily a visibility control (with corresponding editability control).
The current patch would expand that model as follows:
- additional moderation stages prior to publication (with corresponding set/edit/delete caps)
- additional visibility (privacy) statuses
- additional public statuses, which could be used to indicate further post-publication workflow (with possible distinctions in editing access)
The problem I see with (3) is that it could quickly overtax the one-status-per-post schema. What if you have already used a custom privacy status to customize visibility, but now want to make the post "final"? It seems that further post-publication editing access would be better handled via a separate status field that is dedicated to editability. If that is better left to a plugin, no problem ;)
Replying to sirzooro:
@kevinB: in fact post statuses are a special kind of taxonomy, dedicated to manage "post" workflow. In addition they have extra support for visibility in core...
4 years ago
- Cc admin@… added
4 years ago
- Cc johnbillion@… removed
4 years ago
Updated patch with bugfixes, refinements, and lastest trunk
4 years ago
Hoping to keep the ticket alive and kicking as planning gets under way for 3.5... updated the patch (attachment:12706-1.diff) with bug fixes and refinements and moved to latest trunk.
Although a bit rough around the edges, it appears to be somewhat stable for day-to-day use (I run it on a development box), and hooking into the API described above is fairly straightforward.
Outstanding: Potential tweaks to the publish metabox and quick edit
4 years ago
- Cc Viper007Bond added
Was disappointed to find that you can't register a custom post type to just a specific post_type like you can with a custom taxonomy and finally found this ticket. Would be great to get this into core.
4 years ago
- Cc navjotjsingh@… added
4 years ago
- Cc kovshenin@… added
4 years ago
- Cc brad@… added
Is there any movement on this for 3.5? I'd love to see this get in this version!
4 years ago
For this getting in 3.5 it needs a lot of unit tests since the code will be changed a lot.
Looking trough the code I was wondering how the default statuses will get registered to the default post types. I'm probably missing something. Also doesn't it make more sense to create a WP_Post_Status class instead of using a global for that?
4 years ago
- Keywords needs-refresh needs-unit-tests added
4 years ago
- Cc Ken@… added
4 years ago
- Cc justinsainton@… added
This would be super slick. With as much traction as this has, and considering this is between hard and soft freeze - I'm curious as to whether or not this is too ambitious to consider this cycle, or if it's something we can mark as 3.6-early?
Personally, I'd be happy to contribute and invest some time for this cycle.
4 years ago
If you want to make this get into Core faster, write some unit tests:
Unlike normal patches, unit test patches tend to get commited faster and don't get stale as fast.
4 years ago
Also, as is noted, it needs a refresh. Been keeping an eye on this in relation to some parts of #21391.
4 years ago
Good points. @ryanduff and I will take some time in the next week or so to refresh and start some unit tests.
↓ 109
4 years ago
While important, I don't think it's only a matter of only a refresh and unit tests.
I've chatted with benbalter about this a few times. He studied the original patch for easily 10+ hours while updating it to trunk, so he's quite familiar. But he also didn't make any changes to it, instead simply refreshing a two-year-old patch based on a two-year-old API proposal.
I think, and he agrees, that the API as proposed is lacking, confusing, and needs some work.
My initial thoughts on reviewing it are:
- The JS has a lot of room for improvement. Part of that is due to the age of the JS for the existing publish meta box.
- The meta box code has a lot of room for improvement. Rather than being a somewhat elegant status API, it looks like a complete hack. Again, a lot of that is due to the existing code.
- The "moderation" property is confusing and ill-defined.
- Seems like we need a new query var. We currently have post_status = 'any' (along with post_type=any) as a "meta" status that maps to everything. This whole thing seems like a ripe situation to take the post_status and perm query variables and make them better.
- That capabilities.php is untouched in the latest patch is incredibly odd, to say the least. map_meta_cap() supports custom post types and needs to support custom statuses for both built-in and custom post types.
- When it comes to capabilities.php and query.php, the left hand doesn't talk to the right hand. The previous two bullet points outline the two different systems, which really shouldn't be two completely separate systems.
- I randomly noticed that wp_count_posts() goes from 'draft, publish, future, pending, private' to only public statuses. There are many instances of raw SQL queries being changed — we need to thoroughly review these and ideally avoid direct SQL as much as possible.
- The concept of a "scheduled status" (a post having a status outside of the fact that it is in the "future") is nice. Perhaps this should be spun off and implemented separately from custom post statuses. There's just too much going on here, and that seems like a good thing to start with. There are likely other things that could be done or spun off. For example, why must a "published" post have a date in the past? (Think an event in the future.) I'm not even sure if the API as designed handles that.
Overall, there's just so much to consider here, there's really no way it is happening for 3.5.
in reply to:
↑ 108
4 years ago
Replying to nacin:
- That capabilities.php is untouched in the latest patch is incredibly odd, to say the least. map_meta_cap() supports custom post types and needs to support custom statuses for both built-in and custom post types.
The lack of change to function map_meta_cap() is explained by the patch's plugin roots. It can be filtered to apply additional capability requirements based on $post->post_status (as demonstrated in the old status-helper.zip). Maybe inelegant, but not that odd.
- The "moderation" property is confusing and ill-defined.
Call it what you want, the idea is to allow for multiple statuses between draft and published, rather than hard-coding 'pending'. Each of those "moderation" statuses should have its own capability analogous to "publish_posts", as well as edit and delete caps. API should also allow control of which status (i.e. "Reviewed", "Approved" or "Dissed") is set by the "Publish" button when the user cannot publish.
@F J Kaiser
4 years ago
- Cc 24-7@… added
4 years ago
- Cc travel-junkie added
↓ 116
4 years ago
Maybe I've missed this so please excuse me if this point has already been made (feel free to point me towards it).
I'm wondering if the current discussion on custom stati includes the possibility of having a published post/page workflow which has a new version currently in progress without taking the current version offline? Basically the ability to work on new drafts without having to take the current version offline akin to how autosave currently works.
A possible example use case could be:
Ann is an author who blogs about legislation. She wrote a post on law X some time ago. This law X is in the process of being be changed. She would like to update her old post on this law X, but keep the current version still online until the changes in law X have been agreed upon. In the meantime however she would like to update her old post, save the changes, but not make these changes public nor take the old post offline. She continues to work on her changes saving them, occasionally she invites a peer to have a look at her work and all this time the old post stays the same & online. After the changes in law X have been agreed upon she makes her changes public and this updates her old post online.
As far as I know WordPress does not support this use-case currently and it would be very nice if the new custom stati API would support these type of usecases where the publicize workflow of WordPress could be enhanced.
Btw the use-case described above is derived from both corporate & government clients who have a need for a more moderated publicize workflow due to the nature of their content, which for instance may be used in legislation.
If there is anything we can do to speed up the inclusion of this in the stati API, feel free to contact me.
in reply to:
↑ 115
↓ 117
4 years ago
Replying to BjornW:
I'm wondering if the current discussion on custom stati includes the possibility of having a published post/page workflow which has a new version currently in progress without taking the current version offline? Basically the ability to work on new drafts without having to take the current version offline akin to how autosave currently works.
Not that this necessarily solves your entire use case, but Revisionary already handles a lot of what you're asking for.
in reply to:
↑ 116
4 years ago
Replying to sbressler:
Not that this necessarily solves your entire use case, but Revisionary already handles a lot of what you're asking for.
Thanks we had a look at the code of Revisionary and frankly I found at very large (loads of code which seems to be part of somekind of homebrew framework) & at first glance messy. Although it does work as advertised :) I might use it as a reference for a smaller plugin.
↓ 119
4 years ago
Ben Balter (who has been active on this ticket) has been working with a few others on a Post Forking plugin. I'd start there! https://github.com/benbalter/post-forking
in reply to:
↑ 118
4 years ago
Replying to nacin:
Ben Balter (who has been active on this ticket) has been working with a few others on a Post Forking plugin. I'd start there! https://github.com/benbalter/post-forking
Nacin, the link is dead & I don't see any repo resembling 'post-forking'? Are you sure it's called like that?
4 years ago
The link is now alive: https://github.com/benbalter/post-forking
and more information can be read here: http://postforking.wordpress.com
3 years ago
- Cc adam@… added
3 years ago
- Cc aaroncampbell added
3 years ago
- Cc slobodanmanic added
3 years ago
- Keywords editorial-flow added
- Milestone changed from Future Release to 3.6
in reply to:
↑ description
3 years ago
- Cc maxmaeteling added
3 years ago
- Description modified (diff)
- Type changed from feature request to task (blessed)
- Version set to 3.0
3 years ago
↓ 133
3 years ago
In 12706.2.diff took a stab at the "statuses in post types" approach, briefly discussed in IRC. You can register post statuses to post types in register_post_type by using the statuses array:
'statuses' => array( 'pitch' => array( 'label' => _x( 'Pitch', 'book' ), 'label_count' => _nx_noop( 'Pitch <span class="count">(%s)</span>', 'Pitch <span class="count">(%s)</span>', 'book' ), 'public' => false, 'protected' => true, ), ),
Statuses registered with register_post_status will be applied to all post types. If this approach looks reasonable, I'll continue working on some of the other parts touched by the earlier patches.
in reply to:
↑ 131
↓ 134
3 years ago
Replying to kovshenin:
Statuses registered with register_post_status will be applied to all post types. If this approach looks reasonable, I'll continue working on some of the other parts touched by the earlier patches.
Please add option to disable this - some plugins may want to register post status first using register_post_status, and then explicitly attach it to selected post types.
in reply to:
↑ 133
3 years ago
3 years ago
3 years ago
In 12706.3.diff: still haven't touched any user facing parts, same as .2.diff with the following additions:
- New WP_Post_Status class which is used by register_post_status, register_post_type, and possibly register_post_status_for_object_type (see #23169)
- New status attribute show_in_admin_status_dropdown which tell whether the post status should be displayed in the Publish metabox dropdown. It defaults to false and basically prevents a bunch of custom statuses to suddenly show up for all post types after an upgrade to 3.6.
- Another status attribute priority which defines whether a post goes through "Draft - Pending - Publish" or "Pending - Publish - Draft" so the one with the lowest priority (usually Draft) will also define what's the default status for new posts. A new function _sort_post_statuses which sorts by priority.
- A capabilities array, for now only defines the transition_post capability map which defaults to edit_post, and set to publish_post for the Published post status. This allows us to check whether users can change a post to a certain status upon save, etc.
Thoughts? Feedback? How does this look? Question: do you think register_post_status should be deprecated in favor of status registration with register_post_type and register_post_status_for_object_type?
↓ 140
3 years ago
12706.db.1.diff takes Kovshenin's patch and does the following:
- Drops the 'priority' and 'capability' arguments. Priority is largely UI-related which we can work on later, and caps are outside the scope of this ticket.
- Adds a 'moderation' argument for registering post stati to bucket 'draft' and 'pending' stati separately from 'future'
- Completes the post status => post type implementation such that get_post_stati() by a post type actually works. I changed the filter argument to 'post_type' because post stati will only be registered to posts. The somewhat lame thing is that new WP_Post_Status objects can live in two or more places: $wp_post_statuses global and with each post type. Not sure how we want to reconcile this.
- Starts the implementation of exposing newly registered stati in the admin. This particular patch just works for the Manage Posts screen and things like _post_states() need to be updated.
- Starts the abstraction of hard-coded post stati references in other APIs.
I think I'm going to wait on touching the publish meta box until we have some direction on the other part of the project, and instead will continue playing whack-a-mole with the hard-coded references.
in reply to:
↑ 139
3 years ago
Replying to danielbachhuber:
Consider applying ticket #23207 in your patch - Using $labels argument like it's done in register_taxonomy() and register_post_type().
See ticket #23207 and GenerateWP.com (compare the taxonomy-labels and the post-type-labels with post-status-labels).
This way, we would create a standard way to add translation strings to register_{taxonomy|post_type|post_status}() functions.
Just a thought.
3 years ago
- Cc justin@… added
↓ 143
3 years ago
12706.db.2.diff is my first patch plus the following:
- Abstraction of the Publish meta box such that custom moderation statuses can appear in the dropdown, and contributors can submit to the next moderation status.
- _post_states(), which is used in the Manage Posts list tables, will now add all 'protected' statuses, which includes 'draft', 'pending', and 'private'
- Implementation of a 'labels' argument when registering custom post statuses
- get_sample_permalink(), and editing a post slug, no longer breaks when a post is saved to a custom moderation status
If you apply the patch, you'll notice there's a JS error when you change a post to a custom moderation status and hit "OK". There's a @todo marker in the patch for this. Essentially, I'm loading the post status data to the clientside using the script loader. The script loader fires too early though (on init:0) for any custom statuses to be registered.
At least these two big areas still need to be touched:
- QuickPress / PressThis
Here are some pieces I ran into confusion about:
- 'draft' posts fire edit_post(), where as others do wp_create_post_autosave()
- Two ways of redirecting to a preview link depending on draft vs. pending
- A bunch of different types of input buttons are interpreted
- Couple of hardcoded references to 'draft' and 'pending'
Lastly, I've started logging the individual changes I'm making (and justification) on my Github fork: https://github.com/danielbachhuber/WordPress/compare/master...12706-custom-status
Would love to have others play with this code and offer feedback during Tuesday's chat.
in reply to:
↑ 142
3 years ago
Replying to danielbachhuber: Here's my feedback after applying your patch to a clean trunk:
- Once a post is published, there doesn't seem a way to go back to draft or other statuses from the edit post screen
- "Private" labels are gone for private posts in the posts list
- When saved for review, the submit button says "Submit" and does the same as Save (contributor)
- I noticed the save_next argument in the post statuses labels, not sure I understand that. I think each status should have the transition_to label instead, because you don't always transition from draft to pending. So "Submit for Review" will be the transition_to label for pending. "Save as Draft" for draft posts, etc.
- Have we decided whether we're keeping the status class or not?
I'm also confused about edit_post, autosaves, previews and revisions.
3 years ago
12706.db.3.diff hits the first two issues. Here's the relevant changesets:
- https://github.com/danielbachhuber/WordPress/commit/5d6e7933e8f3cca5c5cc901db46a07d8fdf7b81c
- https://github.com/danielbachhuber/WordPress/commit/ed89961bde52403a34badfc6d0d2a97c53517a65
For the third, I'm not sure what the behavior should be or whether we should just continue supporting the contributor model as it exists now.
For the forth, I dig that idea. We need a cleaner way of getting the "next" or "previous" status though.
Lastly, I'm digging the status class now. It seems like a better way of enforcing a common post status object. I suppose we can hear the objections against tomorrow.
3 years ago
- Cc liam_bowers added
3 years ago
- Cc lol@… added
3 years ago
- Cc kevinlangleyjr added
3 years ago
I guess this is future release now? Any change we can move this development to a github repository?
3 years ago
- Cc chriscct7@… added
3 years ago
- Milestone changed from 3.6 to Future Release
3 years ago
- Cc jeff@… added
3 years ago
- Cc RonStrilaeff added
3 years ago
(Comment from #7745 that seems to be relevant - this comment is more expanded)
It seems the real problem is that there are 2 orthogonal issues at work that are not being treated orthogonally: Visibility and Status.
Currently ( 3.7-alpha24822 ) there are very bizarre interactions as a result.
Interaction path 1:
- Create a post
- Change its Visibility to Private
- Status now changes to 'Privately Published'
- Status does not have an edit link any more
Interaction path 2:
- Create a post
- Click on Status edit button (so the status selection box is displayed)
- Click on Visibility Edit button
- Change Visibility to Private
- Click on Visibility 'OK' button
- Status option box changes to allow 'Pending Review', 'Draft', 'Privately Published'
- Select 'Draft' and click on status 'OK' button.
- Status becomes 'Privately Published' ( not Draft like user requested ) and the edit button disappears.
Interaction Path 3:
- Create a post
- Click on Status edit button (so the status selection box is displayed)
- Click on Visibility Edit button
- Set the scheduled time to be in the future
- Change Status to be private
- Post published and the scheduled time is still set to be the future.
- Visibility and Status are not logically the same :
- Visibility is the MAXIMUM POSSIBLE visibility.
- Status is a WORKFLOW STATE that may impose a maximum calculated_visibility
- If Visibility controls Status then Status should be visually subordinate to Visibility. Currently it looks like Status should control visibility. (which from a work flow perspective I would think that it would be the case.)
- Visibility and Status interact in a non-intuitive manner.
- Status should be used to determine the CURRENT maximum visibility of a post.
- Visibility determines the absolute maximum visibility of the post.
so conceptual the question is :
current_user_can('read_post', $post_id) ;
with the answer being determined by:
$actual_visibility = max ( status_max(), visibility_max(),
<some calculation depending on current_user's relationship to the post>, <posting_schedule>, <other filter functions > )
3 years ago
- Cc sworddance added
3 years ago
#12510 was marked as a duplicate.
3 years ago
- Cc steph@… added
3 years ago
- Cc zanematthew@… added
3 years ago
- Cc NateJacobs added
3 years ago
- Cc gennady@… added
3 years ago
- Cc michael.ecklund added
2 years ago
- Cc corradomatt added
2 years ago
Any hope of this getting picked back up for 3.9? Tempted to apply Daniels patch to get this working on internal project.
2 years ago
I would love to see this taken on again, although I don't think it should be promised for a release until the UX and ensuing UI and API are thought through. I think it's important to note the order there - I understand that the instinct is to go for API first (I'm a developer, too, I more than get it), but I think what we're really battling here is growing pains, not just a broken API. We need to focus on what the UX should be, first from a default standpoint, then from a "what COULD people want to do" standpoint, and then determine what UI and API changes need to happen from there.
For example, let's take a pretty common custom workflow of "I save a post, somebody else copyedits it, and somebody else actually publishes it". What does each user type's workflow look like when they're in the admin (possibly not even just the edit screen)? How can the admin help guide them to the best or right action or set of actions to take? From there we think about how an ideal UI would be structured and what an API would need to support for that scenario. Then, through considering various and varying scenarios, again starting with existing default ones, we can come to what kind of extensibility the UI needs to account for and, of course, what the API needs to look like to make it all actually work and to allow developers to mold and customize as needed.
I'd love to explore this some more and plan on doing so in the near future, and invite anybody else who has some thoughts to do the same. comment:162 is a nice breakdown of the current "flows".
↓ 178
2 years ago
Once a project hits a point where it requires a more complex workflow than what WordPress offers out of the box, all bets are off. I don't think we can or should solve that problem in core. However, I think core should have APIs that fully support more complex publishing workflows.
If I were to pick up development on this again, I would likely follow this approach:
- Identify five or more use cases for more complex publishing workflows with sufficient detail that it's possibly to understand the commonalities between them.
- Discuss how the commonalities could be better supported by core.
- From the commonalities, define the problem to be solved. Get buy-in from a core committer or two.
- Build a library to support the commonalities. Should it prove useful, include it in core.
I don't think this ticket has ever really gotten anywhere because everyone on it has been trying to solve different problems, and there hasn't been a core committer yet who just takes an idea and runs with it.
With that being said, I think you could reach out to participants on this ticket with a survey and get sufficient detail for your five or more use cases pretty quick.
in reply to:
↑ 177
↓ 180
2 years ago
Replying to helen:
then from a "what COULD people want to do" standpoint, and then determine what UI and API changes need to happen from there.
That seems like a rather large scope for core development. Maybe not for a "Feature-as-a-plugin", but definitely for core-focused features.
Replying to danielbachhuber:
If I were to pick up development on this again, I would likely follow this approach:
- Identify five or more use cases for more complex publishing workflows with sufficient detail that it's possibly to understand the commonalities between them.
- Discuss how the commonalities could be better supported by core.
- From the commonalities, define the problem to be solved. Get buy-in from a core committer or two.
- Build a library to support the commonalities. Should it prove useful, include it in core.
That also seems like quite a large scope, and part of the reason this ticket is 4 years old and still not addressed.
I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.
Lack of custom statuses in the UI is a big missing piece in core (considering core has register_status()) and something for which I've had to revert numerous times to a very hackish use of ob_start()/ob_end_clean() to correct.
Once custom statues have appeared in the core UI then we can more easily identify specific workflow use-cases that deserve to be in core, and then each of those independent issues can get their own ticket in core.
2 years ago
Completely agree with @MikeSchinkel. The small scope he describes is all that I was looking for when I joined this ticket. Perhaps it would be best to create a new ticket that describes this much reduced scope? Something like "Add custom post status to status select box on edit post screen"?
in reply to:
↑ 178
↓ 181
2 years ago
Replying to MikeSchinkel:
I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.
It isn't simple. The existing metabox makes almost no sense when you step back and look at it. Visibility and status are separate in the UI, but not in the data, and they mess with button labeling in different and sometimes unpredictable ways - how can we add to this in any sane way? Shoving more in there just makes it even harder to change later.
I don't think core should be providing non-default workflows at all, and I'm sorry about not being particularly clear about that - I just think that once we're talking about supporting custom statuses, we should take at least a few minutes to be considerate of what developers are doing with that. Even if the end result is simple (and, dare I hope, a simplified UI), a little consideration goes a long way so that people don't end up still having to do lame hacks, just in different places. I'm not calling for creating formal personas and scenarios or anything like that here - just a look at some of the bigger parts of the picture.
I have no preconceived notions on how involved or big changes to UI and API might be. I just think there's value in a UX-first approach, especially when it comes to trying to avoid hampering extensibility or the future. Again - that UX part of the discovery process could take a total of 10 minutes. I don't know. I don't think we're actually conceptually at odds here. And, after all, it's also just my two cents.
in reply to:
↑ 180
2 years ago
Replying to helen:
Replying to MikeSchinkel:
I'd propose we start with the following: SIMPLY add custom statues to the list of potential selectable statues in the post add/edit UI and require any new workflow to be handled by the developer. Period. That could easily be implemented in time for 3.9.
It isn't simple. The existing metabox makes almost no sense when you step back and look at it. Visibility and status are separate in the UI, but not in the data, and they mess with button labeling in different and sometimes unpredictable ways - how can we add to this in any sane way? Shoving more in there just makes it even harder to change later.
There's more that's making this "not simple" than just the UI too. There's also the issue that we hardcode "publish" as the only status for published posts. This means that we need filters in several other places unless we relegate custom statuses to being all non-published. For example, an "archived" status that is still live (but is maybe used to prevent it from being edited), wouldn't work.
2 years ago
A lot of status lists and transitions are hard-coded. What I'd like to do is make all those lists filterable and the actions variable (e.g. $status-to-$status). Then a developer wishing to implement a custom workflow could add the custom status to the filtered list and use the actions to implement whatever additional functions (like email notifications) are needed.
↓ 186
↓ 187
2 years ago
I think there are two very different ways to approach this. I don't think they are mutually exclusive, but they are different worlds in complexity and approach.
- A custom post status is nothing more than an alias/rename/copy of an existing status.
A status like "Sent to Editor" is really just "pending" under the hood. Or a status like "Active" is really just "publish". There is no "expired" post status in WordPress, so "Inactive" doesn't translate directly to any existing status, but it's more or less "trash".
So, we should build something that simply allows you to declare a new status with a few basic flags that make it mimic the functionality of an existing status. If you're building out a proper workflow, is "For Copy Editor Review" really anything different than "Pending" other than the name?
And at that point, I begin to wonder if an actual "aliases" API is most helpful. And if a post is pending review ("Pending"), who is it pending review for? Is it really necessary to have a separate "status" for each desk a post needs to reach (I'm thinking newsroom, but you can probably extrapolate this for other workflows), or is it just a piece of metadata tied to the post that allows us to say "oh yes, it is assigned to Helen for review". It's still "Pending", so does it really matter what its status is?
So, very simply, I've yet to see some solid use cases of custom post statuses that aren't just renames/aliases of existing functionality.
- A custom post status API requires us to tackle the world of transitions. It's not just that a post can be one of X statuses, it's that based on the current status, and the current user, it can be promoted/demoted to one of X statuses.
Does that mean current_user_can( 'transition_post', $post_id, $new_status )? Probably. And you'll note that if $new_status = 'publish', then this is basically just current_user_can( 'publish_post', $post_id ) — see, we already have a publish_posts capability to extrapolate from. Now someone could implement fine-grained control, without us getting into the workflow business. Maybe.
While a concept like transition_post can handle authorization, it doesn't necessarily handle UI options. Given status A, what statuses can you go to? How does that change affect its spot in a pending moderation queue? Or is it considered "draft"? Or is it considered published? Do we have to implement something like Trac's ticket status workflow? (It's kind of insane, but here's a primer.)
What does a custom post status actually mean? I don't know -- I've been thinking about this for four years and still don't have an answer.
↓ 185
2 years ago
I strongly agree with Nacin's alias approach. Typical use cases are other names for Pending that may/may not trigger email notifications.
The only use case outside of Pending that I have had is make a Trash-like alias of 'Inactive' on a CPT that doesn't clear after 30 days that removes it from 'show_in_admin_all_list'
in reply to:
↑ 184
2 years ago
I second Nacin's approach. My use case is using CPT's which have a custom status "traffic light" that can determine the status of a client at quick glance.
Using Custom Post Status would help sort these CPTs into groups (e.g. "Booked", "Not Booked", "Waiting on Client", etc.)
For me the alias is a great idea, since these custom post status' are really just the same as Published/Private.
in reply to:
↑ 183
2 years ago
Replying to nacin:
So, we should build something that simply allows you to declare a new status with a few basic flags that make it mimic the functionality of an existing status. If you're building out a proper workflow, is "For Copy Editor Review" really anything different than "Pending" other than the name?
So I assume that an existing status could be aliased multiple times?
Then, would the aliased status be stored in the post_status field (i.e. '4ce_review') or would 'pending' still be stored and if so how would the "For Copy Editor Review" be associated? Also, how would developers be able to implement efficient SQL queries to retrieve just the posts for a given alias status when there are multiple aliases for the same existing status, i.e. as "For Tech Review" might also be a legitimate 'pending' status?
As for flags, I scanned through core's source code and it seems that some of the use of status is specific to status, i.e. omit 'trash' posts in a list of posts unless displaying the list of items in trash. But other uses of status seem to point to what a given status implies, or more importantly what all other statuses imply. This leads me to think that a "Post Status Supports" concept would make sense, and here are some of the one's I quickly identified:
post_status_supports( 'revisions' ) post_status_supports( 'sample_permalink' ) post_status_supports( 'last_edited' ) post_status_supports( 'editing' ) post_status_supports( 'editing_attachment' ) post_status_supports( 'commenting' )
With a post_status_supports() function it would seem we could evolve a lot of the code that operates on happenstance and instead actually focus on the (currently implicit) logic needed. With this approach and a related filter hook, plugin and themes could add their own statuses (or status aliases, however it plays out) and if they want their status to support editing but not revisions, then they would have control to do so and core would support their new statuses.
And at that point, I begin to wonder if an actual "aliases" API is most helpful. And if a post is pending review ("Pending"), who is it pending review for? Is it really necessary to have a separate "status" for each desk a post needs to reach (I'm thinking newsroom, but you can probably extrapolate this for other workflows), or is it just a piece of metadata tied to the post that allows us to say "oh yes, it is assigned to Helen for review". It's still "Pending", so does it really matter what its status is?
Actually with an addition of post_status_supports() I think aliases might be of less interest and frankly, aliases are less WordPress-ish. It would be similar to how post types can be extended with post_type_supports() and how we don't really depend on custom post types to be aliases of 'post' or 'page'. So instead of trying to shoehorn new potential use-cases into our existing known use-cases we can instead focus not on the status itself but the individual behaviors that each existing status implies and this support emergent use-cases we'd not previously realized.
So, very simply, I've yet to see some solid use cases of custom post statuses that aren't just renames/aliases of existing functionality.
I'm not sure lack of evidence is sufficient to prove lack of existence. Even so, by writing code to test "if a post status supports revisions" rather than "if it's neither 'auto-draft' and 'draft'" should allow for us to write more robust plugins and themes that are more resilient to change and the bonus is they would support valid custom post status use-cases if and when those use-cases emerge.
All that said, it's already possible to add new custom post status and because of that more than a few people have been using ob_start()/ob_end_clean() to enable them in the admin, or they've written custom metaboxes to support it. Thus adding the ability to also automatically display these custom post statuses will do no "harm" as there are custom post statuses in the wild within many WordPress databases, and they have survived without core's workflow supporting them. Why not at least close the loop on this and let us add in custom post statuses into the post add/edit UI while we wait on a better solution? And if not automatically, why not at least give us a filter hook so we can accomplish it without writing fragile hacked code?
in reply to:
↑ 183
2 years ago
I really think Nacin's second direction, workflows is the way to go. There are many use cases where the ability to have a stricter workflow would be beneficial. I also think workflows fit into the app engine direction WordPress is going for.
↓ 189
2 years ago
I would go for the first direction nacin suggested, allow aliases, at first iteration. In a second iteration, later, implement alternative workflows, transitions and/or "supports" to statuses. May the first and simplest solution get in the way for future evolution?
The best solution sometimes becomes the enemy of a good solution.
in reply to:
↑ 188
↓ 190
2 years ago
Replying to knutsp:
May the first and simplest solution get in the way for future evolution?
The simplest solution is to just include registered statuses in the drop down that allows a user to select a status before updating a post. Aliases would be much more work than that.
in reply to:
↑ 189
2 years ago
Replying to MikeSchinkel:
Replying to knutsp:
May the first and simplest solution get in the way for future evolution?
The simplest solution is to just include registered statuses in the drop down that allows a user to select a status before updating a post. Aliases would be much more work than that.
May be - probably. But to show up in the drop down on the edit post screen, core needs to handle the status as if it was one of the existing. That is the reason this bug is still present. Some statuses trigger UI behaviour (because it means something, has semantics, to core), like changing the button text. May all registered stati be handled as an alias of draft, just to begin with?
Talking about the best solution is fine, when used to evaluate if a first, simple solution might also be a good, temporary solution. When the most visible bug here is gone, then the rest may be future enhancements. Then make a new ticket for that.
People, in thousands, are willing to settle on Mars, without any technology to return to Earth. We are, it seems, not willing to simply fix an old bug as long there isn't a path to CMS heaven included.
I want to go to Mars, one way, when that is the current option. Now, not waiting for a tested Mars-to-Earth commuter system to be in place.
2 years ago
May all registered stati be handled as an alias of draft, just to begin with?
That's how I'd tackle it. Heck, using ob_start() and ob_get_clean() that's how I already handle it. But what a hack PHP caching is.
a first, simple solution might also be a good, temporary solution
I want to go to Mars, one way, when that is the current option.
Ignoring that you were using as a metaphor, you go right ahead. I'll stay here and you can send me ePostcards… ;-)
↓ 193
↓ 195
2 years ago
Whatever you do, please stop using stati as a plural. :)
The plural for the noun in English is statuses, in Latin statūs.
in reply to:
↑ 192
↓ 194
2 years ago
Replying to toscho:
Whatever you do, please stop using stati as a plural. :)
The plural for the noun in English is statuses, in Latin statūs.
We used get_post_stati() because get_post_statuses() was already taken for an XML-RPC function. Ideally we end up with get_post_type_statuses() — which is implying, yes, that we have per-post-type custom statuses. Which I glossed over above, but also needs to be figured out.
in reply to:
↑ 193
2 years ago
Replying to nacin:
We used get_post_stati() because get_post_statuses() was already taken for an XML-RPC function.
Webster don't agree, but I've come to appreciate the brevity of "stati" (though only in code). I think WordPress has the standing and audacity to be an intelligent force in the ongoing evolution of language.
in reply to:
↑ 192
@F J Kaiser
2 years ago
Replying to toscho:
Whatever you do, please stop using stati as a plural. :)
The plural for the noun in English is statuses, in Latin statūs.
I double that. Could we simply stay with either Latin or English instead of any ... custom variant? Whatever language that is: It has to go away. Now. Or better yesterday. It's already tough enough that we ain't really got a naming convention and that I have to rely on my IDEs autocomplete feature to maybe have a hit - not that it always will meet my requirements - but then as well having non-English vocabulary? Please be nice with us non native speakers and at least leave us the dictionary as last resort.
23 months ago
What is the status of this? It is too late for 4.0 now, but what about next release?
20 months ago
- Owner ptahdunbar deleted
- Status changed from new to assigned
↓ 207
19 months ago
I'm using 5 custom status for WTG Tasks Manager for a custom post type.
Posts using a custom status do not show on the All posts view - the query must still have the original core statuses coded.
17 months ago
Here's my case for additional post statuses:
For blogs.ft.com we have a custom post type called webchat, which is used for live sessions. These sessions are events, with a duration of an hour or so, where content is added in a real-time, instant-messaging, streaming fashion.
We still use the usual WordPress statuses (well, just Draft and Published, really).
I'd like to have a kind of sub-status feature in WP core, so that:
- When a webchat post is first published, its status is "Coming soon". This lets users know when to tune in for the event, which is scheduled to start in a day or so.
- When the event starts, the status is "In progress". We use the transition to trigger other things (that aren't important to this case, except that we do want to be able to hook the transition.)
- When the event concludes, the status becomes "Closed". It's still published, but it's clear the event is now over.
- Webchats appear alongside standard posts in the homepage loop, in other words they're treated as just another post.
- It would be beneficial to not only be able to add these semantic status types, but also alias them depending on different kinds of webchat session. For example, question-and-answer discussions (with multiple participants), as opposed to as-it-happens liveblogging (with a single author). Conceptually these are sufficiently different to warrant bespoke terminology for (what are essentially the same) statuses.
This ticket was mentioned in Slack in #core by lukecarbis. View the logs.
15 months ago
14 months ago
#21699 was marked as a duplicate.
11 months ago
- Version 3.0 deleted
@wonderboymusic @danielbachhuber What are the approximate time of complete this API?
11 months ago
- Version set to trunk
11 months ago
- Version changed from trunk to 3.0
Please do not change the version
This ticket was mentioned in Slack in #core by joelstransky. View the logs.
9 months ago
7 months ago
I am not sure this should be based on workflow or use-cases. Wouldn't it be beter to base this on the actual functionality of the status?
A post-type can have 3 possible states: published, unpublished and trashed. No matter how a status is called/named, the end result is one of these 3 functional states. So basically all we need is the ability to add aliases and an ability to include them in the status dropdown and/or post-type index and/or post filter.
So using the existing function register_post_status the $args argument should be extended with the following:
- post_type (any post-type slug(s) for post-types this status can be used on, should default to posts and pages?)
- post_state (can be published, unpublished or trashed, defaults to published?)
- show_in_publish_dropdown true/false (false as default I guess?)
With this you can make any number of statuses and use them any way you want. If you want to add something extra, an additional argument called 'color' could be introduced that adds a colour border to the post-type much like the blue border with plugins.
in reply to:
↑ 198
4 months ago
Replying to WebTechGlobal:
I'm using 5 custom status for WTG Tasks Manager for a custom post type.
Posts using a custom status do not show on the All posts view - the query must still have the original core statuses coded.
Not sure if this was the original intent of this trac ticket, but I can confirm experiencing the same issue as WebTechGlobal.
register_post_status( 'active', array( 'label' => _x( 'active', 'Status General Name', 'my-plugin' ), 'label_count' => _n_noop( 'Active (%s)', 'Active (%s)', 'my-plugin' ), 'public' => false, 'show_in_admin_all_list' => true, 'show_in_admin_status_list' => true, 'exclude_from_search' => true, ) );
the show_in_admin_all_list parameter is either very misleading in its naming convention or buggy in its implementation, because setting this to true does not actually show posts of that post_status on the edit.php?post_type=custom_post screen. You have to filter the request variables and add the post statuses that way.
add_filter( 'request', 'my_request_query' ); function my_request_query( $vars ) { global $typenow; if ( 'custom_post' === $typenow ) { // Status if ( ! isset( $vars['post_status'] ) ) { $vars['post_status'] = array( 'my-status-1', 'my-status-2' ); } } return $vars; }
This ticket was mentioned in Slack in #core by michael.ecklund. View the logs.
4 months ago
3 months ago
Shows the registered status when 'show_in_admin_status_list' is true
3 months ago
Fix showing "register_post_status" in save post widget. Now upper left button get updated to the selected state.
3 months ago
- Keywords needs-refresh removed
6 weeks ago
138 stars and nobody wants to work on it? Ping me on Slack if you're interested in working on it for 4.6! :-)
6 weeks ago
What if we had a WP_Status base class that could be used by posts, users, comments, and maybe even taxonomy terms?
What if a status had properties to define it's object, scope, transition boundaries (to and from), related capability requirements, and so on?
What if we take the lack of an API as an opportunity to clearly define what exactly a status is, and what we need and expect from it?
Is it visibility? Is it privacy? Is it limited to certain users? Is it visible on the front end? Is it visible ever? Certain post types? When and why does it transition, and to what other possible statuses based on what conditions? Can they transition using WordPress Cron, or Heartbeat?
@danielbachhuber has worked a lot with these concepts in the past, and bbPress also implements custom post statuses. The most often used statuses are flat and simple, but imagine a post status for bbPress topics that knows to close them after 90 days in inactivity. Imagine future dated posts that actually publish on time without missing their schedules.
I absolutely do not want for perfection to get in the way of any progress that we can make here, and I think a clearer roadmap for the future of this feature will help everyone know where to focus their time and passion for solving it all.
Then maybe we can break those ideas up into smaller chunks and tickets, which I find helpful for making big issues start to feel achievable.
6 weeks ago
I'm intrigued by @johnjamesjacoby suggestion for more complicated post statuses, but I worry about whether that's feasible without a substantial rewrite of the query structure. Currently, post_status is a simple query parameter: find posts with X status. I have no idea how to construct a query for "open message boards" that dynamically close 90 days after inactivity without having to do a lot of ugly query modifications on the fly.
In my mind, post status is about visibility: who can see the post, and in what contexts (admin, frontend, REST, in a custom query for a frontend element, etc.) As far as I can tell, that framework meets the needs of almost every use case proposed in this thread, from releases to coupon codes to breaking news to moderation. The one case I don't know if it covers sufficiently is handling revisions to an already-published content that are saved in progress but don't update the original yet (see comment 115 above).
6 weeks ago
I'll throw in one more use case, needed for journalist sites: Morgue. Articles with info that's out-of-date but has elements we wish to save. Often the "morgued" post's URL is redirected to a newer related article. But we still want to save the original, even if just for archival purposes.
So we set the Morgue post-status public and search parameters to false, but the show-in-lists params to true. That way we can list all Morgue posts quickly.
Not sure how general this need is, but in journalism the idea of an article morgue is central. And born-digital news is being lost FASTER than paper=printed news. So perhaps post-status can assist in archival/preservation efforts.
5 weeks ago
As I mentioned before; personally I would like this to be simple but effective:
As I see it now, there are 4 (perhaps 5) 'states:
- to-be-published
- published
- has-been-published (optionally with a 301? redirect)
- trashed
- (optional:) never-to-be-published
Implement these and give the ability to create custom names coupled to any of these states and allow those names to be shown in the UI and hooked into an action (for custom functions coupled to a named state).
Wouldn't this solve most (if not all) use-cases?
↓ 220
5 weeks ago
bbPress has a few custom statuses:
- Spam
- Pending
- Private
- Hidden
- Closed
- Orphaned
These are basically states that a forum/topic/reply will find themselves in based on different criteria, and a moderator can force a state if they wish.
A state is really a collection of properties, not dissimilar to how roles have capabilities, and these properties need an easy way to build database queries and limit their visibility.
Consider also that this is likely to be a solved problem already in other open source projects. Has anyone made any progress beyond WordPress when it comes to object states?
5 weeks ago
Just throwing my .02 here... Two of the biggest reasons I enjoy using WordPress for my website platform of choice is for the simplicity and the flexibility/customization.
I've been essentially limitless with WordPress so far. Between Custom Post Types, Custom Taxonomies, Metaboxes (backend -- only), Meta (user/post/term). Admin pages, Admin notifications, and HOOKS (let's not forget about hooks!) etc... What CAN'T you customize in WordPress?
Which brings me back to this topic and something that bugs me... It's not real simple or flexible to customize statuses in WordPress right now. I would love to see improvement in this area and would most definitely would make use of it more once improved.
I kind of like where @johnjamesjacoby was going with his thoughts in response #211. I do agree this area needs more thought and structure to better tie-in multiple different aspects of WordPress but also (if possible) try to keep it SIMPLE and FLEXIBLE for manipulation/customization as well.
5 weeks ago
Rather than patching a 6-year old custom status API that was never fully completed, I'm more inclined to see the @johnjamesjacoby WP_Status object dream come true.
I'd be very excited to contribute and collaborate on this.
The before-publish state is aligned with the "try-before-you-buy" direction that the Customizer and other initiatives within core have been aiming for. Providing a mechanism in which other objects can transition from before-publish to publish would allow virtually anything to be staged and previewed before going live.
Imagine being able to create draft placeholder Users or Terms that are inactive/unpublished until a certain date.
The "after-publish" state has been an itch needing to be scratched for a while, which is why I released a feature plugin for it last year. Lots of hacky nonsense was needed to pull it off in a way that maintained a consistent UX with existing post transitioning flows.
This ticket was mentioned in Slack in #core by dshanske. View the logs.
3 weeks ago
3 weeks ago
I would be interested in a status for deleted that would return a themeable 410 or 451 page. I think that fits in with a Lot of the other use cases.
in reply to:
↑ 215
3 weeks ago
Replying to johnjamesjacoby:
bbPress has a few custom statuses:
These are basically states that a forum/topic/reply will find themselves in based on different criteria, and a moderator can force a state if they wish.
A state is really a collection of properties, not dissimilar to how roles have capabilities, and these properties need an easy way to build database queries and limit their visibility.
Several solutions come to mind:
- Implement like Roles & Capabilities via the wp_options table -- Doing it this way will force rigid states to roles -- not a good thin IMO -- and requires writing to the DB so should be done on a plugin activation, which does not work well for Git-based auto-deployments.
- Implement them using a register_post_state() function that streamlines and simplifies add custom states since they would not need to be stored in the database, but this is also rigid.
- Add a built-in 'post_states' taxonomy listing statuses and their respective states as child terms. This would allow users to be able to select a status for a post, or alternatively drill down and select just specific states for a post. The downside is that this is harder to specify in code because we need to make sure the statues and states are written to the taxonomy so should be done on a plugin activation, which does not work well for Git-based auto-deployments.
- Do #2 but store the states in postmeta fields with a key format maybe like '_states:publish:is_public' and a value of 1, and allowing the users to specify individual states per post as in #3.
Seems like what is needed for this would be a good list of use-cases in a central place (Google Sheet?) and both their statuses and respective states?
6 days ago
Please check my patch "12706.5.patch", which fixes exactly all the points mentioned in the description of this ticket.
As @ocean90 wrote "138 stars and nobody wants to work on it?" please review this patch and hopefully can be shipped with 4.6 after 6 years. ;p
Let's stop this "outside the lines" discussion and close this ticket.


text:
|Investment Range:
|Franchise Units:
|Franchise Fees:
|Financing Available:
|Liquid Capital:
|Training & Support:
At RaceWay our #1 priority is to establish long-term, mutually beneficial relationships with outstanding operators. Joining RaceWay is the best business decision you will make.
Financial Info (Click to Toggle)
|Investment Range:
|Franchise Units:
|Franchise Fees:
|Financing Available:
|Liquid Capital:
|Training & Support:
RaceWay Opportunity Information
Why RaceWay
At RaceWay our #1 priority is to establish long-term, mutually beneficial relationships with outstanding operators. Joining RaceWay is the best business decision you will make. We offer assistance and guidance. We provide you with the best high-traffic locations and competitive fuel prices. We take care of the fuel supply chain, so you can focus on creating new revenue streams for your business.
There's never been a better time to go with RaceWay
Who We Need
We're looking for individuals with:
Does this sound like you?
If so, we're excited to hear from you. Please apply now to see if you and RaceWay are right for each other! This is the first step towards the future you have always dreamed of.
RaceWay History
RaceWay's roots go back over 75 years to 1934 when Carl Bolch, Sr. opened independent gas stations in St. Louis, Missouri, under the name Carl Bolch Trackside Stations. His strategy was to be independent of major oil companies thus be able to consistently offer lower priced gasoline to the public. In 1959 he relocated and acquired the Oil Well Company of Opp, Alabama, which consisted of numerous independent stores located, for the most part, in rural areas of Alabama. The stores and the ones opened after them evolved into the early RaceWay concept: full-service stores opened in conjunction with small grocery stores.
in 1967, Carl, Bolch, Jr. the current Chief Executive Officer, joined the company in Montgomery, Alabama. He expanded the company's geography throughout the South and into Texas on the newly constructed interstate system and pioneered the concept of self-service gasoline in Alabama, Florida, and Georgia. Today the RaceWay brand has grown to almost 300 stores across 12 states in the Southeastern United States.
The company relocated to Atlanta, Georgia in 1976, and in 1979 adopted the brand "RaceTrac" for its company operated stores. Contractor operated stores, many of which were the Oil Well Company stores, became branded RaceWay. Today RaceWay has grown to almost 300 stores across 12 states in the Southeast with plans to open 20 additional stores in 2011.
"IMPORTANT: THE RACEWAY PROGRAM IS NOT A FRANCHISE. WE ARE NOT OFFERING FOR SALE OR SELLING FRANCHISES. Our operators are independent business owners, not franchisees. We do not represent ourselves as a franchise company nor do we intend to do so in the future. Please evaluate our program based on this fact. "
|Liquid Capital:
|Franchise Fee:
|Franchise Units:
|Financing Available:
|Training & Support:
All financial information is provided by the franchise, business opportunity, business for sale or other advertiser, and that information is relied entirely on for the truthfulness and accuracy of the information provided.
Registry website makes it easy for travel agents to earn commission while creating honeymoon experiences
In May 2007, Dean and Dawn Seifert purchased a low volume Minuteman Press design, marketing, and printing franchise from another couple that was retiring. Thanks to their hard work and by following the Minuteman Press franchise system, Dean and Dawn have successfully grown their business in Youngstown, Ohio, which continues to flourish nine years later.
CEO of World's Largest Hot Dog Chain Goes Undercover for Hit Series
Minuteman Press International is proud to announce 5 grand openings in the Philadelphia region. There was also a first quarter increase of 19% over the previous year in total sales volumes for the Philadelphia region. The positive growth is a testament to the ongoing local support that Minuteman Press provides to its owners in Philadelphia, as well as the useful products and services that Minuteman Press provides to the business community.
Nearly 30,000 franchisees were considered; only one per state was selected.
For more than 10 years, he worked in sales and finance. But as his family grew, he realized this type of job didn't really allow him the freedom and time he wanted to be able to provide to his wife and two kids—the world of sales had proven to be busy and non-stop.
When Maria and Aj Medina moved their Minuteman Press franchise to its brand new location at 1416 NE 4th Avenue in Fort Lauderdale, they knew they wanted to make a big splash.
Located at, 6522 Chapman Highway, Knoxville, TN 37920, Urban Air Knoxville is a 40,000 square feet award-winning family entertainment center and is set to open to the public early Fall 2016.
Urban Air set to open an Adventure Park in Fort Worth, Texas with Sky Diving, Ropes Courses and Indoor Roller Coaster along with its standard Trampoline and Warrior based activities.
The Minuteman Press franchise in Burbank racked up two prestigious awards from the Printing Industries Association, Inc. of Southern California as part of the 2016 PIASC Print Excellence Awards. Minuteman Press owner George Sagadencky was thrilled that his business was recognized as winners of the PIASC 2016 Award of Excellence as well as the PIASC 2016 Best of Category award.
See Below...
Browse for other Franchises in similar or related industries. Please see below.
Please Note: This RaceWay advertisement, and all other franchise opportunities, franchises for sale, business opportunities, businesses for sale, franchise financing providers, and other advertisements on this website should not be considered an offering or solicitation, and they are not recommended, endorsed, or approved in any way by Franchise Clique. All listings and advertisements on this website are submitted to Franchise Clique by the franchise, business opportunity, business for sale or other advertiser, and that information is relied entirely on for the truthfulness and accuracy of the information provided. Franchise Clique has no stake in these companies, and have not independently verified any of the information submitted, no responsibility for its accuracy or completeness is assumed by Franchise Clique. Persons submitting the inquiry form are under no obligation to purchase or otherwise utilize any services offered, they are simply requesting more information on the franchises or business opportunities listed. Please review the full advertisement before responding.
You currently have 10 franchises in your request list. This is the maximum amount that can be submitted at one time.
Please submit your information to continue.×

subset: commoncrawl


text:
Wii U Games
This page contains Lego City Stories Video Walkthroughs for Wii U called "Walkthrough Part 4" and has been posted or updated on Jun 6, 2013 by wyvernshido.
Sponsored Links
Boxshot & Details
- Developer: Not Set
- Publisher: Not Set
- Genre: Not Set
- Release: Not Set
- ESRB: Not Set
Video Walkthroughs
Walkthrough Part 4
Watch this step-by-step Video Walkthrough, which may help and guide you through each and every level part of this game.
Report Problem
Please Submit a Problem for any incomplete, non-working or fake cheat listed above.
More Video Walkthroughs
From: wyvernshido
From: wyvernshido
From: wyvernshido
From: wyvernshido
From: wyvernshido
From: wyvernshido
From: wyvernshido
From: wyvernshido
Back to all Cheats
From: wyvernshido
Stuck in this game? Set a specific, clearly defined question and let other gamers answer your question or view answers to previously asked questions. If you think you are an expert then please try to help others with their questions.
Latest Questions
Special assignment badge pieces
From: Redfive1984
From: Redfive1984
Total 1 Answers
Posted on: 08-22-2014
Posted on: 08-22-2014
Emerald train lego city
From: Amanda
From: Amanda
Total 0 Answers
Posted on: 05-04-2014
Posted on: 05-04-2014
How to get to Blackwell
From: shay88
From: shay88
Total 1 Answers
Posted on: 11-22-2013
Posted on: 11-22-2013
Jump into buses?
From: me
From: me
Total 0 Answers
Posted on: 05-25-2013
Posted on: 05-25-2013
Collect Video Evidence from Chan's Gang?
From: Ch4se
From: Ch4se
Total 0 Answers
Posted on: 05-25-2013
Posted on: 05-25-2013
Colour swopper?
From: marshi
From: marshi
Total 0 Answers
Posted on: 04-02-2013
Posted on: 04-02-2013
Ask / All Questions
Level 6, 2nd wheel
From: brendan
From: brendan
Total 1 Answers
Posted on: 03-29-2013
Posted on: 03-29-2013
Trailers & Gameplay Videos
Lego City Stories - Webisode 5 Meet Natalia Trailer
- Apr 6, 2013, Views: 259
Lego City Stories - Launch Quotes Trailer
- Apr 6, 2013, Views: 214
View All Videos
Lego City Stories - A Very Thrilling Tale Indeed Trailer
- Apr 19, 2013, Views: 247
More Options
Top Featured Games
- LEGO Star Wars: The Force Awakens, (PS4)
- Mirror's Edge, (PS4)
- Deus Ex: Mankind Divided, (PS4)
- Skylanders Battlecast Cards To Life, (AND)
- The Journey: Bob's Story, (PC)
- Paragon, (PS4)
- Mafia 3, (PS4)
- Bullet Force, (PC)
- Forestry 2017 - The Simulation, (PS4)
Games You May Like
- Lifeline: Whiteout, (iOS)
- Castles Of Mad King Ludwig, (iOS)
- Imbroglio, (iOS)
- Titan Quest, (iOS)
- NovaWing, (iOS)
- Mazes Of Karradash 2, (iOS)
- Nowhere: Lost Memories, (iOS)
- Dimension Painter, (iOS)
- Caterzillar, (iOS)
- Talisman: Horus Heresy, (iOS)
- Black Hole Joyrider, (iOS)
- My Koi, (iOS)
Sponsored Links


text:
Happy Birthday Shlomit by 1001GWatch
Beautiful idea and execution .
This is beautiful.
This is a lovely idea and well done!
So lovely composition dear Edie
well hello rezzan......how r u? and ty
Great Image..very creative!!
ty mark.......I did a layer on this....one of my watered down windows.....when I spray them hubby makes me clean them...lol
Awwwww!!!Ilove it!!!!!
a beautiful gift for a wonderful lady
Oooo love this one!!!
Lovely gift for dear friend
I believe she liked it lucila and ty for faving dear
Very pretty with the rain
Awww... stunning gift for dear Shlomit....
pretty indeed
Absolutely wonderful picture and gift!


text:
I recently built a 10.5" pistol, and it's a lot of fun
That's beautiful Pirate!
Something tells me that scope won't be on there for long.
oh you never know iwth him...
now you jsut need to do away with the stock and make it a pistol... :-)
say what you mean & mean what you say
im here to build stuff.... not cry about "how things used to be"YES, i work for TEC Tactical.. 07/02 SOT


text:
For the last several weeks, I've been tossing and turning at night. I'm getting "enough" sleep, but I wake up several times throughout the night to "change position" (jokes are too easy on that one ). My bed is very comfortable, I'm not hot/cold, and when I do wake up, I normally go back to sleep within 5 minutes or so. I get plenty of exercise... actually, it seems like the more exercise I get, the more I wake up during the night--it's increased as I've been riding my bikes more and more.
Just curious - anybody else have this rather annoying issue? I don't think sleep aids are the answer.


text:
Hi I downloaded frisco while looking at a screenshot which actually showed member's profile page.
I want to have the same profile header kind of thing on the main page of my buddypress site with a call of action. It looks like that the theme does not have an index.php file so I don't know where I should add html.
I am thinking about adding
<div id="item-header">
My html here
Before the content and the sidebar. Can someone please guide me where I should add this?


text:
« Western Architect Online | Main | Wright Plus 2012 Tickets Now On Sale »
It should also be noted that there will be an MCM homes tour in the Twin Cities area on Saturday (October 8th), including homes by Lloyd Wright and John Howe. The Loveness studio and cottage designed by Frank Lloyd Wright has unfortunately been withdrawn from the tour. Details at: www.docomomo-us-mn.org/modern-homes-tour-2011/.
The comments to this entry are closed.


text:
VANCOUVER, Wash. (AP) — Five archaeology students have been recording information from gravestones this week in Vancouver's 144-year-old Old City Cemetery.
The Columbian reports inscriptions are being lost to vandalism and weathering.
The college students' findings will help the Clark County Genealogical Society maintain the cemetery.
The project is part of the annual field school conducted by Doug Wilson, a National Park Service archaeologist based at Fort Vancouver.
Information from: The Columbian, http://www.columbian.com


text:
Fifth Harmony – Hero – The X Factor
Fifth Harmony (formerly 1432 and LYLAS) sang "Hero" on The X Factor Top 12. Watch the video and listen to the MP3 here.
To vote for Fifth Harmony: 1-855-THE-XF-08
Britney Spears: I'm impressed.
Demi Lovato: Your vocals killed it.
L.A. Reid: I'm happy for you.
Simon Cowell: Maybe there's a chance 5 girls may win this show.
Latest News on The X Factor
All News on The X Factor
Follow me on Facebook! • Follow me on Google+


text:
It's been far too long since we featured a "Funny Picture" here at the Comedy Examiner's Office, so here it is, your welcome to the weekend: More weirdness from Japan. Seems like every other day, someone's sending in some bizarre game-show clip, some news report from Japan that involves a dude dressed in some sort of freakish animal outfit, some report on a dude trying to marry a cartoon...something. We harbor no ill-will towards Japan here at the Comedy Examiner's Office...we just don't know what the hell is going on over there. If you have a theory, feel free to respond in the comments section below folks-- particularly if you have an explanation for the photo above. Otherwise, check out these other recent Comedy Examiner articles as you drink yourself into Saturday...
COMEDY FANS, REJOICE: HBO RENEWS "THE RICKY GERVAIS SHOW" FOR A SECOND SEASON (WITH VIDEO)-- in which we learn that HBO love all of us, especially the Comedy Examiner. If you haven't checked out "The Ricky Gervais Show" yet, check out the clip in this article. I dare you not to laugh.
GLENN BECK SAYS THAT HE WAS JOKING WHEN HE CALLED JAMES CAMERON "THE ANTI-CHRIST" (WITH VIDEO)-- in which Glenn Beck says that he was just kidding when he called James "Avatar" Cameron the Anti-Christ. Oh, Glenn Beck: you are such a card. And a D-bag.
DAVID CROSS SET TO RELEASE NEW CD/DVD ALBUM "BIGGER AND BLACKERER" THIS MAY (WITH VIDEO)-- in which we learn that David Cross is about to drop a new album. If you've never heard any of his standup, check out the clip in this article. Just don't do it at work. Or near children. Or your parents.
TRAILER FOR EDGAR WRIGHT'S "SCOTT PILGRIM VS. THE WORLD" ARRIVES ONLINE, IS AWESOME (WITH VIDEO)-- in which we learn that Edgar Wright has made three very kick-ass movies in a row. Sure, that's prejudging based on this trailer, but check it out for yourself and tell me I'm wrong.
(photo: break.com)