The homepage reads "WordPress: Publish your passion". Since WordPress is more than that, it would be good to see a range of options there in a rotating headline: “Publish your ______?” And we can get quirky there. Something like 3-5 good options, with the specific copy to be explored.

As a simple starting point, the headline block does not need to be interactive, and can simply surface hardcoded options:

This would presumably simplify ensuring a well translatable and accessible solution, and can grow into bigger things if need be in the future.

Semantically, one option could be to have the first heading be static, the subsequent 2-5 headings to swap out with be fake and, then pair it with a hidden heading announcing the a full range. Something like:

• “Publish your passion”
• “Publish your diary”
• […]

And then in the hidden heading, “Publish your passion, your diary, your […], or your […] with WordPress”. Something to explore and vet in practice.

Here's the proposed design for the download subpages: Releases, Beta/Nightly, Source Code, Counter that @beafialho, @critterverse, and I have worked on this file.

I'll share the proposals for the desktop and mobile pages and mention some aspects of the design that could be categorized as 'nice to have'. At the end of the issue I'll add some notes about the navigation of these internal pages:

Releases

Nice to have

• Instead of listing every release on the same page, older releases could be accessed through a list at the bottom of the page. We could either load each table under the Past releases section or have a separate page per version.
• Each major release is identified with both the version number and its code name.

Beta/Nightly

Counter

Something we could explore on this page is a smoother transition between numbers. We could also review the font we chose and use a monospaced one so the numbers stay in the same position as the numbers increase.

Source code

Navigation

The other challenging aspect of these designs are the subnavigations: on smaller viewports our proposal is for the right-side lists to collapse into dropdowns.

Figma file with the designs.

The images on the home page are a bit blurry, and it would be great to improve their resolution.

I've already added a new version of the "Powerful and empowering" illustration. In the case of the showcase section, instead of loading one big picture, I think we could use a grid of images. To explore that solution, I've created a temporary page here (the individual images can be found on this Figma file)

It seems to work fine, except that in the tablet and mobile versions padding is added around the section. Does this approach make sense? Would it be possible to remove that padding?

Add a new block, "Cycle Headings." This block renders "WordPress: _____", where the blank space cycles through a set of phrases.

• Publish your passion
• Grow your business
• Flex your freedom.

These change after 5 seconds.

Semantically, it renders a hidden heading (h1) & paragraphs, and this visual content is hidden from screen readers. JS is used to swap the displayed text, with a CSS transition on the opacity. This a version of the code used on the p2 landing site, tweaked to work with the block output.

The front-page template is updated to use this block.

Fixes #101.

Screen reader users will hear "Heading level 1: WordPress: Publish your passion. Publish your passion. Grow your business. Flex your freedom."

There is no change to the headings if you're using "prefers reduced motion", just to be safe.

Screenshots

https://user-images.githubusercontent.com/541093/186962227-4ffb1c4c-e38f-4cd1-b50d-fcc6c47ce58a.mp4

In the editor, it's just a static block with the main heading. Eventually we could offer some way to enter a few headings & pass them through as attributes (TBH I could add this pretty quickly now, just as some text inputs in the sidebar). Font size & spacing can be controlled here, though it defaults to the H1 styling.

Fonts don't load in the editor on local envs, it's correct on w.org

How to test the changes in this Pull Request:

1. Build the branch, yarn workspace wporg-main-2022-theme build
2. Load the front page
3. Wait 5 seconds, you should see the heading change
4. It should cycle through all 3 headings

Optionally…

• Try with a screen reader - it should make sense
• Try with reduced motion on (will need to reload the page) - it won't change

What back-end performance issues, current or potential, do we need to consider improving?

Server response time is the top issue raised by Lighthouse when running locally. Obviously that's affected by Docker speed. Are there any server-side issues in staging or likely in prod?

• [x] Resize images
• [x] Consider using webp (maybe? can Proton help with this?)
• [ ] Check wpdb query count
• [x] Check object caching

Fixes #130, See #129 — This adds a new block for the Download Counter. It live-updates from a new API endpoint every 5 seconds.

The new API endpoint is /wporg/v1/core-downloads/[branch]/, and it uses the same SQL request as the current page. On local sites it uses a workaround to avoid calling a table that doesn't exist, that's described in the code.

There's also a new shortcode, for stable_branch, which is a different constant (WP_CORE_STABLE_BRANCH) than the existing latest_release shortcode. This is used in the heading on the Counter page.

⚠️ This branch is built on #131 (add/download-subpages), not trunk. The other branch enables the new theme on the download subpages so this can be tested.

