jquery / infrastructure-puppet

Puppet configuration for jQuery Infrastructure servers.
MIT License
7 stars 9 forks source link

Archive plugins.jquery.com, replace with static site #29

Closed Krinkle closed 5 months ago

Krinkle commented 1 year ago

Follow up from https://github.com/jquery/infrastructure-puppet/issues/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 https://github.com/jquery/infrastructure-puppet/issues/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

Krinkle commented 1 year ago

Some possibly relevant commits in the private infrastructure repo:

Krinkle commented 11 months ago

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 commented 9 months ago

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 commented 9 months ago

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

timmywil commented 9 months ago

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

Krinkle commented 8 months ago

@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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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

timmywil commented 8 months ago

I like that idea. I say we can update the existing learn page.

mgol commented 8 months ago

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.

timmywil commented 8 months ago

I've added a checklist to the ticket description

timmywil commented 6 months ago

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.

timmywil commented 5 months ago

Added a page to the learn site for publishing to npm: https://github.com/jquery/learn.jquery.com/pull/818

timmywil commented 5 months ago

Unless @Krinkle or @mgol see anything else, I think we're ready to deploy the static plugins site.

Krinkle commented 5 months ago

@timmywil When you transfer the repo, I suggest picking a slightly longer (or different) name than plugins.jquery.com so as to not overwrite the invisible https://github.com/jquery/plugins.jquery.com/ redirect (e.g. for https://github.com/jquery/plugins.jquery.com/issues/161) for the repo that used to be there, and its permalinks.

So next step.. puppetise alongside the bugs static sites?

timmywil commented 5 months ago

I suggest picking a slightly longer (or different) name than plugins.jquery.com

Will do. Should I do that before deployment?

puppetise alongside the bugs static sites?

yes, that sounds right.

Krinkle commented 5 months ago

I suggest picking a slightly longer (or different) name than plugins.jquery.com

Will do. Should I do that before deployment?

Yeah, I think we'll want to have prod pull/subscribe to the content from within the jquery org.

timmywil commented 5 months ago

Transferred to https://github.com/jquery/plugins.jquery.com-static and added infrastructure team.

Krinkle commented 5 months ago
  • Remove existing plugins site droplet

I've ticked this off with the droplet being turned off. I'll track the last decom step in https://github.com/jquery/infrastructure-puppet/issues/8.