Forking Genesis

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.


This isn’t a theme, though; it’s a suite.

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.


7 posts were split to a new topic: Plugin suites for niche markets

OK, let’s go back to the Genesis fork discussion :slight_smile:

quote=“zulfgani, post:72, topic:2106”]
My first change was to remove the Customizer redirection - Done!
Question: Should the Customizer options be removed altogether or should they be left in place?

After the rebranding I’ll be looking at the following in more detail to see what should/has to stay and what can go without breaking the theme.

1: The SEO module is a priority must go for me - but I’ll take your views into consideration.

2: Nags like the “install and activate Genesis Connect for WooCommerce” will have to go - support for Classic Commerce will be built into either the parent theme or one of the child themes.

3: Google AdSense plus Header/Footer script options will go - these can added back by an addon plugin or a child theme that requires them.

4: The meta tag clean up maybe completely removed or toned down - for me these are plugin territory.

After that we’ll have a core framework ready for beta testing and hopefully move it on to a full production ready release.

If Genesis options are on the Genesis settings page, there is no need to leave it in Customizer.

I vote for leaving Header/Footer script options. AdSense should go.

What you mean by “meta tag clean up”?

Genesis 2.10.1 acts the same, as 2.10, but, maybe, fixes a bug?

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 :roll_eyes:
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.

[2.10.1] - 2019-05-07


  • Added action links (via filter) to the end of the update completed screen.


  • Removed automatic redirect to Theme Settings after an update.

  • Removed the function that output a “success” notice after database upgrade. Upgrades are now silent.


  • Fixed issue on Genesis Plugins page that resulted in a fatal error on WP 5.x or older.

  • Fixed issue with the database upgrade that would cause it not to run in certain circumstances.

I have 2.10.1, how to send it to you? 900kB zip.

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?

1 Like

Will DM you :slight_smile:

1 Like

The simple answer is that we don’t know yet :slight_smile:

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:

foreach ( glob( $theme_directory . '/lib/integrations/*.php' ) as $php_file ) {
   require_once $php_file;

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!)


And put the button in the Settings page “Remove/Download and install” for this functionality. The most flexible, the cleanest code solution.

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.

Would an upgrade not deploy the file again?


This is why I prefer Actions and Filters - easy to override/remove.


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. :slightly_smiling_face:


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 :slight_smile:


Or for a more up-to-date approach, also ST:ID =>

cu, w0lf.

Not sure if it’s still a thing. I wasn’t really involved, just made a tongue-in-cheek suggestion. :slight_smile:

1 Like

Foxland Framework still sounds the best. :slight_smile:


Late reply, but good point, this would require another workaround or a different approach (actions and filters do work very well for this sort of thing).

Any news on Foxland Framework status?

1 Like