Theme Review Team Meeting Agenda for February 25

Theme review team (TRT) conducts a meeting on the second and fourth Tuesday of the month. Along with the fixed agendas, we have open floor meeting at the end where you can ask or share anything related to themes.

We encourage all members and anyone interested to attend.

Channel: #themereview | Time: Tuesday, 25th February 2020, 18:00 CET

Meeting Agenda

  1. Weekly updates
  2. Recap of the online contributor dayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.
  3. Removal of the Featured themes tab in the theme directory
  4. Full Site Editing Road map: Requirements for blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. based themes
  5. Open Floor

The discussion about the meeting agenda can be held in the comments below. You are encouraged to propose the topic for the agenda.

Meetings usually last around 60 minutes. Attend and share your valuable feedback and suggestions.

Theme Review Day – The theme review team is planning for an online contributors day

As we all know that, WC Asia 2020 is canceled due to fear of the spread of the disease caused by the new coronavirus COVID-19. 

Contributors’ day for the WC Asia 2020 was scheduled for Friday, February 21. The theme review team did lots of preparation to make it awesome. Unfortunately, we are not able to apply those ideas this time.

The theme review team is planning for an online contributors day for themes on the same day. In the online presence of Moderators and Reps, reviewers from all around the globe can join the theme review channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and start contributing.

Time: Friday, 21st February 2020, 05:00 UTC

Channel: #themereview 

For more information, you can ask in #themereview channel on slack.

We encourage all members and anyone interested to attend.

#WCASIA #wcasia #themes

A plan to ease transition to block-based themes

2 weeks ago we had our first meeting for the future of WordPress themes, also known as blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based themes. In that meeting, we discussed how future themes will be structured and touched on the way they can be built.

The future is bright, but there are thousands of themes that are not built as block-based themes. These will continue to function properly for years, WordPress has always been a platform that embraced backwards-compatibility and very rarely (if ever) deprecates functionality.

It is inevitable that some existing themes will want to take advantage of the new structure and benefits that Full Site Editing has to offer. The problem is that it is a significantly different implementation to what we currently use, and there is no easy way to transition to that new structure.

This is where this post comes in: Figuring out a plan to ease the transition to block-based themes in a way that makes sense. Start a discussion with theme-authors and find a way to move forward.

Current WordPress themes use PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. templates and a lot of settings in the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. to define colors, typography options, settings that change the markup of some areas etc. Future themes, however, will not have PHP templates. Instead, templates will be defined in .html files containing a “preset” for how blocks will be arranged on the screen. Users will be able to override these “presets” and edit them in their editor. Most of the Customizer’s duties will be handled by the global-styles implementations currently being worked-on in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/.

So, how do we ease migrating from hardcoded PHP templates to a blocks structure?

As a first idea, we have started experimenting with code that will allow authors to define an upgrade path. So if they have a simple headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. that has the following components:

  • Green background
  • White text
  • Site-logo on the left
  • Navigation on the right

then that could be translated to the editor as a group block with green background and white text, containing 2 columns; In the 1st column we can have the site-logo block and on the 2nd column a navigation block.

A theme author wanting to transition to a blocks-based structure would do something like this:

/**
 * Return markup with blocks.
 *
 * Takes existing settings and migrates them to a blocks structure.
 *
 * @return string
 */
function mytheme_get_header_blocks_migration_markup() {

	// Open group block.
	$open_group = '<!-- wp:group {"backgroundColor":"' . get_theme_mod( 'header_background', '#fff' ) . '","textColor":"' . get_theme_mod( 'header_text_color', '#000' ) . '","align":"full"} --><div class="wp-block-group alignfull has-text-color has-background"><div class="wp-block-group__inner-container">';

	// Open columns block.
	$open_columns = '<!-- wp:columns --><div class="wp-block-columns">';

	// Build 1st column.
	$first_column = '<!-- wp:column {"width":33.33} --><div class="wp-block-column" style="flex-basis:33.33%"></div><!-- /wp:column -->';

	// Build 2nd column.
	$second_column = '<!-- wp:column {"width":66.66} --><div class="wp-block-column" style="flex-basis:66.66%"></div><!-- /wp:column --></div>';

	// Close columns & group.
	$closer = '<!-- /wp:columns --></div></div><!-- /wp:group -->';

	return $open_group . $open_columns . $first_column . $second_column . $closer;
}

