WordPress references

[Toine]

Sorry if this is the wrong place for this question (if it is, please tell me what the correct place is)
I was wondering if there is a place where we keep track of WP references within CP. I mean examples like:

• The WP events in the dashboard
• Directory and file naming like wp-config or wp-content
• References to WP documentation or -API’s
• Or (maybe at a later stage?) naming in the code; constants, classes, functions

[pieter]

Hi Toine, thanks for your question. I think Core Development would be a better place for this topic, so I have moved it to there for your convenience.

Regarding your questions, the Core team is well aware of these things and for now most of these things remain untouched. The reason for that is that with version 1 ClassicPress we have made the commitment to stay compatible with WordPress 4.9.x.

Most likely the WP events in the dashboard will be replaced. We have already added a new dashboard widget that shows the Petitions.

References to WP documentation will remain in place too for now at least until we have our own documentation set up.

We have made a function available classicpress_version, which can for example be used to test against the presence of ClassicPress:

function_exists( 'classicpress_version' )

Hope this helps.

[Toine]

Thanks Pieter, for the answer and moving the topic,
The answers sure make sense (and not different from what I expected/hoped for )
And it’s good to have a way to distinguish WP from CP

[james]

Pieter pretty much covered it, thanks for answering! Adding some thoughts about 2 specific points from the original post…

@Toine

• Directory and file naming like wp-config or wp-content
• Or (maybe at a later stage?) naming in the code; constants, classes, functions

We still need to support wp-config.php and wp-content for the foreseeable future, because a key use case for early versions of ClassicPress is migrating existing sites from WordPress. This should be as simple as possible - any renaming, replacement etc required to files or database structures introduces more points of failure.

We could implement some logic like “use a file named cp-config.php or a directory named cp-content if it exists”, but this would also introduce edge cases and complexity. What happens when both files exist, or when a file/directory is renamed from one convention to another? What about the many plugins which hard-code these paths in place expecting a specific filename?

Similar issues apply to naming in the code. For just one example, we can’t rename WP_Query or the PHP filename where it’s included without breaking a huge amount of existing code. We could implement a CP_Query wrapper class, but again, why bother? More edge cases to tackle, more complexity added. Plugins that use the new name would also lose compatibility with WordPress, which isn’t a good outcome either.

We’re open to renaming things where there are no backwards compatibility implications whatsoever. For example, the default database table prefix for new installations of ClassicPress is now cp_ instead of wp_, and of course we don’t change this value for existing sites that are migrated to ClassicPress.

So far, there have been very few cases where that’s possible without introducing bugs and incompatibilities.

So, in summary, backwards compatibility at the code level is a major focus because we want to make it easy and painless for people to switch to ClassicPress. I don’t see that changing any time soon.

[Toine]

Thanks James. So this has been carefully thought about. (Better than I did before asking )
Yes, I totally agree that these are some major reasons to keep the WP references in the code and structure. This is not a matter of “Just fork it and go our own, different way from there”. In our case we do need to take account of WP users who want to switch over.