[Weston Ruter]

I half-jokingly/half-seriously envision moving all existing PHP global-namespace functions for WordPress into a deprecated.php, and then to come up with a normalized/consistent library of functions that take array arguments (finally kill $deprecated = '' arguments, and eliminating 6+ positional arguments to functions). The new WP PHP API could then be namespaced under \WordPress.

This doesn’t address global variables, but that’s a different beast since they cannot be namespaced using PHP namespaces as such.

[Weston Ruter]

PHP_CodeSniffer WordPress Coding Standards for Core. We’ve got a script prepared which selectively applies rules to the diff of a new commit, which would help slowly clean up the Core’s codebase as more and more code gets touched, but ignore code in a file that is not part of the patch.

[Weston Ruter]

@Morgan:

Github isn’t Git, and PRs are specific to Github

+1. I did mention this on the What to do about the Plugins Directory, but didn’t include it here: “I suppose .org wouldn’t want to marry to close with GitHub, even if it is the de-facto platform for open source software platform nowadays, so the specific external Git repo used by a plugin could be configurable: GitHub, BitBucket, Google Code, etc.”

So WordPress.org could/should have mirrors on any number of Git hosts. BitBucket also has pull requests. Other hosted Git service communities probably have their own patterns for requesting pulls, even if it is just opening a ticket in their tracker. Adapters can be written for any number of service clones: mirrors in many places.

What happens when a ticket is updated with a PR from Github and a manual patch from SVN?

I think ideally opening a GitHub pull request would automatically create a patch file and attach it to the ticket. Whenever a new commit is pushed to the branch on GitHub, the patch would be refreshed on the ticket. This would be independent of any other patches manually added. This would allow any number of people to create patches from their respective GitHub forks, and each one would have a separate patch file attached to the Trac ticket.

Does a PR from Github that updates a patch automatically mean no more patches named 12345.1.diff

Basically, yes. But I think there would be a different naming convention for patches from pull requests. For instance: github-westonruter-12345.diff could be the patch which corresponds to the GitHub pull request for the westonruter account from the 12345 branch. As noted above, whenever the pull request is updated then this patch file could be updated.

Also worth mentioning that PHP created a custom integration between their bug tracker and GitHub’s pull requests to adapt to their existing workflow. It’s not inconceivable that we could copy what they have and integrate it with Trac instead.

Cool! Do you have a source for this?

[Weston Ruter]

+1

[Weston Ruter]

From Nacin’s post on Make Core this morning, he linked to a post about the Customizer which was written for the previous community summit. The post was a draft, so it hasn’t been seen until now: The Future of the Customizer.

Interesting to look back at this piece of history from Koop.

I find it interesting that under “What else can we customize?” he identifies Widgets, which is what we added in 3.9. He also identifies Menus, which is what Nick Halsey (celloexpressions) has been working on. And then he also identifies “post previews” which is something else I’ve been prototyping.

Roadmap for allowing the customizer to support multiple instances, which allows it to be used in any use case, instead of just theme switching.

This action item was done, as you can open the Customizer without doing a theme switch now. But perhaps he has in mind what Eric Lewis has brought up in #29071 (Make it easier to include an instance of the Customizer outside of customize.php).

How far will WordPress core go in terms of adopting the customizer?

Customize all the things! 😉

[Author]

Posts