// Migrate header template-part.
new \WPTRT\Blocks_Migration( [
	'content' => mytheme_get_header_blocks_migration_markup(),
	'slug'    => 'header',
] );

The above code is a simple and incomplete example, but it does show the basis of this idea:
We created the structure we needed in the editor using coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks.

Then we switch our editor from “Visual Editor” to “Code Editor”, and we have our blocks code there. We can take that code, put it in a function and replace the variables we need. In our case that meant using the header_background and header_text_color settings, retrieved using get_theme_mod(). In our example theme we can then remove these settings from the Customizer since they will now be controlled from the blocks.

After the author creates the blocks-based markup, they can call the migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. class. When this class runs in our example, it will do the following:

  1. Check if there is a template-part with the slug we have defined.
  2. If a template-part with that slug exists, then exit early, there’s nothing to do here since either the user has created their own header (in which case we don’t want to overwrite it), or the migration has already run. If a template-part with the defined slug does not exist, then move on to the next step.
  3. Create a new template post (that is a post in the templates custom post-type that full-site editing will use), and add the contents in there.

Once the migration script creates the header template-part post, that is going to override the “preset” .html template that we have in our theme.
When a user first installs the theme (new installations), they will use the preset (which will contain the defaults and is a basis which users can then customize).
When a user upgrades their installation to the blocks-based version, the theme will retrieve their Customizer settings, build the markup based on what the author has written and created the post which will override the “preset”.

Most things that themes use already exist as blocks in core, or are getting added to make the Full-Site Editing easier.
But there will be things that cannot be directly ported.
One of these things is widgets. Since core widgets already exist as blocks, it is possible to translate them to that new structure. However 3rd-party widgets that don’t exist as blocks will not be easy to be auto-detected and translated.

So far we are running some tests with simple structures and we can say that it is possible to build something to ease transitioning existing themes to block-based themes. But before we start building a proof of concept implementation that we can iterate on and experiment with, we need your assistance and feedback.

What are the things that you feel Full-Site editing would need to have in order for theme-authors to be able to build themes?

If you have ideas on how to ease the transition from widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.-areas to blocks, we’d love to hear them.

Other than non-core widgets, do you foresee issues with converting existing themes to block-based?

Block-based Themes Meeting Agenda for February 19

Below is the agenda for this week’s Block-based Themes meeting.

Time: Wednesday, February 19th 2020, 16:00 UTC
Channel: #themereview

Agenda

  • Welcome
  • Status updates for BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based Theme efforts in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/:
  • Show & Tell: Block styling with CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. variables in the Go theme (@richtabor)
  • Questions & Discussion

If you have any questions you’d like to see raised at this week’s meeting, or any topics or demos you’d like to see in future meetings, please share below.

We also need a volunteer to take notes!

#agenda

Block-based Themes Meeting Agenda for February 5

Below is the agenda for the first Block-based Themes meeting. The goal of this initial meeting is to get everyone on the same page about early full-site editing work in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, so that we can understand how it may effect themes in the future.

Time: Wednesday, February 5th 2020, 16:00 UTC
Channel: #themereview

Agenda

  • Welcome, review the meeting purpose
  • Overview of early blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based theme efforts in Gutenberg:
  • Questions on these topics
  • Propose topics for future meetings

There will be a period at the end of the meeting for folks to discuss how this meeting can be most useful. If you have any topics, demos, or questions you’d like to see discussed at a subsequent meeting, please share below!