Peter Westwood 7:25 am on May 22, 2010
Tags: agenda ( 1,078 )

Suggest agenda items for May 27th 2010 d…

Suggest agenda items for May 27th 2010 dev chat

#agenda

Peter Westwood 7:26 am on May 22, 2010

Progress to plan
Peter Westwood 7:27 am on May 22, 2010

Blockerblocker A bug which is so severe that it blocks a release. review – Hopefully this list will already be empty! https://core.trac.wordpress.org/report/18
sc0ttkclark 8:35 pm on May 25, 2010

With the introduction of the new custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. panels, a whole slew of adjustments must be made to avoid cross-referencing “Post” or “Page” in the UIUI User interface. Nacin has made a large amount of adjustments for this today, but there are more specifically referencing “page” that I’ve noticed under the “Attributes” section within the “Order” field description “Pages are usually ordered alphabetically, but you can put a number above to change the order pages appear in.” and under the “Discussion” section within the “Allow trackbacks and pingbacks on this page.” checkbox. The use of “page” within these areas should be given additional support for customization by register_post_type.

In addition to this, use of “Insert this Post” buttons throughout the Media Library Thickbox have long been confusing for anyone adding media to “Pages”, with the addition of the new custom post type panels this confusion will only grow. I propose adding additional parameters to the Media Library Thickbox URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org that refer to the specific post_type the popup window is to be referencing, and then retrieving a new label within the register_post_type “labels” definition.
- sc0ttkclark 8:38 pm on May 25, 2010
  
  My first paragraph mentions adding support for customization, this is option #2, where as option #1 is genericizing (https://core.trac.wordpress.org/ticket/13539) them.
  - sc0ttkclark 8:40 pm on May 25, 2010
    
    Nevermind, Nacin mentioned this should be handled within the ticketticket Created for both bug reports and feature development on the bug tracker. itself, updated.
    
    https://core.trac.wordpress.org/ticket/13539
demetris 4:40 pm on May 26, 2010

Revert two large sets of changes that were hurriedly introduced in the last few days.

Relevant tickets:

https://core.trac.wordpress.org/ticket/11274

https://core.trac.wordpress.org/ticket/13467

I will open a ticketticket Created for both bug reports and feature development on the bug tracker. to explain why I propose the reversal. (I will add the link here when the ticket is ready.)
- Peter Westwood 8:35 am on May 27, 2010
  
  The help text is really important and we have had it coming for a long time so I don’t want us to lose out on it.
  
  The other ticketticket Created for both bug reports and feature development on the bug tracker. I need to read up more on
  - demetris 8:49 am on May 27, 2010
    
    I am not saying the help panels are not important.
    
    And if they are important, that’s all the more reason (especailly so considering the extent of the changes) to do it early in a dev cycle.
    
    I know these changes were planned for v2.7. They did not make it then. We could have introduced them early in 2.8, early in 2.9, or early in 3.0. Now it is too late for 3.0.
    
    They are also implemented in a way that is bad in my view (and, more importantly, will remain bad for a long time if we persist on introducing them so late in the dev cycle).
    
    Also, have you checked the number of new strings lately?
    
    1154 as I am writing this.
    
    Yes, that’s the number!
    
    One thousand one hundred and fifty four.
- demetris 8:15 pm on May 27, 2010
  
  Why I propose reverting the changes:
  
  https://core.trac.wordpress.org/ticket/13584
Ron 6:20 pm on May 26, 2010

MU upgrade notification, distro, automatic upgrade, etc.
Philip M. Hofer (Frumph) 9:40 pm on May 26, 2010

How about finding a way to communicate with theme repository pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party author’s their plugin needs updating and deprecate / remove old plugins, i.e. clean up the plugin repository. -/2 revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., the search for a valid plugin can bring up plugins that are so outdated it could cause problems with 3.0 and all the things that are deprecated.

Suggestions could include having someone generate a list of the not-working and auto-send a message to the email attached to the account holder of that plugin.

I am available as well to help with it, whatever decision it is to determine plugin removal.
yes we work 12:06 am on May 28, 2010

Sorry – this probably isn’t the exactly 100% best possible place for this, but we wanted to ask about a potentially big problem we think we’ve found with the implementation of custom post types that isn’t being talked about much:

Custom Post Types are really going to change the way WP is used, but most people so far seem to recommend that custom post types be registered in functions.php – we can’t help but feel that this is wrong and risky: these definitions aren’t really part of a site’s theme, rather they form part of its underlying data structure. If you started changing the post_type definitions in functions.php once a site was already populated with data, wouldn’t you quickly lose touch with the contents of the underlying database, with no way of cleaning it up or getting back to where you were?

And if you switch graphic theme (as WP users do) why should you lose all your custom post types? Surely custom post-type definitions (and likewise custom taxonomies) ought to be theme-independent, allowing the user to change theme but maintain the site’s content and hierarchy?

Moreover: isn’t it wasteful to have these definitions as PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher code which executes repeatedly and redundantly every time a page request is made?

Have we missed something? Is it just the way very visible sites like wpengineer, nettuts and kovshenin.com suggest setting up post types that needs clarification? Is there a better way than using functions.php? Is this the right forum to discuss it, and if not, where is?

