-
Notifications
You must be signed in to change notification settings - Fork 3
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.
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
Add menus #91
Conversation
Also, I need to update the docs. Will do that now. |
Since the menus are a plug-in and a non standard Wordpress feature, I'm not sure if the naming should be in the schema. What if they use another menu plugin? |
What happens if we use another menu plug-in? Would like to have a more declarative way to connect to custom endpoints. |
Reminds me that we need to document that the module works with out-of-the-box WordPress and makes no assumptions about plug-in usage. |
Since all we need to do here is hit an explicit menu API route, without any additional processing, we could just create a generic API downloader. This wouldn't be tied to any specific Wordpress plugin. It could be configured for each site in a plugin-agnostic way. Example: "ApiDownloads": [
{
"Path": "wordpress/menus/header-menu.json",
"Source": "/wp-json/menus/v1/menus/header-menu"
}
] Menu problem solved, schema stays clean from plugins. If we did need to process the API calls before writing out to the repo, then perhaps we could create a plugin interface for wordpress-to-github itself. But that might be too much for now. |
@@ -9,6 +9,13 @@ | |||
"PostPath": "wordpress/posts", | |||
"PagePath": "wordpress/pages", | |||
"MediaPath": "wordpress/media", | |||
"ApiRequests": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this.
Another option (to add to our general thinking) for handling third-party plugins:
I share this because we will need to adapt the menu to other data sources. WordPress has its own specific data structure. We don't need to find all the solutions right now (until we have real situation where we can use or prototype with another CMS), but we can think about CMS agnosticism, plugin changes, upgrades, platform updates & how a system that doesn't have a menu feature could use fields to recreate the menu? For example, if using Contentful, there is not going to be a menu built in, and if there was a third-party service, it's guaranteed that the API structure won't be the same, but we still want the design system component to render the same output. Questions for thought
EDIT: looking at this again, the API connector would benefit from its own WP plugin & its own plugin - in this case, there are two packages involve - a WordPress UI (third party, no API) & a cagov WP plugin that extends an monolith UI with an API. Can definitely see this pattern happening more often with other features, if UI's are mature but API integrations are not. |
These are good questions. I was very tempted to go down this road before retreating to the much simpler (for now) So, ideation time. We could deploy a plugin system. Let's call it cms-to-github. We would have separate plugins for the menu, Contentful, etc. Even wordpress-to-github could become a plugin of this system. The cms-to-github program would execute the code within each plugin before dumping all the output to GitHub. This might behave similarly to Rollup. Sounds good to me. But as you point out, I think it would be difficult to effectively architect this system until we have more examples/scenarios where it'd be useful. |
This is ready for another review. Here's the revised interface for wordpress-to-github.config.json files. "ApiRequests": [
{
"Destination": "wordpress/menus/header-menu.json",
"Source": "/wp-json/menus/v1/menus/header-menu",
"ExcludeProperties": ["description"]
}
] Some notes follow.
Questions.
|
This is good iteration as-is in my opinion. Would solve the immediate need for adding api endpoints. I like the cache testing debug option. |
|
Issue to add change-log - #105 |
Something like JSONata might work well here. |
(I updated the readme files to match the new split) |
Per cagov/drought.ca.gov#126, this PR adds support for navigation menus to wordpress-to-github.
Before, we called the Wordpress menu API directly from the 11ty build. The problem with this approach is that changes to the menus would not trigger an 11ty build. We'd need to wait for something else to trigger another 11ty build before the menus would update.
This change to wordpress-to-github will now fetch menus and deposit them into the 11ty site repo as static files. Hence, builds will now get triggered upon menu changes, since we're dropping new/updated files into the repo.
Among everything else, one specific thing to confirm is the caching strategy for menus here. I wasn't sure how to test that locally.
Note: sample output is available in the automation-development-target repo.