I have decided to make sure some of my themes that are represented over at WordPress Theme Directory to be compatible with ClassicPress. Starting version 2.0.0, you can now use White Spektrum with ClassicPress.
You can go to the Appearance → Themes and search for White Spektrum
Enjoy.
It’s great to see themes that retain the “classic blog” look and functionalities. I will definitely try out your themes one of these days.
And the fact that you are making them compatible with ClassicPress sure makes using them a future-proof choice.
yeah! i think that’s the whole point of me retaining the look and feel is because of ClassicPress. I have more to come.
I was testing it for my site and I think it is great.
Only thing that I can suggest is adding support for custom logo in the customizer and the checkbox to show/hide site title/tagline.
That detail would make ti very modern and a very good multipurpose theme IMHO.
What did you have to change?
Aren’t most themes in the WP repo compatible with CP?
well when i build my framework, it was set to WP 5.0 or higher, so it won’t activate with CP 4.9, so i made that change and rebuild the framework. My entire theme files are not exactly what you call standard since its mainly build with laravel container.
For CP “compatibility” to WP “compatibility” one has to make the theme, first, WP passable. This includes adding, at minimum:
<body <?php body_class(); ?> and <?php wp_body_open(); ?> tags into the header file. Also just about everything needs to pass the Review (Theme Check) including having support for blocks. add_theme_support( 'wp-block-styles' );
So, to avoid having to pass a theme on WP(.org) my approach is to ONLY create CHILD themes of existing themes. The logic is: I don’t have to make a theme WP > 4.9 version ready. If the parent theme is passed as WP > 5, I can ignore EVERYTHING about Gutenberg (except if the parent theme does not have; at minimum; the last noted snippet for block styles).
IMO using any theme that is part of the wp repo would kind of be counter-productive to CP philosophies (whatever that is [as joyously once said]). Maybe one reason CP needs a repo. BUT creating child themes with the tag ClassicPress should help identify CP themes. I have not try it yet, but, might do this for my twentyeleven child theme and let you know. But I thought someone said the CP tag was not invalid for Theme Check.
That’s backwards from what we are talking about…
Both Ben and I have reviewed themes at WP. I don’t think block styles are required. (Most themes don’t have them…)
I am in favor of a theme directory that does not include child themes.
At the WP repo, you can only use the pre-defined tags. But you can mention ClassicPress in the description, so the search will find it. My theme does this.
add_theme_support( 'wp-block-styles' ); is optional and is not required… it is recommended as theme check states.
we are talking about themes from WordPress directory being compatible with ClassicPress.
Theses are all recommended and not required
RECOMMENDED: No reference to nav_menu's was found in the theme. Note that if your theme has a menu bar, it is required to use the WordPress nav_menu functionality for it.
RECOMMENDED: No reference to register_block_style was found in the theme. Theme authors are encouraged to implement new block styles as a transition to block themes.
RECOMMENDED: No reference to register_block_pattern was found in the theme. Theme authors are encouraged to implement custom block patterns as a transition to block themes.
RECOMMENDED: No reference to add_theme_support( "wp-block-styles" ) was found in the theme. It is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_theme_support( "responsive-embeds" ) was found in the theme. It is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_theme_support( "custom-logo", $args ) was found in the theme. It is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_theme_support( "custom-header", $args ) was found in the theme. It is recommended that the theme implement this functionality if using an image for the header.
RECOMMENDED: No reference to add_theme_support( "custom-background", $args ) was found in the theme. If the theme uses background images or solid colors for the background, then it is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_theme_support( "align-wide" ) was found in the theme. It is recommended that the theme implement this functionality.
RECOMMENDED: No reference to add_editor_style() was found in the theme. It is recommended that the theme implement editor styling, so as to make the editor content match the resulting post output in the theme, for a better user experience.
RECOMMENDED This theme doesn't seem to display tags. Modify it to display tags in appropriate locations.
RECOMMENDED This theme contains no sidebars/widget areas. See Widgets API
RECOMMENDED No reference to the_post_thumbnail() was found in the theme. It is recommended that the theme implement this functionality instead of using custom fields for thumbnails.
RECOMMENDED .wp-caption css class is recommended in your theme css.
RECOMMENDED .wp-caption-text css class is recommended in your theme css.
RECOMMENDED .sticky css class is recommended in your theme css.
RECOMMENDED .gallery-caption css class is recommended in your theme css.
RECOMMENDED .bypostauthor css class is recommended in your theme css.
Exactly. Maybe I mis-structured the point. But the point to take home is that all the highlighted “requirements” in your thread are exactly the ones we would hope to not require (with obvious thumbnails etc support).
Head requirements may be a good discussion topic. Things like pingbacks and emojis being left out of head…
I don’t know how to split this off into its own topic (but it should be).
What is in <head> is really not part of a theme’s job. I address the pingback issue in my petition’s PR.
not sure where you get thumbnail is required, again thumbnails are optional.
…etc. <— anything that you would most likely put in your functions.php file like HTML5 support and custom logo upload, ETC. Apologies; I could have been clearer.
Not sure but maybe I am being lazy or rushed for time right now, but is there a Forum section for a Theme Review (Team). I can obviously view the Themes Topic but maybe you have more insight on what the origin of Themes Repo and or (a)ny Theme Review Team system which is present.
I am working with plugins currently to help review plugin. But I wouldn’t mind helping in theme review as I have two CP specific themes ready.
The head topics would definitely be a good thread to start.
As a matter of facts it is time to have a theme dir, I agree.
We do have themes for CP and people look for it.
The Dir already has a (not visible) section for themes, I am not sure what is missing to have it working, Wade will need to tell us when he’s available.
Theme review and submission standards will need to be written, in the same fashion as our plugin review standards all visible here Plugin Guidelines | ClassicPress Documentation
They aren’t going to be a lot different, but obviously need to be rewritten.
That’s partially already been done, see
Draft Theme Directory Guidelines
Draft Theme Directory Adoption/Takeover Guidelines
Draft Theme Directory Submission Guidelines
Draft Theme Directory Review Process
Draft Theme Directory Vulnerability Reporting Guidelines
So what we need is the DIR to accept themes.
This can unfortunately only be done, or at least exposed by, Wade.
I have created a task for him to review this when he’s available.
The directory for themes, is it going to be the same as plugins where it just have a list of themes and it just redirects the specific github page… could we just do what WP do and jsut create a new plugins api and themes api or is that too much work since CP would have tgo host those themes/plugins
As mentioned I don’t know what’s exactly needed to have the „same“ for themes as for plugins but we will surely have (when we have it) the „same“ for themes as we do for plugins.
This means Directory listing and api.