Archive plugins.jquery.com, replace with static site

[Krinkle]

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

• Search index improvements
• Update https://learn.jquery.com/plugins/ with npm authoring note
• Deploy plugins site to miscweb
• Remove existing plugins site droplet
• Transfer plugins repo to the jQuery org

[Krinkle]

Some possibly relevant commits in the private infrastructure repo:

• https://github.com/jquery/infrastructure/commit/0037f09d7471f4c03c623688228220180d64ae89 Remove unused jquery::plugins class.
• https://github.com/jquery/infrastructure/commit/daf2d9729f2e274abdf8a319a8b84f9c43c1915a Remove unused jquery/templates/plugins.erb file.

[Krinkle]

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
runs WordPress in the "Multisite" configuration which is significantly differennt from how other prod sites work, and therefore also different from the current local development and staging environment.

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.

[timmywil]

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.

[Krinkle]

@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,

• ScrollMagic, results in many seemingly duplicate results for previous versions.
• Jan, matches everything with a January release date, as opposed to things titled, described or authored by a "Jan".
• school, matches all pages because of the "This version is old school" notice in the layout.
• "view homepage", mathces all pages because of the "View Homepage" button in the layout.

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 jquery-wp-content/themes/*jquery.com/ and jquery-wp-content/themes/*jquery.org/`?

[timmywil]

Yeah, I had just done the defaults, but we can certainly tweak the search index.

[Krinkle]

@timmywil Currently the site has the following sentence on the homepage:

We recommend moving to npm, using "jquery-plugin" as the keyword in your package.json. The npm blog has instructions for publishing your plugin to npm.

The static site has instead:

We do not recommend using any versions of plugins from this registry. Please find jQuery plugins on npm.

The mention of the keyword and link to blogpost seemed useful, but I haven't read it in detail. Do you agree?

[timmywil]

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 npm does still have the jquery-plugin keyword so that they can find jQuery plugins, but plugin authoring docs should go elsewhere.

[mgol]

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.

[Krinkle]

Perhaps a new page on jquery.com would make sense, e.g. jquery.com/plugins/, or something to add to https://learn.jquery.com/plugins/.

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".