5.0 and the future: PHP version, Modules/Components and more

[justintadlock]

Now that dependency management is a bit more commonplace in the WP community, I think it's time to start thinking about Hybrid Core from a different viewpoint. This discussion was brought on by a separate but related discussion of creating a modern starter theme that uses standard practices from the wider PHP, JS, and CSS developer communities and not necessarily being tied down to what core WP is doing.

HC has a lot of useful features and tools. However, not all of these tools are necessary for every project.

Before moving forward: Nothing here is set in stone and no decisions have been made. This is an early discussion to gather feedback and ideas.

PHP version

Perhaps this belongs in a separate discussion, but I think it goes along with updating HC with newer ideas. Until now, I've tried to support WP's minimum version of PHP 5.2.4. However, I'm going to come out and say that 5.0 will definitely be 5.3+ at the very least. We may even jump to PHP 5.6+.

I think where we go is going to depend largely on feedback from those building themes with HC with a healthy dose of what "newer" (relatively speaking) PHP features the framework would benefit from.

Components

We've discussed on the Theme Hybrid Slack channel the possibility of separating the various HC components into separate repositories. And, the hybrid-core repo being a repository that ties all the packages together for those who want to continue using the entire framework.

Much of HC is already very modular. There are so many features that would work just fine as a standalone script installed into a theme. For example, here's a short list of things that could easily stand alone:

- media-meta
- media-grabber
- layouts
- template-hierarchy
- attr

Of course, there are some things I'm unsure of. There's plenty of random utility functions as well.

If we go this route, we'd have to figure out and define what each component is. Then, we'd have to figure out how such a system would work (I'm fairly certain we'd be using Composer as part of that solution).

And, discuss... :)

[trsenna]

Hi, just my first two cents for this discussion. Obvious, but one of the first things maybe is decide about how hybrid-core will autoload your classes. I think composer is the way to go :)

After that I believe you can do the refactoring into hybrid-core to autoload classes. In a third moment I would choose a feature and extract it into a individual composer package that would be required by you hybrid-core project. Probably I would extract one feature only until I have it done and working.

[rgadon107]

Composer is nice, and can be quite useful. But it is not necessary to autoload files. That can easily be done by building an 'autoload()' function into the theme using procedural code. The function can incorporate a loop into the function, which can process a list of files used within each of the theme directories. One useful feature of this approach is that files that do not need to be loaded for a particular project can simply be commented out for use at a later time.

The value of requiring a minimum version of PHP 5.3+ within the theme is so that it can encapsulate functions within 'namespaces'. That functionality was added to PHP in version 5.3. Because of WordPress' decision to make Core backward compatible to PHP version 5.2, namespace capability cannot be included in core files at this time.

Namespaces allow us to do away with prefixing functions. This makes code more readable, and allows for better naming as to what custom functions actually do. It may also result in fewer errors and better troubleshooting when investigating and resolving problems with processing code.

[brettsmason]

On PHP version - I don't think we should support any unsupported versions, which would mean a 5.6 minimum. My preference would be 7, but that may be unrealistic I'm not sure.

Really like the suggestion of splitting things into components and can see that being really useful.

[erikjoling]

I'm definitely interested in a modular approach of Hybrid Core. It feels better to only include functionality which I will use in my themes.

Right now I am using my own theme-framework, hugely inspired by Hybrid Core. But I'm repeatedly impressed by your way of coding that I'm keeping my options open to embrace Hybrid Core again. :)

[justintadlock]

Part of this ticket is going to have some crossover with the starter theme I'm building here: https://github.com/justintadlock/abc

Feel free to follow along with that project. Even if we don't break HC up into separate modules, some of the code may end up landing in HC.

[justintadlock]

PHP version

We've bumped to 5.6+ (with a strong recommendation of 7+) for HC5.

Add-on components/packages

Here are the add-on packages for HC5:

• https://github.com/justintadlock/hybrid-breadcrumbs
• https://github.com/justintadlock/hybrid-carbon
• https://github.com/justintadlock/hybrid-customize
• https://github.com/justintadlock/hybrid-font

Two other possible add-on packages will be:

• hybrid-layouts (an overhauled version of the Layouts feature from 4.x)
• hybrid-gallery (a port of the Cleaner Gallery extension)

For now, I think this ticket has been appropriately addressed.

[trsenna]

I agree that your add-ons addressed very well this ticket. But I'd encourage if possible later (not now, maybe a lot of months/years later) to cleanup the hybrid-core extracting from it more add-ons or independent composer packages.

[justintadlock]

There's a number of items that I think would be good candidates (in the future) for separation:

• Attributes
• Media Meta
• Media Grabber
• Pagination
• Template Hierarchy
• Views

I kind of see 5.0 as a transitioning period to Composer support. Let's get theme authors comfortable moving from dropping in a single hybrid-core folder or Git sub-module to learning Composer during the 5.x.x series.

Then, when 6.0 hits, let's split off any features that can be separated. With any luck, we'll have a stronger core at that point too.