Best wishes,
Andrew& Thomas – Yes We Work
- Jane Wells 8:11 pm on June 10, 2010
  
  Andrew & Thomas: Custom post types are meant as advanced functionality. Anyone thinking about using custom post types should be more than capable of adding to their theme’s function file. Anyone not capable of such (or capable of asking someone to add it for them) is very likely unclear on the purpose of post types or the implications of using them (not included in posts feed, etc). A site relying on custom post types — for example a product catalog, real estate listings, etc — is unlikely to change themes for the heck of it without making sure their content will be displayed.
  - yeswework 12:01 pm on June 11, 2010
    
    Yes, custom post types are an advanced functionality; in a hypothetical ideal world, anyone considering using them would be a perfect balance of information architect, database administrator, php developer and site tester, but that still wouldn’t mean that the functions file, or in fact any file in the theme, is the correct place to initialise or edit the structure of custom post types, because…
    
    A) WordPress is structured around the premise that changing theme is an easy matter and largely an aesthetic choice (hence the theme directory and the easy, one-click “activate theme” functionality). People expect it to work a certain way, and this new feature is counter-intuitive. Furthermore, implementing custom post_types doesn’t disable the theme switching feature – which might be a small safety mechanism. Advanced users won’t make the mistake, but the rest of the WP userbase might, because that’s what WP has made them expect.
    
    B) the fact that a simple change to functions.php renders data inaccessible not only to the front-end theme, but also to wp-adminadmin (and super admin), doesn’t have many common precedents in WP. Isn’t it the CMS back end’s task to at least ensure you can see/access all your data there, even if not on the public side of the website. Otherwise, how can you keep track of what your theme SHOULD or COULD be showing?
    
    C) Initialising post_types and their features in a theme file jars with the usual common sense decision of WP and other CMSs to separate the Business Logic from the Presentation Layer.
    Data structure (adding a custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. to a post, or setting up a custom post_type) is determined by Business Logic, not by the Presentation Layer of a theme: that is to say, you need to set up real estate post_types because your business is real estate, not because the theme you use for your blogblog (versus network, site) sets them up. Then it’s up to the theme to make your data (ie, the real estate records you’ve entered via wp-admin) visible/searchable at the front end. Obviously the need to display them is closely linked to the need to set them up in the first place, but the direction of the logical flow is important in determining where the setting up should be done… ie, not in functions.php.
    
    D) WP functions are often deprecated, meaning functions.php and plug-in files can quickly become unchained from WP (unlikely, we know, because WP dev do a very good job of catering for deprecated functions in new releases; but possible and, in this case, dramatic if it were ever to happen).
    
    In summary: if implementation of custom post_types were via a new part of wp-admin, the risks of data loss, user confusion and deprecated function calls in 3rd party files would be mitigated or eliminated, which would be to everyone’s advantage.
    
    PS. As we mentioned in response to Andrew Nacin’s comment, initialising custom post_types via a plug-in (unless it’s canonical and therefore managed at the same level as WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. code) is hardly any better, but at least you half-expect a plug-in to make some changes to what you see in wp-admin.
  - Andrew Nacin 8:52 pm on June 12, 2010
    
    “the rest of the WP userbase” should not be generating post type code using helper plugins. I’ve never really understood those, because really custom post types are so much more than just registering them in order to be able to truly use them. If the user doesn’t know the difference between a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and functions.php, custom post types are not for them.
    
    Like multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site frankly, these are not for the faint of heart. Post types are for advanced functionality and a LOT more is required than simply registering them to fully utilize their potential, particularly when catering to the various use cases. To assume otherwise is naive.
    
    Simply adding register_post_type() code may be enough to transform your adminadmin (and super admin) area, but it doesn’t do anything for your frontend handling, and developers and users need to understand that they need to take what we’ve provided and run with it to suit your individual use case.
    
    Taking this further into 3.0 changes, I’ve seen some theme developers almost threaten that they’ll just use wp_list_pages instead of menus based on perceived weaknesses. I can only think that based on their use case they describe, *yes*, that IS what they should be using.
    
    For us to add this, we’d not only need to account for the templating aspects, but the rewrite aspects, and the query aspects. And we have to figure out things like slugs and such, not to mention that it would only encourage use (overuse) of post types in situations (or experience levels) that do not call for them.
    
    Any plugin developer can implement the proper rewrite rules for their use case. And we want to see what plugin developers come up with, otherwise we risk overthinking it. Thus, we’re leaving it for 3.1.
- Philip M. Hofer (Frumph) 8:18 pm on June 10, 2010
  
  Theme specific custom post types that utilize archive and search functions dependent on those post-types would rather them as part of the theme instead of an additional pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
  - yeswework 11:46 am on June 11, 2010
    
    Philip – yes, a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is still the wrong place to set them up, but it’s probably going to be less error-prone than functions.php. WP-adminadmin (and super admin) would be the right place, surely?
- Andrew Nacin 10:21 pm on June 10, 2010
  
  And also, for what it’s worth, we’re not exactly telling people to use functions.php; those are coming from elsewhere. I think we’re planning to do a “When you shouldn’t use custom post types” post, probably in the same vein as “When you shouldn’t use multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site.” They risk being abused by those who aren’t prepared for what comes with them.
  - yeswework 11:51 am on June 11, 2010
    
    YOU (plural) may not be saying to use functions.php, but almost all the highly visible sites that deal with developing in WordPress ARE saying that, and WP.org links to those exact sites from the register_post_type page in codex (https://codex.wordpress.org/Function_Reference/register_post_type) without providing authoritative “how to” instructions; even Matt mentioned one of those sites in his WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. address, so we assume it’s what most people – especially casual developers – will do. Writing a “don’t do this” post is not much of a substitute for a “do this” post, is it? If one were looking to implement an exciting new feature of a cms on a site, one would only read a “don’t do this” article once one had already made the exact mistake the “don’t do this” article was trying to warn against.

Comments are closed.

Welcome!

Communication

Suggest agenda items for May 27th 2010 d…

Welcome!

Communication

Share this:

Site resources