Archive plugins.jquery.com, replace with static site #29
Comments
|
Some possibly relevant commits in the private infrastructure repo:
|
|
The site is still up but now pinned to a fixed of the jquery-wp-content repository to avoid subtle changes or breakage prior to its archiving. Especially given that this site runs on a much older version of WordPress, an older PHP, and Keeping compatibility with that is basically impossible. It also enables some other change I have in mind to be done in a way that would be simpler if we don't need to keep compatibility with this setup in mind. Noting this here as I'll refer to this from those would-be-breaking commits. |
|
The archive is available at https://github.com/timmywil/plugins.jquery.com with preview at https://timmywil.com/plugins.jquery.com/. I plan to move this repo to the jQuery org when we get closer to deployment. |
|
@timmywil Looks good to me! There's one thing I noticed that might make it a bit hard to use, which is the search feature seems to be indexing all pages, and all text on those pages. In particular, it is indexing non-latest versions of plugin pages, and non-content text. For example,
If that's easy to exclude, that might be worthwhile. Otherwise, good to go! I noticed this site has a different favicon than we normally use, it's in light blue instead of regular blue, and a bit smaller/more padding around it. It looks nice though, perhaps something to backport to |
|
Yeah, I had just done the defaults, but we can certainly tweak the search index. |
|
@timmywil Currently the site has the following sentence on the homepage:
The static site has instead:
The mention of the keyword and link to blogpost seemed useful, but I haven't read it in detail. Do you agree? |
|
I removed the blog post link because it was the legacy blog and I worry it may 404 at some point. But mostly, I think the audience needs to change. The former assumed the reader was a jQuery plugin author, but I think the majority of readers will be those searching for jQuery plugins, in which case the mention of the "jquery-plugin" keyword is confusing. The link to |
|
If we're worried about the page getting 404'd, we can link to Web Archive (https://web.archive.org/web/20230909014003/https://blog.npmjs.org/post/111475741445/publishing-your-jquery-plugin-to-npm-the-quick). But I understand the audience argument. The issue is, though, that if authoring docs should go elsewhere then it'd be good to have them in that place. Right now we remove without a replacement. |
|
Perhaps a new page on jquery.com would make sense, e.g. The existing link on jquery.com named "Plugins" can then be pointed to that instead, and from the plugins.jquery.com homepage we can point there as well with a label like "Learn more about authoring and publishing plugins". |
|
I like that idea. I say we can update the existing learn page. |
|
That works for me but I’d prefer to have the learn page updated before we switch the plugins site to one without this text. |
|
I've added a checklist to the ticket description |
|
Search indexing has been refined on https://timmywil.com/plugins.jquery.com/. I think I addressed all the examples in Timo's comment above, but I left in matching on dates. I could see that being useful, but not in the form it was in before. Now, it matches on author name first and it only matches on the date the latest version of the plugin was released, as opposed to matching on all plugin version release dates, which pretty much matched all plugins. |
* Update label from JSF to OpenJSF, follows-up 50cbaf8. * Update support/evenets links to match current jquery.com. * Remove "Plugins" from global nav, since it's merely a self-link here and likely not to stay on the main sites. Ref jquery/infrastructure-puppet#29
* Update label from JSF to OpenJSF, follows-up 50cbaf8. * Update support/evenets links to match current jquery.com. * Remove "Plugins" from global nav, since it's merely a self-link here and likely not to stay on the main sites. Ref jquery/infrastructure-puppet#29
|
Added a page to the learn site for publishing to npm: jquery/learn.jquery.com#818 |
|
@timmywil When you transfer the repo, I suggest picking a slightly longer (or different) name than So next step.. puppetise alongside the bugs static sites? |
Will do. Should I do that before deployment?
yes, that sounds right. |
Yeah, I think we'll want to have prod pull/subscribe to the content from within the jquery org. |
|
Transferred to https://github.com/jquery/plugins.jquery.com-static and added infrastructure team. |
* Enable the h1 heading. The page content has no custom h1 of its own so looks out of place with other pages on jquery.com. * Invert the order of some paragraphs so that links are clear and at the top, with a single recommended option each time and then other links in a bullet list after it. E.g. there is now an actual "Download jQuery 3.7.1" button, describing over top that it is the compressed production version, and then a list of other links. Explanations of these files now follow the list instead of being in front of it, thus burying the links less. * Promote link to browse releases.jquery.com to the first section. I've personally never used the links that were in the first section previously as they always felt like too much text to read. When I land on the releases list, I know what each variant is and feel more confident that I'm getting the right one instead of reading the long link labels. If we like this direction and shorter links, taking into account that many people probably already "start" at releases.jquery.com based on links to there from other places and thus only see the short versions there, we could also explore shortening the labels here. I've not done that in this commit yet. * Remove outdated info about source maps still being a future/emerging technology. * Remove instructions for Bower. * Improve "Yarn" CLI link readability by giving it the full term as its link label, "Yarn CLI" instead of only partly linked. * Improve "npm" sentence by linking "npm" and then naming "jquery package" in the second link. * Update Pre-Release section to link to releases site instead of to a single file, since there are now quite a lot of variants of this file that people may want to choose between. * Update "jQuery CDN" section heading to link to the releases site from its name, and remove outdated sponsorship mention. * Improve "Other CDNs" by applying the bolding more focussedly (when an entire paragraph is bold, it's the same as bolding nothing, is my rule of thumb). Ensure the bolded portion is readable and understandable by itself. * Remove "Build from Git" section, covered by README where it is presumably more up to date. This is linked to from "About the code". * Remove mention of closed jQuery Forum from "About the code", instead link to "Report a bug", matching the link chosen at jquery/jquery-wp-content#220. * Remove mention of plugins.jquery.com from "About the code". Ref jquery/infrastructure-puppet#29.
* Enable the h1 heading. The page content has no custom h1 of its own so looks out of place with other pages on jquery.com. * Invert the order of some paragraphs so that links are clear and at the top, with a single recommended option each time and then other links in a bullet list after it. E.g. there is now an actual "Download jQuery 3.7.1" button, describing over top that it is the compressed production version, and then a list of other links. Explanations of these files now follow the list instead of being in front of it, thus burying the links less. * Promote link to browse releases.jquery.com to the first section. I've personally never used the links that were in the first section previously as they always felt like too much text to read. When I land on the releases list, I know what each variant is and feel more confident that I'm getting the right one instead of reading the long link labels. If we like this direction and shorter links, taking into account that many people probably already "start" at releases.jquery.com based on links to there from other places and thus only see the short versions there, we could also explore shortening the labels here. I've not done that in this commit yet. * Remove outdated info about source maps still being a future/emerging technology. * Remove instructions for Bower. * Improve "Yarn" CLI link readability by giving it the full term as its link label, "Yarn CLI" instead of only partly linked. * Improve "npm" sentence by linking "npm" and then naming "jquery package" in the second link. * Update Pre-Release section to link to releases site instead of to a single file, since there are now quite a lot of variants of this file that people may want to choose between. * Update "jQuery CDN" section heading to link to the releases site from its name, and remove outdated sponsorship mention. * Improve "Other CDNs" by applying the bolding more focussedly (when an entire paragraph is bold, it's the same as bolding nothing, is my rule of thumb). Ensure the bolded portion is readable and understandable by itself. * Remove "Build from Git" section, covered by README where it is presumably more up to date. This is linked to from "About the code". * Remove mention of closed jQuery Forum from "About the code", instead link to "Report a bug", matching the link chosen at jquery/jquery-wp-content#220. * Remove mention of plugins.jquery.com from "About the code". Ref jquery/infrastructure-puppet#29.
* Enable the h1 heading. The page content has no custom h1 of its own so looks out of place with other pages on jquery.com. * Invert the order of some paragraphs so that links are clear and at the top, with a single recommended option each time and then other links in a bullet list after it. E.g. there is now an actual "Download jQuery 3.7.1" button, describing over top that it is the compressed production version, and then a list of other links. Explanations of these files now follow the list instead of being in front of it, thus burying the links less. * Promote link to browse releases.jquery.com to the first section. I've personally never used the links that were in the first section previously as they always felt like too much text to read. When I land on the releases list, I know what each variant is and feel more confident that I'm getting the right one instead of reading the long link labels. If we like this direction and shorter links, taking into account that many people probably already "start" at releases.jquery.com based on links to there from other places and thus only see the short versions there, we could also explore shortening the labels here. I've not done that in this commit yet. * Remove outdated info about source maps still being a future/emerging technology. * Remove instructions for Bower. * Improve "Yarn" CLI link readability by giving it the full term as its link label, "Yarn CLI" instead of only partly linked. * Improve "npm" sentence by linking "npm" and then naming "jquery package" in the second link. * Update Pre-Release section to link to releases site instead of to a single file, since there are now quite a lot of variants of this file that people may want to choose between. * Update "jQuery CDN" section heading to link to the releases site from its name, and remove outdated sponsorship mention. * Improve "Other CDNs" by applying the bolding more focussedly (when an entire paragraph is bold, it's the same as bolding nothing, is my rule of thumb). Ensure the bolded portion is readable and understandable by itself. * Remove "Build from Git" section, covered by README where it is presumably more up to date. This is linked to from "About the code". * Remove mention of closed jQuery Forum from "About the code", instead link to "Report a bug", matching the link chosen at jquery/jquery-wp-content#220. * Remove mention of plugins.jquery.com from "About the code". Ref jquery/infrastructure-puppet#29.
I've ticked this off with the droplet being turned off. I'll track the last decom step in #8. |
Follow up from #6, in which we moved all ~20 doc sites to new infrastructure as simple standalone WordPress sites. There is one site we haven't migrated yet: https://plugins.jquery.com/.
This looks like a fairly stateful site, and also lacks a staging site. It includes several custom build steps that we haven't ported over yet, and I'm actually not sure that it would re-create the same site even if we do run it from scratch since the underlying sources may have dissappeared or significantly changed.
We could try to copy and upgrade the existing database as-is, but maybe we want to use this chance to turn it into a static site (like #10). Possibly a bit simpler and slimmed down only an index listing with a page for each plugin (URL-compatible) showing the plugin meta data (description, author, links to website/docs/bugs), so that it's easy for people to find what this points to and where to find source code, updates, contact persons, or forks going forward.
Remaining items
The text was updated successfully, but these errors were encountered: