I agree with the idea behind this choice but the application is almost always bad.
If you move from restaurant-theme to pub-theme likely dishes from restaurant-plugin are displayed poorly and so you must move to pub-plugin your content.
And - without speaking of locking users to a specific theme - what when xyz-theme has great support for beautiful-slideshow, and then you move to super-theme where only smartest-slideshow integrates smoothly?
Not at all - these are the kind of nuances that need to be discussed/looked at from the end user’s point of view. Development should be to done as to meet the needs of end users
It is also the reason not to implement too much of particular plugin support in any one particular theme. The beauty of the Genesis framework is it entirely pushes for the use of a child theme and therefore each child theme a niche theme with the framework having no lock per se except for those mentioned above.
Part of my proposal is that the framework would for example include support for Classic Commerce if it is active and then the child theme would be responsible for the styling of the output. Again, the support code only kicks in if the plugin is active.
As for SEO - this data must always remain portable and accessible to the site owner irrespective of what theme they use. Having it this in the theme is what is termed as vendor lock in.
This is what I thought I had seen; sorry if I misinterpreted it to mean that it is condoned by the ClassicPress project.
I prefer the restriction of themes handling only the look and feel, because they can be switched at any time, including programmatically (on each page and by the user). If you’ve ever had to try to keep a client site going that has a theme with a CPT that has been hacked, you’ll understand better.
Yes, there is a difference. Themes are active on every page load, so they are targeted for hacks. Plugins have activation and deactivation hooks, which themes don’t, so they are better suited to defining things like CPTs, where they can do the flush_rewrite_rules at the correct time.
Themes are also loaded after plugins, so are too late for some things.
If someone wants to develop a restaurant theme, great, however, adding plugin functionality (ie, CPTs) is the wrong way every time. Instead, (such) theme developers need to realize that they’re not developing themes, they’re developing a suite of products designed to work together and they should just call it what it is. Calling it a theme does a disservice to the end-user who probably doesn’t realize anything about theme-lock, the reasons why this is a bad idea, or that they’ll possibly be stuck paying someone later to undo the damage.
Genesis takes it upon itself to remove the site header meta tags i.e. this line (plugin territory). remove_action( 'wp_head', 'wp_generator' );
I made the inevitable mistake of updating to the 3.x branch and didn’t save a copy of 2.10.1
If you have a copy and can let me know what the changelog says I’ll take a look into it if there’s a bug or two.
This might be worth looking at. But it may not be necessary in the future if most of the things requiring a DB upgrade are being/to be removed? What business does a theme have upgrading things in the database anyway?
As @zulfgani states, this theme is not an official ClassicPress project. Classic Elements is currently a ClassicPress research project, and that is not “official” either - it is primarily a space for people to explore ideas.
Lots of people use Genesis, and having a fork of it available to our community is a good thing.
Fully agree with this.
Now back to theme guidelines for a second: The problem I see with this is that you can no longer separate the design from the functionality. What if I like the way this restaurant theme looks, but I don’t need any of the CPTs or other stuff?
I understand why you built it this way (third-party theme marketplace), but in fact I would argue that a “restaurant theme” should actually be a plugin.
Under this scenario: When I switch themes my analytics code goes away. So this should also be done in a plugin.
Also regarding theme guidelines, we are in the prototype and research stages right now. We will need to talk about guidelines/requirements again before launching our directory, but we can revisit that conversation separately.
I think this is a good balance. To take it a step further you could make these sections of the code very easy to separate out / remove, and document how to do so. A pattern I have seen that works well is something like this:
This works like mu-plugins in that it just loads all “integration” files from the given directory. To disable one or more of them, just remove the corresponding PHP file. (And if you document this, maybe add a note that this is a special case - you generally cannot just delete random PHP files and expect things to keep working!)
No, something like this shouldn’t have its own setting, because this is a lot of extra work to make it all work correctly for a feature that most users will never need. Customization at this level would be done by deleting the files, that way it is the site owner’s responsibility if this needs to be undone later.
I was the one who asked about a Genesis fork. I’ve only ever used the Genesis framework and its assorted child themes. The majority of the websites I’ve encountered, which use WP, are using the Genesis framework.
It was chance that I stumbled across CP when I switched my web hosting provider. I honesty don’t know what the likelihood it would have been for me to make the jump to CP if I couldn’t have found a legacy version of Genesis to work for the time being. I’m grateful for this community and for @zulfgani who was willing to look into it.
If the name topic is still a thing … maybe we should try picking Star Trek-related names instead? Whenever I hear of Genesis, I instantly think of the “Genesis device” in Star Trek II: The Wrath of Khan