Corey McKrill 10:34 pm on March 29, 2019
Tags:   

Feature and maintenance update for WordCamp.org: March 18-29, 2019

Here’s a list of the WordCamp.org feature developments and maintenance work that was accomplished in the last two weeks:

  • Continued iterating on WordCamp’s shortcode-to-block conversions
    • Introduced the Organizers block
    • Updates to Speakers, Sessions, and Sponsors blocks
    • Began tracking progress in a milestone
  • Investigated and mitigated two server downtime incidents
  • Fixed a problem with retrieving data about meetup events after Meetup.com made an unannounced change to their API
  • Fixed a bug that wiped out sponsor data in some situations
  • Updated the verbiage in ticket receipts to reflect current global sponsors
  • Began the process of implementing a more reliable cron system on WordCamp.org

#wordcamp

+make.wordpress.org/community

Josepha 10:29 pm on March 29, 2019
Tags: ,   

X-post: Weekly Digest | Week 13

X-comment from +make.wordpress.org/updates: Comment on Weekly Digest | Week 13

Alex Shiels 1:41 am on March 29, 2019  

Block metadata in the Plugin Directory

Plugins that are in the Block-Enabled section of the Plugin Directory can now automatically list the blocks that they provide. For example:

Screen Shot 2019-03-29 at 12.08.24 pm

If available the list is displayed for now in the Description section, between screenshots and the FAQ. As you can see it’s a rudimentary list to begin with, that simply lists the block names and titles. We plan to improve that over time, and to do that we could use your feedback and help.

Because of the difficulty of reliably extracting block metadata from code, the best way plugin developers can ensure their blocks are reliably indexed is to use block.json files as recommended by the Block Registration RFC. We’ve done our best to parse this info out of existing source code, but less than half of Block-enabled plugins were easily discoverable this way. The RFC isn’t yet final, but by experimenting with it now plugin developers can help with feedback and suggestions both for the RFC and for the plugin directory’s use of that metadata.

I’ve opened a general ticket #4345 for discussing improvements to the plugin directory side. The RFC for the block.json specification can be discussed over on GitHub. Feedback, suggestions, and questions are welcome.

Hugh Lashbrooke 12:20 pm on March 27, 2019
Tags: make.wordpress.org/polyglots,   

X-post: HelpHub Localisation Plan Meeting Notes

X-comment from +make.wordpress.org/polyglots: Comment on HelpHub Localisation Plan Meeting Notes

Corey McKrill 11:25 pm on March 18, 2019
Tags: , ,   

Next WordCamp.org ticket scrub on March 21st, 2019

This ticket scrub will happen on 2019-03-21 17:00 UTC in the #meta-wordcamp channel.

The focus is on Meta tickets with the WordCamp Site & Plugins component.

Comment below if there’s a specific ticket or topic you’d like to discuss.

#agenda #ticket-scrub #wordcamp

+make.wordpress.org/community

Josepha 2:05 pm on March 13, 2019
Tags: ,   

X-post: Strengths and Challenges: Organization

X-comment from +make.wordpress.org/updates: Comment on Strengths and Challenges: Organization

Alex Shiels 11:13 am on March 8, 2019  

The Block Directory, and a new type of plugin


The plugin directory already has a block section, and there has been some fragmented discussion about expanding or improving it. I’d like to share some thoughts on this and propose a more expansive solution. First I’ll outline some of the main problems that need solving.

Issues:

  • Many plugins already register blocks, but often the plugin name and description doesn’t give a good indication of what those blocks are.
  • There is no way to search by block name.
  • Installation of plugins is far removed from the business of using blocks.
  • Developing blocks is a steep learning curve for new and experienced plugin developers alike.

A proposed solution:

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory. They will be JavaScript-based, and each plugin will register a single Block. And they will be searchable and installable from within the Gutenberg editor itself.

Let me break that down with some more detail.

A Single Block Plugin is intended to be a relatively small, simple plugin that provides a single Gutenberg block. The plugin is the block, essentially.

Single Block Plugins are WordPress plugins that conform to a few rules, including:

  • They register a Gutenberg block.
  • They’re written in JavaScript, and are front-end only.
  • They have no UI outside of the editor.
  • They use a block.json file with metadata as per the Block Registration RFC
  • They include readme.txt and header metadata as required.

This is not set in stone; we’ll work out the exact rules in collaboration with plugin developers and the community on Make WordPress Plugins.

The Block Directory will be a section within the Plugin Directory, that contains only Single Block Plugins.

  • It will be separate from the main plugin directory: you’re either browsing regular WordPress Plugins, or Single Block Plugins.
  • Single Block Plugins will be searchable by block name and description, as per the Block Registration RFC.
  • The Block Directory will probably use a simplified version of the plugin page layout for Single Block Plugins.
  • There will be an API endpoint for searching blocks by name and description.
  • Inclusion in the Block Directory requires following the rules for Single Block Plugins.

