Categories and products

Categories and products are staged the same way as CMS content: open the edit form in the Magento admin, make your changes and choose MageDrop › Save & Stage instead of Save. This page covers what that means for catalog data in particular: which parts of the form are captured, how store views work, what happens to images, and what a deploy and a rollback do.

Category and product staging needs the MageDrop module 2.0 or later (see Installing the module).

What is captured

MageDrop compares the form you saved with what is live and stages only the fields that differ. Everything else on the form is left alone, so a release that changes a product's name never touches its price, even if someone changes the price in the meantime.

Products

Every attribute, including custom ones, special prices and their dates, and multiselects.
Images and videos: new and removed images, labels, sort order, "Hide from Product Page", and the base, small, thumbnail and swatch roles. The gallery is staged as a whole, so the release holds exactly the gallery you saw when you staged it.
Customizable options and their values, including removed ones.
Tier prices.
Related, up-sell and cross-sell products.
Categories and websites the product is assigned to, with its position in each category.
Configurable products: which child products are linked.

Not staged

Some catalog data is deliberately left out, because changing it on a schedule (or undoing it) isn't safe:

Data	Why
Stock and source quantities	They change with every order. A rollback would put back yesterday's stock levels.
Bundle options, downloadable links and samples	Saved by their own product-type handlers, which can't be safely applied and undone on a schedule.
New products, and new configurable variations from the matrix	A release changes existing content. Create the product (disabled, if it isn't ready), then stage its content and status.
Which attributes a configurable product uses	Changing them can delete the existing variations.
Magento's own scheduled design updates	MageDrop's schedule replaces them for content changes.

When you Save & Stage a form, these sections are simply ignored: they keep their live values and nothing is lost. To change them, use the normal Save.

Editing a child product inside a configurable's variation matrix doesn't stage the child. Open the child product and stage it there.

Store views

Switch the store view at the top of the edit form before you make your changes, just as you would for a normal save. MageDrop stages the change for that store view only, and the dashboard labels it with the store view's name.

Use Default Value. Ticking it stages "use the default" for that field. When deployed, the store view's own value is removed and it falls back to the default scope.
Rollback puts back the exact situation. If a store view used the default before the deploy, rolling back removes the value the release added. If it had its own value, that value comes back.
Global and website attributes (price is usually one) can only change at the scope Magento allows, exactly as in the admin.
Gallery per store view. At a store view, labels, hidden images and role choices are staged for that store view. Removing an image there doesn't remove it from other store views.

One product can have changes for several store views in the same release. Each store view appears as its own card on the release page.

Images

When you upload an image and stage it, the module moves the file to its final place in Magento's media folder straight away, exactly where a normal save would put it. MageDrop only stores the path, so your images never leave your server.

Preview can show the new image immediately, because the file is already in place.
A deploy only has to point the category or product at the file.
Files staged for releases that never go live, and images a deploy removed from a product, are tidied up by a daily cleanup once nothing uses them. You can turn it off or change how long files are kept under StoresConfigurationMageDropMedia Cleanup.

Deploying and rolling back

A deploy saves each category or product once per store view, through Magento's own models, so indexers, URL rewrites and caches update as they would after an admin save. For catalog data in particular:

Positions in a category are restored on rollback, not just the assignment.
Galleries roll back to the images, labels and roles they had at deploy time, including which store views had their own labels.
Configurable products only have their child links changed. Their configurable attributes and options are never touched.
If an entity was deleted in Magento after it was staged, the deploy fails for that entity and nothing in the release goes live. Remove it from the release and deploy again.

See Deploying releases and Rollback for the full process.

Previewing catalog changes

Preview shows staged category and product changes on the category page, in the menu, in listings and on the product page, per store view. A few things come straight from Magento's search index and can't be previewed, such as layered navigation counts. See What gets previewed for the details.

Revisions

Every admin save of a category or product records a revision, so you can see what changed and restore an earlier version from the Revisions tab. Saves made by imports, integrations and scheduled jobs don't create revisions, so your history isn't flooded by stock or price feeds. See Revisions.

Tips

Stage the whole campaign in one release. Category banners, product images and prices go live together and roll back together.
Keep live edits out of staged fields. If someone saves a field directly while it is staged, the deploy overwrites it and the rollback puts back the value from deploy time.
Check the store view on each card before you deploy. A change staged at "All Store Views" won't show on a store view that has its own value for that field.