canonical /kəˈnɒnɪkl adjective
‘according to the canon’ – the standard, rule or primary source that is accepted as authoritative for the body of knowledge or literature in that context.
Table of Contents #
- Form Block as experiment within the Gutenberg plugin
- Canonical Plugin is a good alternative
- MP6 was a great success
- What we should do to replicate MP6 with Form Block
- References
Form Block as experiment within the Gutenberg plugin #
While starting the Form Block as an experiment within the Gutenberg plugin is a brilliant way to start this long wished for major change to WordPress core, I’m not sure it’s a sustainable approach in the medium to longer term.
Reasons:
- the Form Block is outside the current Roadmap on the Gutenberg project
- the Form Block is going to get complex in some areas
- providing a solid way for existing form plugins to adopt & extend the form block is not easy
Advantages of doing it within the Gutenberg project:
- the Form Block has a Block editor UI
- GitHub based development
Refer:
Quote
Form Block is outside the Roadmap on the Gutenberg project #
Refer:
Quote
Form Block is going to get complex in some areas #
Refer:
Quote
Existing form plugins adopt & extend the form block #
Refer:
Quote
A Canonical Plugin is a good alternative #
Refer:
Quote
Canonical Plugins Revisited #
Matt Mullenweg in … again the discussed using Canonical Plugins more commonly for WordPress core development.
The plugin directory is great, but many plugins are controlled by a single dev or company, and often end up going a direction of a premium or pro version, sometimes even removing functionality that used to be in a plugin and pushing it into the pro version.
This can also create an incentive to put something into a SaaS service that is easily done in a more distributed fashion locally to the site. Even accepting donations can create some weird incentives for how to divide those among a number of contributors.
Matt Mullenweg – Canonical Plugins Revisited
I agree –
Quote
The plugin directory is great, but many plugins are controlled by a single dev or company, and often end up going a direction of a premium or pro version, sometimes even removing functionality that used to be in a plugin and pushing it into the pro version.
This can also create an incentive to put something into a SaaS service that is easily done in a more distributed fashion locally to the site. Even accepting donations can create some weird incentives for how to divide those among a number of contributors.
Matt Mullenweg – Canonical Plugins Revisited
I agree –
Quote
Also I think we should build on the successful history of canonical plugins like MP6, Gutenberg, and REST API to have more community-developed plugins, called canonical because they will be the official first-choice recommendation by core and w.org for an area, that share in the ethos and approach of WordPress itself but to a more niche area that might not be right for core.
Matt Mullenweg – Canonical Plugins Revisited
I agree – MP6 was a great success
Quote
We are reaching a point where core needs to be more editorial and say “no” to features coming in as ad hoc as they sometimes do, and my hope is that more Make teams use this as an opportunity to influence the future of WordPress through a plugin-first approach …
…. that gives them the luxury of faster development and release cycles (instead of three times per year), less review overhead, and and path to come into core if the plugin becomes a runaway success.
Matt Mullenweg – Canonical Plugins Revisited
I agree – WordPress core has in my opinion reached a point where it should say no more often. But WordPress needs a viable, practical way of doing that in a way doing that in a way that:
- does not stop innovation & major changes
- item
Quote
I am very conscious that when people are aiming to have something in core, a “no” or “not now” can be frustrating and sometimes create artificial pressure to put something in before it’s ready, as I believe happened with the REST API in WP 4.4.
Matt Mullenweg – Canonical Plugins Revisited
I agree –
Quote
Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core.
There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility.
There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.
Matt Mullenweg – Canonical Plugins (Say What?)
I agree –
Quote
..
Matt Mullenweg – Canonical Plugins Revisited
I agree –
Quote
Refer:
- Canonical Plugins Revisited – 2024
- Canonical Plugins (Say What?) – 2009
- In Support of Canonical Plugins
- Canonical Plugins Revisited @ team.buzztone
Quote
MP6 was a great success #
history of mp6
characteristics & reasons for success
Refer:
Quote
What we should do to replicate MP6 success with Form Block #
Refer:
Quote
References #
Gutenberg GitHub
- New Block additions for the Block Library #71026
- Proposal for Core Blocks in the Directory #58773
- New blocks to expand pattern and theme designs #63501
- New Block Label
- Try canonical block plugins using the Time to Read block #61504
Here at CF7 Skins we’ve made a decision to get involved & contribute to the development of the Form Block in WordPress core.
Neil Murray
