View in #core on Slack
@Matt_Robinson: Anyone online for a core review discussion?
In terms of the v2 work, in the last week I’ve been looking at trying to “fast forward” the current v1 code as I described above.
I have now updated the vast majority of files located in wp-admin
and the root.
There are still the files in wp-includes
to update, then test files.
I am already aware that the cahnges made so far have broken QUnit testing.
Many of he changes are document block updates, many of these are simple but some raise the quest as to why we change many instanced of “WordPress” to “ClassicPress” in the code, in some cases in a misleading way - for example plguin and theme update checks still use the WordPress API but the document block states it is the ClassicPress.net address - that is incorrect.
@Simone_Fioravanti: Correct me if I’m not wrong, but this way we have not to bring back changes that were introduced in v1.
@Matt_Robinson: Correct, I’m am attempting to keep our already made changes, on that also through, ClassicPress defaults to SSL for API checks and also sends the user agent information using classicpress_user_agent()
- this is replaced in numerous places in the code but I wonder if a single filter approach would work and save code overhead.
The other issue is the amount of time and work this process is taking for 1 person. It’s quite time intensive and is going to need some major testing once complete. I’m wondering how we can share the workload and who might be able and willing to help out.
@Simone_Fioravanti: Can’t give an opinion about this because that function accpets a parameter, and maybe is used where filters are not already defined.
I can imagine the huge amount of work. I can certainly contribute testing.
@Matt_Robinson: Appropriate code is here:
https://github.com/ClassicPress/ClassicPress/blob/bc9719e6e0e6f04a4282105aa959b3c9168364b0/src/wp-includes/class-http.php#L177
That is the default, so we could simply remove the explicit passing of ‘user-agent’ elsewhere in the code rather than updating those instanced and perhaps re-introduce the upstream filter to allow local level control if desied.
@Viktor: Sorry guys, had a call.
@Matt_Robinson: I haven’t really got as far as Javascript in terms of packages as yet either but I’m considering just dropping in the built file from current upstream but in the previous location rather than scattering Javascript files in asset
and vendor
folders. We could then bypass the upstream changes to script-loader - again that needs more figuring out.
@Simone_Fioravanti: Seems a very good idea. Guess that main changes to script-loader were introduced for Gutenberg and the new build process.
@Matt_Robinson: That seems to be the case, so we can leave out what we don’t need and include what is needed pre-built in the default location and link back to there. That might all fall apart later but that’s the plan for now - will depend on Site Health and Quick Edit modals remaining functional.
The code base I currently have is almost certainly broken so not worth publishing yet.
@Simone_Fioravanti: Site Health is one of the things I see no need for.
@Viktor: I actually find Site Health useful, and even installed plugin on CP sites to give me basic server/PHP information to troubleshoot issues. I don’t care for the recommendations, but the debugging info it provides is valuable for support and troubleshooting.
@Matt_Robinson: The Document blocks are things like:
@global wpdb $wpdb ClassicPress database abstraction object.
Could we just leave that saying WordPress
?
That does exist in the current v1 code.
As for WP-CMS, I know what you are saying but is has now been abandoned and deleted, and there are changes made specifically wor WP-CMS that need taken out without any access to past change sets now so we are in the dark hunting these down and reverting them.
I’m ambivalent about Site Health, doubt I’ll use it myself but can see that advantages - that said some of the check we may need to remove or change - connection test to WordPress api as an example.
@Simone_Fioravanti: Maybe Site Health can have a lower priority and be tailored to CP, maybe more professional and without so many recommendations.
Leaving WordPress in docblocks for me is just fine. Maybe we can replace WP in the docs site.
@Matt_Robinson: One other area for potential simplification, we have a different linked site for support forums like this:
__( '<a href="<https://forums.classicpress.net/c/support>">Support Forums</a>' )
Upstream it is linked to the WP forums and the link text is just ‘Support’
I wonder if we can add a ClassicPress class that filters gettext and swaps the link at rended time - one location to maintain and reduced work when backporting perhaps - maybe not as big a deal if we reduced instances where we convert WP to CP in core code documentation.
Okay, I need to shoot off early this week, I’ll try to keep working on my update, tests can be updated laster so I’ll publish a branch of code once the diff process is completed.
@Simone_Fioravanti: You mean using the gettext
filter, sounds good!
@Viktor: Wouldn’t gettext add to the performance overhead? It might be milliseconds, but still adds it.
@Matt_Robinson: Yes, the gettext
filter. Only issue with that is tracing back over the code already updated and restoring the upstream code! Low priority for now though, that can be polished later.
It would add overhead but no more than using a non English-US language.
@Simone_Fioravanti: The filter have to be well coded. Fail early if domain is not default, check which function is faster ecc…, but it seems not so difficult.