search

WordPress / wporg-mu-plugins

Development of the Global Header and other mu-plugins used on WordPress.org.
58 stars 28 forks source link

setup REST API endpoints for sites outside the network #45

Open iandunn opened 2 years ago

iandunn commented 2 years ago

Profiles, Trac, Codex, etc can't load the new header/footer directly; either because they're on a different multisite network, or because they're not WP at all.

the best solution might be to create REST API endpoints that output the markup and inline styles. they could basically just call the blocks and buffer the output, I'm guessing.

Profiles is probably the easiest to test on, since there's no docs on how to setup a Trac/Codex local env (if that's even practical), or on how to access the production instances

This already exists, kind of, for rosetta localised sub-sites. https://de.wordpress.org/?fetch-custom-header=%2Fplugins%2F

38

It'd be nice to create a standard WP-API endpoint, though.

iandunn commented 2 years ago

it may be best if the endpoint just returns the raw data -- url, anchor text, parent id, is active, etc -- and the block generates the markup.

that way the markup generation can be DRY, and we won't have to change the endpoint in the future if we want to change the markup, reuse it in other contexts, etc.

iandunn commented 2 years ago

🤔 , although, that would mean Trac etc have to generate matching markup, which will probably lead to things being out of sync.

So maybe the endpoint should just call render_global_header() and render_global_footer(), and return the generated markup (which will include inline styles, and <link> tags for external stylesheets).

We might want one endpoint for the header, and one for the footer?

If it'd help avoid News-specific styles bleeding into the global markup, we could setup a site like w.org/global-header-footer. That could have a blank child theme, so it'd only have the theme.json etc of the parent theme. https://github.com/WordPress/wporg-news-2021/issues/13 is a blocker for that, of course.

tellyworth commented 2 years ago

Could the endpoint simply be a static HTML file, that's re-rendered periodically (or at deploy)?

iandunn commented 2 years ago

🤔 How were you picturing the static HTML would get updated?

Would it include everything in <head>? If how, how would it customize it for Trac vs Codex vs Openverse etc? If not, how would those sites get the inline and external styles?

Even if we don't use that for production, it might be good to setup stub endpoints soon with a copy/paste of the HTML/CSS. That'd allow folks to start work on Trac etc, while a dynamic solution is figured out here.

iandunn commented 2 years ago

I started to create static stubs, but tried out the dynamic approach in 373b3fe just to see what would happen. Luckily it didn't take much to get it working.

We'll need to test it out on Trac, Openverse, etc to see if it meets all the various needs, though.

iandunn commented 2 years ago

@zackkrida , what do you think about these endpoints?

They're very rough/experimental. Let us know if a different approach would work better for you, if you'd need some customizations (like for <title>), etc.

zackkrida commented 2 years ago

@iandunn Those are awesome! This approach is fine. Some specific things I've noticed you may be aware of:

iandunn commented 2 years ago

The menu item truncation with the ellipsis (...) isn't working in the header

🤔 good catch. It looks like the script for it isn't being enqueued. I'll add a task for that 👍🏻

The footer appears unstyled

I'm guessing that's just because the inlined styles rely on external stylesheets that are included in the header. Once both are embedded on the same page, it should work.

I haven't tested that yet, though.

zackkrida commented 2 years ago

I'm guessing that's just because the inlined styles rely on external stylesheets that are included in the header. Once both are embedded on the same page, it should work.

Ah, that makes sense, thanks!

zackkrida commented 2 years ago

I haven't tested that yet, though

You're correct! 🥳

CleanShot 2022-01-04 at 15 37 18@2x

.

dd32 commented 2 years ago

Implemented headers for WordPress Planet & Codex via #62

header priority navigation isn't working, script isn't enqueued Remove ugly die() hack, send text/html properly through API instead

In doing that, I've also fixed the above issues - the header had to be rendered on the footer endpoint, to ensure that anything the header triggered to be enqueued was output in the footer, and removed the die().

Trac

Implementing this into Trac is going to require a bunch more work.. Trac Genshi templates are full XHTML documents, and our new header/footer are HTML5.. but it's possible.

In all honesty, A static header for Trac is going to more viable.

A middle-ground might be an external script to simply run to update the Trac templates, using a HTML2XHTML type application, unless I can convince DOMDocument to output the rendered HTML in an XML format Trac will accept.

After the above issues are fixed, we end up with this:

Removed Image, see https://github.com/WordPress/wordpress.org/pull/50 for a more up to date one

iandunn commented 2 years ago

the header had to be rendered on the footer endpoint, to ensure that anything the header triggered to be enqueued was output in the footer

😆 , good catch!

Implementing this into Trac is going to require a bunch more work.. Trac Genshi templates are full XHTML documents

Ouch.

Can Genshi be configured to use HTML5?

Or maybe we could migrate to Jinja2? It seems like it supports HTML5. I'm not sure how far along Trac's support is, though.

There's also the genshihtml5 extension

But yeah, a static option may be simpler, as long as we can automate it.

dd32 commented 2 years ago

Can Genshi be configured to use HTML5?

That only affects it's output, not it's input templates.

Or maybe we could migrate to Jinja2?

Jinja is the default trac template now I believe, but I don't think writing a new theme for Trac is of the upmost importance right now..

The genshihtml5 extension may be worthwhile looking into though, as it appears to do exactly that, allow html5 to be used as an input template

But yeah, a static option may be simpler, as long as we can automate it.

Looks like I failed to mention https://github.com/WordPress/wordpress.org/pull/50 here - I've got a simple PHP script in that PR that uses DomDocument to read HTML and spit out XHTML. With a few syntax corrections for <style> and <script> it's mostly working with just a jQuery error. If you know my personal test trac instance URL, it's in operation there currently.

dd32 commented 2 years ago

wp-trac.css has a bunch of overrides for Trac styles that are applied by #wporg-header and #wporg-footer

These were fixed in https://github.com/WordPress/wordpress.org/commit/e3318ae10ae886b4cf00879dd6a14e8f22b611a4

dd32 commented 2 years ago

Ugh, Too many issues covering the same things :) Trac is over here: #53

iandunn commented 2 years ago

I've got a simple PHP script in that PR that uses DomDocument to read HTML and spit out XHTML

Ah, nice! That WFM 👍🏻

iandunn commented 2 years ago

I added a styles route In 00afe5917bca3d5b52bdfd6e5b5c703f73920452, for #81 . That lets sites fetch only the global styles, if they want to generate the markup themselves.

That's probably only useful for WP sites that aren't in the w.org network, but it could be useful if we decide to hardcode the markup for trac/codex/etc.

iandunn commented 2 years ago

Moving to post-launch, since the work we've done so far has gotten Profiles/Trac/Codex working.