Regular WordPress plugins in the main Plugin Directory can continue to register Gutenberg Blocks.

  • Regular plugins will also be searchable by block name and description.
  • Regular plugins can register as many blocks as they like, and are not required to follow the same rules as for Single Block Plugins.
  • Regular plugins can continue to do all the amazing things they can now, including back-end code, wp-admin UI, and so on.

In other words, Single Block Plugins are for blocks; Regular WordPress Plugins are for anything at all.

Single Block Plugins will be JavaScript-based.

  • The block code will be entirely written in JavaScript.
  • The plugin can contain other assets like images and css.
  • To begin with, Single Block Plugins will contain a single PHP file containing plugin headers and initialization code only. Eventually, this should become unnecessary.
  • They won’t have any back-end code.
  • Any UI will be contained within the editor.
  • We’ll help onboard new (and new-to JS) developers with templates, samples, and other tools.

Single Block Plugins will be searchable and installable from within the Gutenberg editor.

  • The Block Inserter will use the above-mentioned search API to discover and display relevant Single Block Plugins from the Block Directory.
  • Installation will (eventually) be seamless, without leaving the editor.
  • We’ll make use of and improve the block management features that are already on their way into core.
  • Obviously this will entail plenty of design, UX, and accessibility work, which will start over on Make Design.
An artist’s impression of what inline installation might look like (thanks Mark!)

This post is intended as a starting point for discussion and new ideas. We’ll post more details on the Plugins, Meta, and Design Make sites in the coming days to focus on those particular areas.

Andrea Middleton 7:45 am on March 8, 2019
Tags:   

Feature and maintenance update for WordCamp.org: February and March 2019

Here’s a list of the WordCamp.org feature developments and maintenance work that was accomplished in February 2019:

Here’s what folks working on WordCamp.org hope to accomplish in March:

  • Complete the rest of the shortcode-to-blocks conversions (Sessions, Organizer, Sponsors, Schedule) — this will probably be the majority of the work in March
  • Continue to give feedback to the teams working on automating VAT invoices and the WordCamp.org PWA.
  • Update global sponsor acknowledgement on ticket purchase emails and landing pages.
  • As always, fix bugs as they are reported and maintain wordcamp.org

#wordcamp

Josepha 10:39 pm on March 1, 2019
Tags: ,   

X-post: 5.0 Release Retrospective Kickoff

X-comment from +make.wordpress.org/updates: Comment on 5.0 Release Retrospective Kickoff

Vedanshu Jain 7:44 pm on February 27, 2019
Tags:   

Replacing SVN with Git for wordcamp.org’s code

WordCamp.org’s code currently uses SVN as the primary tool of version control hosted on the Meta SVN repo. For the last several months we have also been experimenting with Git to see if it improves the development workflow.

Currently there is a GitHub repo which is set up as the mirror of the official SVN repo of WordCamp.org’s code. This repo is used to hold code reviews, and sync with SVN with every  new commit.

So far this setup has been a big help in making it easier to get and give reviews, therefore improving code quality. Many basic features in Git like commit, stash, branch etc have been a delight to use in place of their SVN counterparts because of Git’s decentralized nature.

At this point it’s worth discussing removing SVN altogether, from at least the local development flow. Right now the process is prone to errors, not easy to set up, and has an extra step of manually syncing Git with latest changes in SVN.

New proposed process

It seems like a good idea to change the version control system as follows:

  1. Make the Github repo the primary destination for code reviews. It will be configured on the local system of whoever wants to contribute to WordCamp.org’s code, and will be the primary place to work and develop.

  2. Keep SVN as part of the release process. That is, whenever code is deployed changes will be synced from Git to SVN and start the deploy process. This process will be manual (or at least will be triggered manually) and SVN will be used only as a release tool (i.e. aim is not to preserve commit metadata like author, commit message etc). This approach has two main benefits:

    1. No changes to deploy scripts will be necessary to use Git. These script are used while pushing code from latest SVN revision to WordCamp.org’s server. They would continue using SVN as before.

    2. No dependence on an external tool in order to deploy changes. For example, Github going down will not affect us in case we want to push an emergency fix.

Commits with their authors have already been imported from the SVN repo into the Github repo.

Share your thoughts

Do you have any technical concerns about moving from SVN to Git? Do you suggest any changes to the process?

If the development process is indeed changed, it might be a good idea to also think about importing issues from Meta Trac to Github that are reported for WordCamp.org and its components. Do you have any concerns about importing issues into Github, or should they continue to exist in Trac?

Please leave your suggestions and feedback in a comment on this post.

#wordcamp