Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

setup REST API endpoints for sites outside the network #45

Open
10 of 12 tasks
iandunn opened this issue Dec 23, 2021 · 18 comments
Open
10 of 12 tasks

setup REST API endpoints for sites outside the network #45

iandunn opened this issue Dec 23, 2021 · 18 comments
Labels
[Type] Enhancement New feature or request
Milestone
News: Post-launch...

Comments

@iandunn
Copy link
Member

iandunn commented Dec 23, 2021 •
edited
Loading

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.

  • Create rough endpoints
  • header priority navigation isn't working, script isn't enqueued
  • WP sites that aren't part of the w.org network (like Profiles) will need to run wp_head() on their end, but integrate results into <head>
  • Add a styles route to fetch only the global styles
  • let client customize <title>
  • don't output wp_head() / wp_footer() things like <link> that aren't meant for the client
  • change URLs of RSS links etc to match the client's URL
  • check for unintended side effects on google analytics, like does it mistake one site for the other?
  • Get feedback from Trac, Openverse, etc
  • Iterate based on feedback
  • Remove ugly die() hack, send text/html properly through API instead
  • restrict endpoint to certain sites?
@iandunn iandunn mentioned this issue Dec 23, 2021
Closed
30 tasks
@iandunn iandunn changed the title setup REST API endpoint for sites outside the network, test on Profiles setup REST API endpoint for sites outside the network Dec 23, 2021
@iandunn iandunn added this to the News launch milestone Dec 23, 2021
@iandunn iandunn added the [Type] Enhancement New feature or request label Dec 23, 2021
@iandunn iandunn changed the title setup REST API endpoint for sites outside the network setup REST API endpoints for sites outside the network Dec 23, 2021
@iandunn
Copy link
Member Author

iandunn commented Dec 28, 2021

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 iandunn mentioned this issue Jan 3, 2022
Closed
7 tasks
@iandunn
Copy link
Member Author

iandunn commented Jan 3, 2022

🤔 , 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. WordPress/wporg-news-2021#13 is a blocker for that, of course.

@tellyworth
Copy link
Contributor

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

@iandunn
Copy link
Member Author

iandunn commented Jan 4, 2022

🤔 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 added a commit that referenced this issue Jan 4, 2022
@iandunn
Header/Footer: Add API route stubs.
373b3fe 
These are still experimental and may change significantly.

See #45
@iandunn
Copy link
Member Author

iandunn commented Jan 4, 2022

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 iandunn mentioned this issue Jan 4, 2022
Closed
6 tasks
@iandunn
Copy link
Member Author

iandunn commented Jan 4, 2022

@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
Copy link
Member

zackkrida commented Jan 4, 2022 •
edited
Loading

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

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

CleanShot 2022-01-04 at 15 17 44@2x

  • The footer appears unstyled. There are inline style tags in the markup so it might be some kind of namespacing/versioning/class mismatch

CleanShot 2022-01-04 at 15 14 53@2x

@iandunn
Copy link
Member Author

iandunn commented Jan 4, 2022

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
Copy link
Member

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
Copy link
Member

I haven't tested that yet, though

You're correct! 🥳

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

.

@dd32
Copy link
Member

dd32 commented Jan 13, 2022 •
edited
Loading

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.

  • Header split in two parts
  • <script> tags all need to be CDATA wraped.
  • <foo bar> is invalid, needs to be <foo bar="">, there's a <link rel.. crossorigin> and several data-* attributes in .global-header__navigation.
  • <foo> is invalid, needs to be <foo />. <link>'s and <input type="search" are the main ones.
  • wp-trac.css has a bunch of overrides for Trac styles that are applied by #wporg-header and #wporg-footer

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 WordPress/wordpress.org#50 for a more up to date one **

@iandunn
Copy link
Member Author

iandunn commented Jan 13, 2022

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.

@iandunn iandunn mentioned this issue Jan 15, 2022
Closed
4 tasks
@dd32
Copy link
Member

dd32 commented Jan 17, 2022

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 WordPress/wordpress.org#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
Copy link
Member

dd32 commented Jan 17, 2022

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

These were fixed in WordPress/wordpress.org@e3318ae

@dd32
Copy link
Member

dd32 commented Jan 17, 2022

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

@iandunn
Copy link
Member Author

iandunn commented Jan 17, 2022

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
Copy link
Member Author

iandunn commented Jan 19, 2022

I added a styles route In 00afe59, 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
Copy link
Member Author

iandunn commented Jan 20, 2022

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

@iandunn iandunn removed this from the News: Post-launch iteration 1 milestone Feb 25, 2022
@iandunn iandunn added this to the News: Post-launch iteration 2 milestone Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Type] Enhancement New feature or request
Projects
None yet
Milestone
News: Post-launch iteration 2
Development

No branches or pull requests
4 participants
@iandunn @dd32 @zackkrida @tellyworth