Screenshots

Design-wise, there was a comment about using a monospace font to prevent the numbers jumping around - I went ahead and applied that, but we can still try out different styles. I didn't add any animation, so it just updates to the next number.

https://user-images.githubusercontent.com/541093/194117814-133151c3-399d-4652-9a1a-3f289e9cefb0.mp4

Old version data is still accessible with the ?branch=5.9 query parameter (a current feature of the page).

The font scales down on small screens.

In the editor, the block doesn't live-update, but it does display the latest count.

How to test the changes in this Pull Request:

This works best on a sandbox, since you can see the real download counts, but it's still possible to test locally.

1. View the Counter page
2. Try passing different branches, ex: /download/counter/?branch=5.9
3. Use the block on other pages to test the editor interface — font, color, & spacing should be customizable

Let's put together a checklist of any front-end performance issues (current or potential) that need to be considered. We may not fix them all for initial launch, but the sooner we know about them the better.

• [x] Use webp for images
• [x] Load the download modal JS only on download page
• [x] Load the MU Latest Posts block JS in the footer
• [x] Largest Contentful Paint image was lazy loaded

In some links (the CTA style text links), the link text includes an arrow icon. The mockup uses the ↗ character, but on the staging site WordPress is converting it to ↗️ (oops, so does github).

| Mockup | Staging site | |---------|---------| | | |

It would be best if we could use the arrow character itself so it can respond to any link color.

As long as the big type remains with this size, this should be the font weight for this CTA, which will be used in other places in the website.

| Site (Regular) | Mockups (Light) | | ---- | ---- | | | |

Also noticed the "Get WordPress now" in the paragraph is not a link on the site. If it's on purpose, maybe we should just remove it as it's redundant?

This adds a new build:patterns script that will generate updated pattern files in the theme, based on edited post content.

It includes some hard-coded parts initially, this is a starting point with some decisions still to make. For example:

• Currently it treats w.org/main-test/ as the canonical source of content. Should that become w.org itself, or a staging site?
• Should it directly fetch the remote content (as it does now) or rely on 'setup:refresh' and use the local version of content?
• Which of those will make translation easier?
• Where should the URLs and corresponding output files be defined?
• How could it programatically discover newly created pages on the staging/canonical site?
• Should this be done locally by devs, or as part of the sandbox sync?

To use/test:

yarn build:patterns

..then git diff and check that it has generated updated files in source/wp-content/themes/wporg-main-2022/patterns.

Ref: https://wordpress.slack.com/archives/C02QB8GMM/p1660640323188989?thread_ts=1658956086.933959&cid=C02QB8GMM

The fonts files seem larger than usual, let's see if we can reduce their sizes.

Closes #150

Adds a template and pattern for the Enterprise page. Some custom styles have had to be added, mostly for the logo grid which changes layout significantly on mobile.

Remaining tasks:

• [x] Prod quality images
• [x] Escaping
• [x] Arrow styling for last section
• [x] Heading hierarchy
• [x] A11y
• [x] Lighthouse Perf and a11y tests

Props @bengreeley

Screenshots

| Desktop | Tablet | Mobile | |--------|-------|-------| | | | |

How to test the changes in this Pull Request:

1. Add an 'Enterprise' page with slug enterprise (an existing page may need to be deprecated in your site)
2. Rebuild the styles yarn workspace wporg-main-2022-theme build
3. Test the responsive layout

During the redesign of the Enterprise page, @thetinyl made minor updates but found there was an opportunity for a larger overhaul of content. I'm linking to her notes for when the time comes that we should revise the content. https://github.com/WordPress/wporg-main-2022/issues/150#issuecomment-1339771950

Editing a page without a block template means changes would immediately go live. This prevents it entirely, which means the workflow requires a dev to create the page template before a designer can start editing.

How to test the changes in this Pull Request:

1. Log in as a Designer user
2. Go to wp-admin / Pages / All Pages
3. Pages that have templates (like Download) should have an Edit button; others (like Enterprise currently) should not.

This Pull Request is driven by a recent design change made in the wporg-showcase redesign where the content is now left aligned and the font size is 20px. (Showcase Figma).

Related https://github.com/WordPress/wporg-showcase-2022/pull/60.

Screenshots

| Before | After | | -------| -------| | | |

There are no visual changes for mobile & tablet views.

How to test the changes in this Pull Request:

1. Pull changes, load homepage.

Existing page content needs to be converted to use this design. Most of the work should be doable in the post editor, using styles and blocks that already exist in the theme.