Hi,
I have just installed CP for the first time and added a few plugins and themes.
Have set debug on true and notice that quite a few themes are generating this warning:
Deprecated: Function add_theme_support( 'html5' ) was called with an argument that is deprecated since version CP-2.0.0! HTML5 is the default.
As far as I know this isn’t deprecated in WP yet, so why doesn’t CP simply ignore this, instead of returning a warning?
Guido
Because CP deprecated it.
Go to functions.php in the THEME and comment out the line add theme support(html) and you are ok.
Hi,
Thank you for your reply.
I understand what to do, but in case of a theme update I must do it again.
I thought CP was a duplicate of WP, without the annoying blocks.
But apparently there are more differences between the both.This way you might cause more problems in the future, when installing plugins/themes from org.
Guido
CP isn’t just WP without blocks. It’s WP without bloat. Sites should be HTML5 by default these days, so that’s why that call is unnecessary. The deprecation notice isn’t seen by anyone except admins with DEBUG turned on.
Other examples of bloat removal: no jQueryUI, no Thickbox, no HoverIntent, no ClipboardJS. These have all been replaced either by native HTML5 elements or simple, vanilla JavaScript.
As a result, CP is orders of magnitude faster, and it’s also much more accessible for users with disabilities.
Hi Tim,
Understood! I’m a CP newbie, still learning.
Because CP uses the repository from WP you might want to consider ignoring deprecation notices for stuff that isn’t deprecated in WP yet. To avoid questions and confusion. IMO a site should not have notices / warnings, not even a single one.
Guido
We tried that in the first few years of CP. It just led to atrophy. WP is going in another direction and it’s ignoring all the legacy stuff that needs updating. If we don’t add deprecation notices in CP, no-one will ever update. So this is the direction we’ve decided upon.
deprecation notices serve to devs to know what they can do and what won’t work anymore after a certain deadline. they are needed.
that said, just do a child theme de-registering the specific add theme support for html instead and keep the parent untouched.
Deprecations are thrown only if WP_DEBUG is true, and this is not an usual setup for production sites.
But if you (like me) like to keep debug mode on and got annoyed by query monitor complaining at every page load it’s simple to filter out what you want/don’t want to see.
Hi,
In my upcoming release of “ClassicPress Plugin / Theme Tester”, I’ll be showcasing “Deprecated Notices” along with a growing number “CP Dev Standards-based Notices”.
The goal is to help developers keep up on changes, and build better Plugins and Themes by having their stuff run through our tester, and use the output to get ahead of potential bugs whether it be security, deprecation or performance.
Thank you all for your replies.
@tpnsolutions
The “ClassicPress Plugin / Theme Tester” will be listed at the Plugins page soon?
Guido
It’s actually a “platform” so to speak, whereby it deploys a vanilla CP install, runs through installing all of the “official” (from CP Directory) plugins and logs any errors that occur based on standard debugging feature of CP, and a few extra debug specific plugins (for additional insights).
It then creates a log with relevant details about the tests primarily focusing on those with failed tests.
*** So it’s not exactly a “plugin” itself but a tool that runs server-side in a semi-automated manner. ***
The logged errors are then published to a web-based report where they can be reviewed. The goal is to show the error, and potentially a way to address it (directly or indirectly). Known common errors may have a whole write up in time from more experienced devs on how to address, other issues may simply refer to documentation on topics like “depreciation” and such…
The whole concept, and usage is a work in progress, so this is sort of where I’m at presently.
Can someone post a reminder of where I can find the conditional statement to support for the version of CP <2.0 ?
The relevant function is classicpress_version()
Thx, so:
if ( function_exists( 'is_classicpress' ) && version_compare( '2.0', $cp_version, '<' ) ) {
add_theme_support( 'html5', ........
seems to be the correct statement. taken that $cp_version is already global. classicpress_version was not recognized but I found this How do I detect ClassicPress (vs WordPress) and the latest version? which seemed to help solve my trial with checking for html5 support.
I would have thought you could do something simpler, like this:
if ( classicpress_version() && classicpress_version() < 2.0 ) {
I’m not sure if the function returns a string or an integer; if the former, then it would need to be:
if ( classicpress_version() && classicpress_version() < '2.0' ) {
Looks like it is a string https://www.youtube.com/watch?v=xszyCxEZy-A time=2:16
var_dump(classicpress_version)
Better checking if classicpress_version is declared, then use version_compare to compare the output.
Also require_once version.php should be useful.
@simone can you extrapolate a bit more on this (usage example) or maybe go ahead and PR to the hello-theme
And I think the comments for this piece should say
/* Not used in ClassicPress > 2.0 to output HTML5. */
This code can be used in theme’s functions.php.
if ( version_compare( function_exists( 'classicpress_version' ) ? classicpress_version() : '0', '2', '<=' ) ) {
add_theme_support( 'html5' );
}