Forking Genesis

Surely, if you’re in Leicester and it’s all about the Foxes, the name should be either Gary Lineker or Jamie Vardy.

1 Like

Ah, I hail from the land of Villa Park so I’m Villan/Villain? at heart

Having said that, I’m more of a Vardy fan than Lineker so I might be inclined to play favoritism if the choice came down to the two :innocent:

But don’t forget King Richard III was found buried under a car park in Leicester a few years back (2012 to be precise). :slight_smile:

The reason I just happened to drop in the word “Foxhaven” is because of the association with Leicestershire and a certain “country pursuit” that many people (including me) find abhorrent. That particular pursuit is supposed to have started in Leicestershire (hence the reason why Leicester FC are called The Foxes) and it’s still prevalent today.

I apologise for bringing up a highly controversial subject but that (the “country pursuit”) is what first comes to my mind when I hear or see the word “fox”.

But if it’s a choice between Vardy and Lineker, it’d be Lineker any day. Because I like crisps :grin:

And on that note, I shall bow out.

3 Likes

What about cats?

Nothing against foxes. But cats…

Why an animal and not a plant?
Seriously. To do something different from the masses.

No need for apologies, I total get where you coming from and I am averse to that very same abhorrent country pursuit.

hmmm, crisps or the premiership? :thinking: Vardy wins :joy:

2 Likes

I like this line of thought too.

Genesis: The coming into being of something; the origin. — dictionary

This sounds more to me like a plant springing out of the earth. In that spirit maybe some ideas here:

3 Likes

Thank you @james - those lead me to a few more discoveries :slight_smile:
Beacon - Word of the Day - beacon | Dictionary.com
Fettle - Word of the Day - fettle | Dictionary.com
Nucleus - NUCLEUS Synonyms: 21 Synonyms & Antonyms for NUCLEUS | Thesaurus.com
Scion - SCION Synonyms: 22 Synonyms & Antonyms for SCION | Thesaurus.com

Hindsight - a play on this year 20/20(2020) twenty-twenty hindsight

Just for fun :rofl:
Peripeteia - a sudden turn of events thanks to Gutenberg

2 Likes

The idea to fork Genesis still alive?

2 Likes

I’d still like to see it happen. :slightly_smiling_face:

I’ve been goofing around with the code since everything in my area is pretty well shut down because of COVID-19.

2 Likes

Yes, very much so.

Likewise and can assure you that it is happening.

Just to add context: The Genesis fork is on and will be developed in conjunction with Classic Elements i.e. it will be the base theme with built in support for the builder.

Cosmetic branding has been done and once I’ve released Classic Elements I’ll be working on the theme from 2 fronts.

  1. Remove bloat and

  2. Classic Elements integration

Same here - I’ve goofed around code in the last two weeks more than I’ve done in past 3/4 months :grinning:
The positives of working from home.

5 Likes

That’s great news! Thank you for the update.

1 Like

I hope, it will be a clear framework, without CE artifacts? I have no plans to use ClassicElements, just a Genesis fork and a child theme on production or Dynamik on dev sites.

Or, my hope to see the two separate projects is quite naive?

No, no artifacts just support for those that choose to use CE. There will also be support for Classic Commerce as well as Classic SEO - again these are most likely to be user activated rather than being fully baked in.

As an example if I have Classic SEO activated I get an option to use it. If Classic Commerce is active then options are made available together with some basic styling - one shouldn’t have another plugin added just to connect the theme to say CC i.e. no bridging addons. If none of the supported plugins are active then the code will remain dormant and there will be no prompts to say that “This theme recommends xyz plugin, begin installation/activation” :wink:

How this support/integration is added in is what I’m working on - suggestions here are most welcome :slight_smile:

3 Likes

Didn’t like the idea to add code, but ok, I can live with that.

I really like RankMath’s approach and interface to enable/disable some functionality (in Dashboard). Clear and intuitive.

Maybe this additional code can be installed/uninstalled from the dashboard like this? Also, it will be some sort of consistent UI. I know, in SEo plugin thic code just deactivates, as said, I am OK with that, but, maybe in the future consider an option “delete code” and “download code”?

Maybe, the same interface can be adopted in the ClassicPress v2 to turn on/off legacy functions? Consistency can be good for the UX.

Additional code will be kept to an absolute required minimal and let the supported plugins do the heavy lifting. All the theme has to do is say if CC/CS/CE is active I have an Action/Filter for that and give the option to turn it on/off.

So at most we are looking at actions and filters plus some additional CSS declaration - fully fledged integration will be left to the developer to achieve via a child theme.

Another example is in the future CE will have the option to build headers and footers (via an addon) - the theme should not be so rigid in implementing its header/footer as to not allow for the plugin to hook in the new one.

Having said that, non of these a fully set in stone - they may even be confined to dedicated child themes but I’m still leaning towards the minimal support being in the main theme. Again, I’m open to suggestions!

2 Likes

I’m about to start work on the fork and I’m going to base it on the last v2.10 that I have (2.10.0) together with the sample child theme which is at v2.10.0 as well.

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.

Any and all suggestion/feedback will be taken onboard and considered - you are more than welcome to counter the proposals above.

So for now, let’s get this show on the road :slight_smile:

3 Likes

I find it interesting that there has been no discussion of what the Theme Directory guidelines or entrance requirements are, yet here we are with a research theme (with Classic in the name) seemingly becoming the benchmark for everything that comes after.

So, the question is: Does the ClassicPress project condone theme lock-in (meaning themes that have plugin functionality of any kind) ?
This should be considered from a view of what core provides for themes and plugins, but also for bundled themes and their maintenance and support. What should the user expect to find in the Theme Directory?

Because Genesis was never in the WP repository, it doesn’t follow any of the WP rules.

1 Like

There seems to be a bit of a misunderstanding here.

The theme name has not been decided yet even though a name with Classic in it was floated. As it stands I’m not even considering including “Classic” in the name of the theme at all - I’d prefer a one word name and ClassicSomething doesn’t qualify as a one word name, at least not to me.

This is not an official or even an unofficial ClassicPress-research effort or at least not as far as I’m aware! I simply took on the idea as there seemed to be a need for the framework to be maintained with ClassicPress compatibility.

I have no intention of having any kind of vendor plugin lock in for the theme - I merely proposed adding support for the official plugins as well as those which are currently under the “research” banner. The “support” may even be confined to child themes supported by the framework/core theme.

If I’ve misquoted anywhere in the thread that lead to the confusion/misunderstanding then I sincerely apologize as that was not my intent :slight_smile:

4 Likes

AFAIAA, there’s nothing to stop anyone from using ‘Classic’ in the name of a plugin or theme. The only restriction is on the use of ‘ClassicPress’.

And I can confirm that this is not an official ClassicPress project so @zulfgani is free to do what he likes. He is simply making use of ClassicPress research facilities to nurture and develop his idea with the help of the community. However, that’s not to say that this can’t become an official project at some point in the future.

Everyone is welcome to submit their own project to be added to the research area. Perhaps a theme forked from GeneratePress, Sage or Underscores for instance.

3 Likes

About theme/plugin territory i hope there will not be heavy restrictions as for wp.

For me is up to users to prefer a theme giving (example) the opportunity to add analytics tracking code or doing it using a plugin.

Other example: restaurant theme. Dishes are a CPT and for wp those must be created from a plugin. But a theme that can’t work without a plugin for me is just messy. And there is no difference (or maybe i can’t see) in code payload to keep this things separate.

1 Like