Plugins using date('U') or time() may have been expecting a timezone offset in previous versions of WordPress, and depending on the server setup this was true. This has changed in 3.0. We now tell PHP to not factor in timezones to ensure maximum portability across PHP versions and server setups, thus you’ll end up with UTC time when using those functions.
Use current_time('timestamp') to get the Unix timestamp with a timezone offset.
Some pre-release to do items:
Another reminder that escaping rules for options and transients changed a bit in 3.0.
Best should be to clean up code in
wp-login.php
$user_login = $user_data->user_login;
$user_email = $user_data->user_email;
and in wp-pluggable.php (several times)
$user_login = stripslashes($user->user_login);
$user_email = stripslashes($user->user_email);
btw as i am reviewing mails in pluggable.php and hooks on mails in wp-login.php
in wp-login.php we have :
if ( is_multisite() )
$blogname = $GLOBALS['current_site']->site_name;
else
// The blogname option is escaped with esc_html on the way into the database in sanitize_option
// we want to reverse this for the plain text arena of emails.
$blogname = wp_specialchars_decode(get_option(‘blogname’), ENT_QUOTES);
in pluggable.php, we have :
// The blogname option is escaped with esc_html on the way into the database in sanitize_option
// we want to reverse this for the plain text arena of emails.
$blogname = wp_specialchars_decode(get_option(‘blogname’), ENT_QUOTES);
what is the right sequence of code ?
Please could you open a ticket for this.
The special_chars_decode probably needs applying in the is_multisite() case above for the same reason it was applied in pluggable.php
done #13618
done #13618
not sure this line
$blogname = $GLOBALS['current_site']->site_name;
is usefull !?
Check out register_nav_menu(), register_nav_menus(), and the theme_location argument to wp_nav_menu() for a means of associating custom navigation menus with particular “locations” in your theme. The Twenty Ten theme offers an example.
During plugin activation, WP 3.0 checks to see if the plugin generates any output. If any output is generated a warning is shown to the user. Generating output during activation is usually a good sign that the plugin has spaces before the opening php tag or that it generates warnings. This extra output can break feeds and cause “headers already sent” warnings. Please test your plugins against 3.0 and make sure your they do not generate unexpected output.
The whitespace issue can usually be alleviated by not ending your script with ?>
It seems wrong, but Zend Framework, Drupal and many other projects have adopted it as a standard, and nobody actually has a problem with it from a technical angle from the PHP side when I’ve ever asked.
I am having the same problem during activation.When i try to activate the plugin i get the message “The plugin generated 560 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.”
So where can i edit the plugin to get rid of this.It works in all of the lower wp-versions.
If you are still having an issue, I found a spot in a plugin I was developing, which may be the same issue with this plugin. Check that the “add_option” method does not contain a “description” parameter of, if it does, that it is an empty string or null. “Description” was deprecated with version 2.3 of WordPress. Good luck.
Hey guys I’m having the same issue. However, I’m getting the following message:
“The plugin generated 3 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.”
I’m crap at editing code, was this what you was hinting at Jeff Lamberth?
Please advise.
We have a better phpDoc page. It is regularly updated for trunk, the latest branch and the latest tag. Thanks to Barry.
And if you want any other projects trunks you might find them here: http://phpdoc.ftwr.co.uk and here http://phpxref.ftwr.co.uk
Thanks for keeping it in sync, I rely on it heavily now that we’re updating our WP book.
It would also be nice to have an official site for hooks, lie this one — or at least an equivalent for trunk 
Hooks and filters aren’t documented in sourcecode like phpdoc but some hooks / filters are in codex.
Yup, I knew that
But as you say, it’s partial, and it’s hard which are new in 2.8, in 2.9, in 3.0.
If Adam Brow can do it, there’s no reason this can’t be done officially
I probably wont be able to join in again, I’ll be on the road, i’ll keep up on the mobile however.
Kind of. I’ve re-tooled http://core.trac.wordpress.org/report/26 so we can now track some stuff we keep in the theme and plugin repositories. Tickets in the “WordPress.org site” milestone are shown, and are then grouped by component — Themes (for Kubrick, Classic, and also Twenty Ten when 3.0 is out), Import (for the importers), and WordPress.org (the original scope of the milestone).
I’ve moved Kubrick/Classic tickets to the Themes component, and punted a confirmed importer bug out of 3.0 as well.
Suggest agenda items for May 27th 2010 dev chat
Progress to plan
Blocker review – Hopefully this list will already be empty! https://core.trac.wordpress.org/report/18
With the introduction of the new custom post type panels, a whole slew of adjustments must be made to avoid cross-referencing “Post” or “Page” in the UI. 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 URL 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.
My first paragraph mentions adding support for customization, this is option #2, where as option #1 is genericizing (http://core.trac.wordpress.org/ticket/13539) them.
Nevermind, Nacin mentioned this should be handled within the ticket itself, updated.
Revert two large sets of changes that were hurriedly introduced in the last few days.
Relevant tickets:
http://core.trac.wordpress.org/ticket/11274
http://core.trac.wordpress.org/ticket/13467
I will open a ticket to explain why I propose the reversal. (I will add the link here when the ticket is ready.)
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 ticket I need to read up more on
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.
Why I propose reverting the changes:
MU upgrade notification, distro, automatic upgrade, etc.
How about finding a way to communicate with theme repository plugin author’s their plugin needs updating and deprecate / remove old plugins, i.e. clean up the plugin repository. -/2 revisions, 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.
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 PHP 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
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.
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-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 field 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 blog 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 core 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.
“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 plugin and functions.php, custom post types are not for them.
Like multisite 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 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.
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 plugin.
Philip – yes, a plugin is still the wrong place to set them up, but it’s probably going to be less error-prone than functions.php. WP-admin would be the right place, surely?
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 multisite.” They risk being abused by those who aren’t prepared for what comes with them.
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 (http://codex.wordpress.org/Function_Reference/register_post_type) without providing authoritative “how to” instructions; even Matt mentioned one of those sites in his WordCamp 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.
New IRC policy suggestion. Whenever the folks at #wordpress send someone over into #wordpress-dev, we send them back, and one or more of us need to bite the bullet and jump back over there and see if we can help.
This has a few advantages. One, people who hover in #wordpress can learn, instead of always sending people our way. Two, we can keep the core development channel clean of chatter — including the logs, which some of us do try to read the scrollback for (I’ve stopped lately, but I used to always make sure I read the logs in full). Three, this then gets logged in the proper channel. Four, we also don’t raise expectations that #wordpress-dev is for general development. If we dip into #wordpress a bit more (I’m going to idle in it now, I think), we’ll have support questions in #wordpress-dev less, and it will increase our productivity.
I know sometimes we like to adopt odd questions and challenges that come into #wordpress-dev — I’m as bad as anyone on this. But after spending an hour (and others before me) and many dozens lines of logs, we discovered that a recent issue came down to a bad APC configuration setting. [last line edited for clarity]
This wasn’t the standard thing to do already?
Well, yes
I’m all for this, I dont idle in #wordpress due to the noise, But if someone comes to wordpress-dev or PM’s me/mentions it in #wordpress-dev, I’ll happily jump over to #wordpress to help someone out.
I think what happens is that folk like you leave so even if something half-you,know reasonable comes up it either doesn’t get responded to or just degrades into noise. Backwaters become swamps.
So what I’m thinking is that anything that get’s initially responded to in -dev and moved over into #wordpress has the effect of generating a bit of light. (I used to be on IRC every day with another big project OMG a decade ago.)
By “moved over” I mean talked through, so stuff that isn’t -dev, strictly speaking ends up being dealt with while keeping the total payload there smaller and giving #wordpress a nudge in the right direction.
I try to read all the logs, too, and it doesn’t seem like this is a frequent problem. Being a frequent problem is a necessary (though still not sufficient) condition for creating new policies.
Does your IRC client use color-coded usernames? Mine (XChat) has that as an option, so it was very easy for me to skip over the remainder of this particular conversation once I got the gist.
This sounds like sound good practice to me.
I do idle in #wordpress but barely read it
I gave up trying to read the whole log of any channel a long time back!
there should be no connections between those two channels but the user (as developer).
arena, and 
gaurab and one other person are discussing. 
Marcus 9:46 pm on May 28, 2010 Permalink |
Was Turbo taken out of WordPress 3?
Ryan Boren 8:19 pm on May 29, 2010 Permalink |
Yes.
Montana Flynn 6:53 pm on May 31, 2010 Permalink
Any reason why?
Peter Westwood 6:47 am on June 1, 2010 Permalink
Turbo was disabled as a UI options as Google Gears is no longer supported upstream.
If you already have Turbo enabled it may still work but also it may not.
Andrew Nacin 3:51 pm on June 1, 2010 Permalink
We’ve kept the manifest current. In recent testing, Gears still worked for me if enabled prior to an upgrade.
hakre 12:45 pm on May 29, 2010 Permalink |
For your last last, I made a suggestion which might be wise: #13067
Nikolay Bachiyski 10:20 pm on June 1, 2010 Permalink |
Importers now have domains, POTs and the rest of the i18n goodies. I just need to get them in GlotPress.