MooTools plugins: how to maintain or replace an older collection

Older MooTools sites often grew one plugin at a time: a carousel, a tooltip, an accordion, and an image overlay. The result can be difficult to update because the widgets share a framework while each assumes a different set of behaviors.

This is a maintenance guide at the original collection’s address. It does not offer an unverified bundle of old plugins as a current starter kit.

Make an inventory first

Record the exact MooTools Core version, any MooTools More modules, each plugin file, and where it runs. Preserve the distributed licenses and your local modifications.

Look for code that extends native objects, assumes global variables, or attaches document-wide listeners. Those details can explain why an apparently unrelated component breaks when a library changes.

Replace by user task

• A simple accordion may become native details and summary markup.
• An image overlay may become a properly labeled dialog.
• A horizontal gallery may use native scrolling and scroll snap.
• A visual transition may belong in CSS, with a reduced-motion alternative.

Choose a replacement because it meets the required behavior, not simply because its package is newer. A modern widget can still mishandle focus or load far more code than the task needs.

Migrate one component at a time

Write down the existing input, output, keyboard behavior, and failure state. Replace the component behind that boundary, compare it on the pages that actually use it, then remove the old initialization code and listeners.

Only remove MooTools when the inventory shows that nothing still requires it. Keep a rollback point, test long content and narrow screens, and avoid combining the migration with an unrelated visual redesign. Smaller changes make regressions much easier to diagnose.