Modula Defaults - WordPress Plugin

How to Configure Modula Defaults for Repeatable WordPress Galleries

Modula Defaults is built for people who already use Modula Gallery and regularly create similar galleries: a photographer's portfolio, real estate listings, work catalogs, event albums, case study pages, or client-facing image sections. This guide does not repeat a general overview of galleries. Instead, it focuses on the practical use of presets: how to prepare a base gallery, which settings to save, how to apply a default to a new or existing gallery, and how to verify that the outcome does not break your images, lightbox, or responsive grid.

The core idea behind the extension is simple: build a set of settings once, give it a clear name, and then reuse it as a starting configuration. The important distinction is how the feature works: a default carries over settings, but it should not be treated as a copy of a finished gallery with images included. This is especially useful when different pages need to look consistent while the set of photos changes every time.

Below you will find a step-by-step guide to Modula Defaults, including preparation, extension setup, creating your first preset, bulk application, a practical use case, troubleshooting, and alternatives. We will also look at when presets are a better choice than duplicating galleries, and when it is easier to configure one gallery manually instead of cluttering the admin area with extra entries.

What the Extension Actually Solves and Where It Saves Time

Modula Gallery itself handles responsive gallery creation, grid selection, lightbox behavior, captions, hover effects, filters, image sizing, and publishing through a block or shortcode. Modula Defaults adds another layer on top of that: saved setting sets. If your usual workflow means repeating the same sequence every time - choose Custom Grid or Masonry, set spacing, configure the lightbox, turn on captions, check responsiveness, then do it all again for the next gallery - a default turns that sequence into a starting point.

This becomes especially noticeable on sites with more than just a few galleries. A photographer may keep separate galleries for individual shoots, a real estate agency may build one gallery per property, a designer may publish grouped work samples, and a content manager may maintain pages for multiple locations. In that kind of workflow, inconsistent settings quickly become a problem: one gallery opens the lightbox on click, another links to a URL, a third uses different spacing, and a fourth feels too cramped on mobile. Defaults reduces the risk of manual inconsistency because the core settings start to live as named records.

The point of the extension is not to eliminate creative setup. Quite the opposite: a good default still leaves room for specific images, ordering, captions, and local edits, while locking in the repeatable pieces - gallery type, base width, spacing, lightbox behavior, captions, hover effect, loading behavior, responsive settings, and, if the relevant extensions are installed, related options such as protection, EXIF, downloads, zoom, or password protection. The official product page makes it clear that a default carries more than just the layout. It can include a broader configuration set.

When It Helps More Than Manual Setup

The extension makes sense when the same settings really do repeat. If you only have one promo gallery on a landing page, the benefit will be small: you may spend almost as much time designing the default as you would configuring the gallery itself. But if you publish a recurring series of similar content, a default becomes a practical standard. It saves you from trying to remember which values were used in the last successful gallery or opening an older entry in another tab just to copy it.

Another strong use case is managing several types of image-based content. One site might have a default called "Portfolio - large lightbox," another for "Fast grid for news," one for "Property catalog with BnB layout," and one for "Mobile gallery with a compact lightbox." That is better than relying on a single universal template, because different galleries call for different tradeoffs between appearance, speed, and viewing comfort.

Who May Not Need It

Modula Defaults is not useful for everyone. If an editor creates galleries only occasionally, if every gallery is unique in how it works, if the site uses only the built-in WordPress gallery, or if the team is not ready to agree on preset naming rules, the extension may just add unnecessary overhead. It also does not replace work on source images: if the photos are too small, poorly cropped, or badly captioned, a default will not improve the quality of the content.

There is also one more consideration: dependence on the Modula Pro ecosystem. Official materials list Default Settings as a Pro feature. Before you build a workflow around it, make sure the extension is actually available in your installed setup rather than assuming the menu item is already there.

What to Check Before Installation and Before Creating Your First Default

Before installing the extension, do not start by clicking Add New. First, decide which gallery on your site should be treated as the reference gallery and why. If you choose that reference badly, Modula Defaults will simply help weak settings spread faster. Preparation takes less time than cleaning up dozens of galleries later because they use thumbnails that are too small, unnecessary captions, or awkward mobile behavior.

Check three levels: technical, editorial, and user-facing. The technical level covers WordPress compatibility, active Modula or Modula Pro components, extension availability, and the absence of conflicts with optimization tools. The editorial level covers preset naming, rules for different gallery types, and user permissions. The user-facing level is about what a visitor actually sees: how the grid looks, how images open, how captions read, and how easy it is to return to the page.

Technical Foundation

At the WordPress level, first make sure the main Modula plugin is installed and active. On WordPress.org, Modula is described as a responsive gallery plugin with a drag-and-drop grid, a Modula Gallery block, shortcodes, a lightbox, and multiple gallery types. Defaults requires more than the base plugin. You also need access to Pro extensions. The official extension setup guide routes this through Modula - Extensions, where the required module is enabled with a toggle after the Pro component is in place.

If the site is maintained by a client team, check roles in advance. Modula has a separate extension for permissions management that can allow or restrict gallery creation, editing, deletion, and updates. That is not the same feature as Defaults, but for a real editorial workflow it matters who is allowed to change presets. If any editor can modify a shared default without rules, the site will quickly lose visual consistency.

Your Preset Map

Before creating your first default, write down which gallery types actually exist on the site. There is no need to create ten presets "just in case." Start with two or three recurring use cases:

• A work portfolio where large images, clean spacing, and a clear lightbox matter.
• A real estate or interior gallery where room order, fast browsing, and responsive density matter.
• A blog gallery where loading speed and reasonably light thumbnails matter.
• A client gallery where captions, protection, or extra Pro features are needed, if those features are installed.

Each default should have a name that explains its purpose, not just its appearance. Good names: "Portfolio - large lightbox," "Real estate - BnB layout," "Blog gallery - fast thumbnails." Bad names: "Test," "New," "Default 2." A month later, no one will remember how "Default 2" differs from "Default 3."

Review the Source Gallery

If you plan to save settings from an already configured gallery, open it on a public-facing page first. Do not check only the admin screen. Review the actual behavior: how the grid sits inside the theme container, whether the lightbox opens correctly, whether important parts of images get cropped, whether thumbnails are too small, and how the mobile layout behaves. You should save a default only after verifying the visible outcome. Otherwise, it becomes a convenient way to replicate a mistake.

Installing the Extension and Running an Initial Check in WordPress

How you install Modula Defaults depends on how the Pro side of Modula is already set up on your site. This guide does not cover purchasing or obtaining a license. The focus here is configuring a product you already have. The official Pro extensions documentation describes the overall path: Modula Pro must first be installed and active, then you open Modula - Extensions in the admin area and enable the required extension with its toggle. Once it is successfully enabled, the toggle becomes active and the Defaults section appears in the admin menu.

After enabling it, do not rush to create dozens of presets. First, confirm that Modula - Defaults is actually visible to a user with the intended role. If the section does not appear, there are usually three straightforward reasons: the extension is not enabled, the current user lacks the required permissions, or the Pro component is not in the state required for extra modules. Define the problem that way instead of saying "the plugin does not work." That makes troubleshooting much narrower and more useful.

Safe Initial Verification Order

1. Open the WordPress admin area as the user who normally manages galleries.
2. Go to Modula - Extensions and confirm that Defaults is enabled.
3. Open Modula - Defaults and make sure the Add New button is available.
4. Create a test default with a clear name and only minimal setting changes.
5. Open Modula - Galleries - Add New and verify that the new default can be selected when creating a gallery.
6. Do not apply bulk actions to published galleries until the test gallery has been validated on an actual page.

This order may sound cautious, but it protects you from the most frustrating mistake: a team immediately applies a new default to a set of live galleries and only later discovers that it uses the wrong grid type, the wrong thumbnail size, or turns off important lightbox elements. Modula Defaults does include bulk application, so testing on a small sample group is essential.

What Counts as a Successful Installation

A successful installation is more than just seeing a menu item. You need three confirmations: you can create a default, you can select it when creating a new gallery, and you can apply it to selected existing galleries through a bulk action. If all three are available, the extension is ready for use. If the Defaults section exists but the selection does not appear when creating a new gallery, check whether the default itself was saved and whether the user's role has any restrictions.

Practical check: create a temporary gallery with 6-8 images, apply the default to it, insert it on a private test page using the Modula Gallery block or a shortcode, and review it at desktop and mobile widths. Only then should you apply the same approach to production galleries.

How Defaults Stores Settings Without Copying Images

The most important distinction is this: a default is not a duplicated gallery. The official Modula Defaults page explicitly states that applying a default does not touch the images in the gallery. In practical terms, that means you are transferring configuration, not content. If the source gallery contains photos for project "A," saving it as a default does not create a template with those same photos for project "B." It creates a rule set: how the gallery should arrange images, how it should behave on click, which captions it should show, and which extra options should be enabled.

That boundary protects your content. For editors, it is useful because they can build a clean "gallery style" without worrying that old images will accidentally appear in a new gallery. For administrators, it requires discipline: if you need to reuse both the images and the settings, use a gallery duplication feature or another migration approach, not a default. Defaults is for repeatable configuration, not for cloning published content.

Which Settings Make Sense to Include in a Default

Official materials list a broad range of settings that can be carried with a default: layout, columns, spacing, lightbox, captions, hover effects, loading behavior, responsive breakpoints, social sharing, and other Modula settings. In practice, it helps to think in groups of decisions rather than as a raw feature list.

The first group is gallery structure. That includes gallery type, width, spacing, thumbnail size, column count, and mobile behavior. These settings have the biggest impact on how the page looks at first glance and how quickly people can process it. The second group is interaction behavior: lightbox, arrows, loop, keyboard navigation, title and caption display, toolbar, zoom, or download, if those options are available. The third group is editorial detail: titles, captions, hover effects, limits on how many images are shown, and filter rules, if the use case really requires them.

What You Should Not Save Thoughtlessly

Not every setting makes a good shared default. A highly specific hover effect may work well for a designer's portfolio but feel distracting in a real estate catalog. An Images to show limit can be useful on the homepage, but may unexpectedly hide part of the image set in a full case study. A download button in the lightbox may make sense for client delivery, but not for a public portfolio. Only save settings in a default if they truly need to repeat. Leave debatable choices at the individual gallery level.

The same reasoning applies to responsiveness. If Masonry and Custom Grid offer settings for desktop and mobile or tablet columns, enable them deliberately. On a site with heavy visual content, the mobile experience may matter more than desktop: too many columns make thumbnails tiny, too few stretch the page out too much. A good default should define not just "a nice value in the admin UI," but comfortable behavior at real screen widths.

Creating Your First Default: From Reference Gallery to Reusable Set

You can start in one of two similar ways. The first is to create a default in Modula - Defaults through Add New, choose the settings you want, and save them with Save Default. The second is to save settings from a specific gallery through the action panel inside that gallery, if your interface version offers that path. The official product page notes that Save as default and Apply default are available in the Advanced panel inside the gallery, and that the dialog shows which settings will be saved.

For a first setup, it is usually easier to start from a reference gallery. That way you work from a tested outcome rather than abstract values. But before saving it, clear out any accidental decisions: a temporary image limit, an overly experimental hover effect, a disabled lightbox, or a CSS tweak that was only needed on a single page.

Step 1. Prepare the Reference

Create or open a gallery that matches the intended use case. For a portfolio, this might be a Custom Grid with manually emphasized hero images. For a blog, it could be Masonry with moderate spacing and smaller thumbnails. For real estate, it could be BnB or another layout that makes rooms and details easy to review. Different Modula gallery types expose different settings, so the default should be tied to the actual job the gallery needs to do, not to a vague goal like "make it look nice."

Then review the core settings: gallery width, spacing between images, thumbnail size, image count limit, mobile columns, lightbox behavior, captions, and hover effects. If the gallery uses filters, confirm that they are truly part of the repeatable pattern. If filters will be unique in each publication, they should not become a required part of the default.

Step 2. Save the Set Under a Clear Name

Open the default creation screen and give the set a name that immediately answers the question "where should this be used?" The name should make sense even to a new editor. If you have several content categories, add context: "Portfolio - Custom Grid," "Property - BnB with lightbox," "Blog - fast Masonry." In a Russian-language editorial team, Russian names may be fine, but if the interface and the team work in English, keep the names short and English. What matters is using one consistent rule.

After choosing the settings, click Save Default. Then return to Modula - Defaults and confirm that the entry appears in the list. The official documentation notes that defaults in this list can be edited, deleted, or expanded with new entries. That means the set is not permanent forever: you can refine it, but you should treat that as changing a standard, not as a casual edit.

Step 3. Create a New Gallery From the Default

Now test the workflow the extension was meant to support. Open Modula - Galleries - Add New and select the default you created. Add a new image set, save the gallery, and place it on a test page. At this stage, you need to confirm two facts: the settings were actually applied, and the images are still new. If you see the same style but a different set of photos, the mechanism is working correctly.

You should also verify that the gallery can still be adjusted locally after the default is applied. This matters in cases where the default provides the base but the page needs a small deviation: a different title, a different order, a custom caption, or more images visible in the lightbox. If the team becomes afraid to change anything after applying a default, the workflow turns rigid. The right model is this: a default sets the starting point, not a ban on thoughtful editing.

Best Settings for Different Gallery Types

There is no single "best" Modula Defaults configuration. The best default is the one that matches the gallery type, the quality of the source images, the width of the theme container, and the visitor's behavior. That is why it usually makes more sense to create several sets for recurring use cases. Below is a practical decision framework based on Modula documentation for gallery types and settings.

Portfolio and Visual Case Studies

For a portfolio, the first gallery grid usually needs to make an impression. Custom Grid works well if you want to highlight standout images manually and control proportions. Modula documentation describes Custom Grid as a type where you can adjust image sizes inside the container and control height, width, and aspect ratio. A portfolio default should usually be built around a strong visual rhythm: moderate gutter spacing, a sufficiently large thumbnail size, the lightbox enabled, and clean title and caption display if those details help explain the work.

Do not overload this kind of default with lightbox buttons. If the goal is to view the images closely, keep navigation, closing, and perhaps thumbnails or fullscreen, but do not switch on every available button just because it exists. The check is simple: the visitor should be able to open the work, move through a few images, and return to the page without feeling that the interface is getting in the way.

Real Estate, Interiors, and Property Galleries

For listings with a large photo set, order and fast scanning matter most. If you use a BnB-style layout or a similar structure, the default should support the workflow of "see the essentials first, then open the details." At the settings level, check gallery width, lightbox behavior, mobile columns, and captions. In real estate galleries, captions like "Kitchen," "Bedroom," or "Exterior" are often useful, but the caption text itself should not be part of the default because it changes from property to property.

If the gallery is inserted through Elementor on a wide page, check not only the Gallery width value but also the page template. Modula documentation for Elementor shows that full-width output depends not just on the gallery setting, but also on the page or container width. Otherwise, a 100% setting will not force the gallery outside the theme's layout limits.

Blog Galleries and Quick Image Sets

For blog posts, speed and predictability usually matter more. Masonry or Creative Gallery can work well here, but there is little reason to use oversized thumbnails if the page already contains plenty of imagery. Modula's performance documentation recommends reducing gallery image size when a page loads slowly and mentions Medium 300x300 as a practical reference point for lighter thumbnails. That is not a universal rule, but it is a good place to start for a "fast gallery" default.

For this type of default, it is smart to review Images to show in advance. If you limit the number of visible images, make sure the lightbox still shows the rest when needed. The Lightbox & Links documentation connects full lightbox access with the Max Images Count limit. That is useful on pages where you want only 6-10 thumbnails visible on the surface, while still allowing visitors to browse the full set on click.

Client and Protected Galleries

If your setup includes extra Modula extensions, a default can also include settings related to downloads, zoom, EXIF, protection, or comments. This is where you need to be especially careful. A download button may be unnecessary in a public portfolio, but essential for client delivery. EXIF data may be helpful for artistic photography, but excessive in a product catalog. Do not build one default for every protected use case if the underlying needs are different.

Applying a Default in Bulk to Existing Galleries

One of the strongest features in Modula Defaults is that a saved set can be applied not only to a new gallery, but also to multiple galleries that already exist. The official knowledge base describes the workflow through the gallery list: select the needed galleries, open Bulk actions, choose Apply default, click Apply, then choose the default to import and confirm with Import. It is a convenient tool, but also the one that requires the most disciplined review.

Bulk application should be treated as a change to the design and behavior of a group of published items. Even if the images themselves do not change, the visitor may now see a different grid, a different lightbox, a different preview size, or a different mobile layout. So before applying a default to dozens of galleries, choose one test gallery that is similar to the rest in image count and content type. Apply the default there first, review the public-facing page, and only then expand the rollout.

When Bulk Application Makes Sense

The first justified case is when you are changing the site's presentation standard. For example, all portfolio galleries should now use the same lightbox behavior, cleaner spacing, and a unified mobile layout. The second case is cleaning up older galleries whose settings drifted over time because they were configured manually. The third is when a team launches a new content format and wants older material to match the current presentation style.

In each case, it helps to prepare a gallery list in advance. Do not select everything blindly if the site contains different content types. A gallery for a news post, a product page, and a portfolio may look similar in the admin UI while serving completely different needs on the front end. One default may improve consistency and still damage UX where a different format is required.

How to Roll Back If a Default Was Applied to the Wrong Galleries

The official documentation does not promise an automatic rollback history for every bulk application, so treat it like any other visible sitewide setting change: create a backup before a major update, write down which galleries are affected, and preserve the old default if one already exists. If a new set was applied in the wrong place, the simplest rollback is to reapply the previous default or manually restore the key settings on the affected galleries. But that only works if the previous rules are known.

A practical option is to keep a "control" gallery that preserves the current standard. It does not have to be public, but it should reflect the existing working state. Before a bulk replacement, open it and record the key settings: gallery type, gutter, image size, lightbox behavior, responsiveness, and display limits. If something goes wrong after applying the new default, that gallery helps you restore the original values.

Safe rule: always test bulk default application on 1-2 non-public or low-risk galleries first. If the visible outcome matches expectations, move on to the larger group. If not, fix the default itself instead of editing every published gallery one by one.

Practical Use Case: A Unified Portfolio Style for a Photography Studio

Imagine a photography studio website where a separate gallery is created for every shoot. The goal is to publish new sets quickly, keep them visually consistent, and avoid repeating the same manual setup. At the same time, each shoot has its own images, captions, and order. This is an ideal use case for Modula Defaults because the repeatable part is not the content, but the display rules.

Goal

You want a default called "Portfolio - large lightbox" that defines the base gallery type, clean spacing, sufficiently large thumbnails, an enabled lightbox, easy navigation, and a responsive mobile layout. After that, the editor creates a new gallery, selects the default, adds the images for the specific shoot, and publishes it with the Modula Gallery block or a shortcode.

Preparation

Before you configure anything, confirm that Modula and the required Pro extension are active and that the Modula - Defaults section is visible in the admin area. Prepare 8-12 test images with different orientations: landscape, portrait, close-ups, and wider shots. That will show how the grid behaves not in a perfect sample, but in a realistic shoot.

Create a test page that is hidden from casual visitors or not added to the menu. That is where you will validate the outcome. If the site uses Elementor, SiteOrigin, Beaver Builder, or another page builder, test the exact insertion method you plan to use in production. Modula supports blocks, shortcodes, and builder integrations, but the page container still affects how wide the gallery appears and how it looks.

Setup Steps

1. Open Modula - Galleries - Add New and create a test gallery called "Portfolio base."
2. Add your prepared images and arrange them in an order similar to a real publication.
3. Choose the gallery type. Use Custom Grid for manual composition, or Masonry or Creative Gallery for a more automatic image wall.
4. Set spacing, width, image size, and mobile responsiveness. For Custom Grid, make sure images do not become too small after manual resizing.
5. Open Lightbox & Links settings and enable only the elements you actually need: lightbox opening, arrows, loop, captions, keyboard support, or the toolbar if it improves viewing.
6. Save the gallery and place it on the test page through the Modula Gallery block or a shortcode.
7. Review the public-facing result, then save the settings as a default with a clear name.
8. Create a new gallery called "Client shoot test," select the default you just created, and add a different image set.

Validating the Outcome

The result is successful if the new gallery inherits the grid, spacing, lightbox, and mobile behavior while still containing its own images. Check three layouts: a wide page, a tablet width, and a mobile width. On mobile, pay attention to double tap if it is enabled for hover or lightbox behavior, and make sure the gallery is not trying to show too many columns.

Then open the lightbox. Confirm that arrows work, captions appear only where they are needed, the toolbar does not cover important parts of the image, and closing the lightbox returns the visitor to the same page. If a visible image limit is enabled, confirm that the remaining images still appear in the lightbox if that is the behavior you intended.

A Commonly Missed Pitfall

Do not mix a portfolio default with a fast blog-gallery default. In a portfolio, large thumbnails and a strong lightbox are justified. In a blog, those same settings may make the page heavier and much longer. If the editor has to shrink images or disable unnecessary buttons after every default application, the wrong preset is being used for the use case. Create a separate set instead of relying on constant manual correction.

How to Verify the Outcome After Applying Settings

Validation after using Modula Defaults should answer not "did something save in the admin UI?" but "did the visitor get the expected gallery?" To do that, you need a short but reliable checklist. It should be used after creating a new default, after editing an existing default, and after a bulk application.

Admin Area

In the admin area, confirm that the default appears in Modula - Defaults, opens for editing, and has a clear name. Then open a gallery where it was applied and check the main tabs. You do not need to compare every single field, but you do need to confirm that the expected groups changed: gallery type, general settings, lightbox, responsive options, and any extra tabs included in the workflow.

If the default was applied in bulk, open several galleries from different sections of the site. Sometimes one gallery with only a few images looks fine, while another with a larger image set immediately reveals the problem: spacing is too tight, thumbnails are the wrong size, or the lightbox is overloaded.

Public-Facing Page

On the public page, review loading, the grid, and interaction behavior. The grid should fit inside the theme container, avoid horizontal scrolling, and not leave strange empty gaps. The lightbox should open on click, show the correct controls, and close without reloading the page. If the gallery was inserted through the block editor, make sure the selected gallery is still connected after the page is updated.

Check the mobile version separately. Modula documentation for desktop and mobile or tablet columns notes that custom responsiveness applies to specific gallery types, including Custom Grid and Masonry. If you expected a different column count on mobile but it did not change, check the gallery type and whether Custom Responsiveness is enabled.

Image Quality and Performance

If the page becomes heavier after applying a default, check thumbnail size and image count. The official performance documentation recommends reducing Gallery Images Size for a specific gallery if the page loads too slowly. But do not do that mechanically in every case: setting the size too low can reduce sharpness, especially in Creative Gallery. Modula's blurry images documentation for Creative Gallery specifically warns that a minimum size that is too low can lead to soft-looking images.

The practical check is simple: on desktop, thumbnails should look sharp enough at the actual container width; on mobile, they should not break the grid; and the lightbox should open without a noticeable delay. If you have to choose between very large thumbnails and speed, create two defaults: one for visually important pages and one for lightweight blog inserts.

Where Defaults Works Better Than Gallery Duplication, and Where the Opposite Is True

Modula can duplicate galleries, while Defaults creates reusable setting sets. These tools only look similar on the surface because both keep you from starting from zero. Their jobs are different. Duplication is useful when you need to repeat the structure of a specific gallery together with a large number of local choices. A default is useful when you need to repeat display rules but load new content.

If you create a series of almost identical property pages where only the photos change, a default is usually the cleaner approach. It does not carry over unnecessary images or force the editor to clear old content first. But if you are creating a variation of the same gallery for A/B testing or making a copy of an existing case with the same images, duplication may be faster. The key is not to use duplication as a substitute for a standard when the team is creating dozens of new galleries.

Signs That You Need a Default

• The team repeats the same settings regularly, but the images are different every time.
• You need to maintain several presentation standards for different gallery types.
• There is a risk that editors will forget to enable the lightbox, responsiveness, or the correct thumbnail size.
• You need to bring existing galleries in line with a new rule through bulk updates.

Signs That Gallery Duplication Is Simpler

• You need to preserve not only the settings, but the same image set as well.
• You are creating a one-off variation of an existing gallery.
• The settings are too specific to one page and will not become a repeatable standard.
• The team does not plan to maintain a list of named presets.

A practical rule of thumb: if the first thing you do after copying a gallery is delete all the images, you probably needed a default. If the first thing you do after applying a default is manually add the same images back in, the task is probably closer to duplication.

Compatibility with Themes, Cache Layers, and Page Builders

Modula Defaults inherits the usual working conditions of Modula Gallery. If a theme, page builder, optimizer, or cache plugin already affects your galleries, a default will not remove that influence by itself. It simply applies the chosen settings more quickly to new or existing galleries. That is why compatibility should be treated as part of the rollout, not as some rare edge case.

Container Width and Page Builders

If a gallery needs to be full width, check more than the Gallery width value. You also need to check the page container. Documentation for Elementor and Modula shows the full chain: create the gallery, set Gallery width to 100%, then use a suitable page template in Elementor and insert the Modula widget. If the theme or page template keeps content inside a narrow container, the gallery setting cannot magically push it beyond those limits.

On sites using the block editor, the principle is similar: the selected block and the width of its group or column affect the final output. So a "full width" default should be tested on a real page, not only inside the gallery admin screen. If the same gallery looks different in a post, a page, and a builder template, the cause is often the output container, not Defaults itself.

Cache and JavaScript Optimization

The official Modula knowledge base describes two practical conflicts with optimization tools. For WP Rocket, if image display breaks, the recommendation is to exclude Modula images from lazyload using the selector .modula-gallery .modula-items .modula-item img. For Autoptimize, the documentation notes that minifying Modula files can interfere with correct rendering and suggests excluding the path wp-content/plugins/modula-best-grid-gallery/. You do not need to enable these changes on every site in advance, but they are useful diagnostic paths if galleries start behaving strangely after a default is applied.

A safe workflow looks like this: clear the cache first and check the page in a private window. If the problem disappears, you may be dealing with stale cache rather than the default itself. If it does not disappear, temporarily disable the questionable optimization only for testing. Do not disable all caching permanently unless you understand the cause. With WP Rocket and Autoptimize, it is usually better to add a targeted exclusion if that confirms the fix.

A Careful CSS Tweak for a Small Local Design Touch

If the built-in settings get you almost all the way there, but a specific gallery needs a small design adjustment, use safe CSS at the gallery level or through Appearance - Customize - Additional CSS, as recommended in Modula's custom CSS documentation. Do not edit plugin files or add heavy JavaScript just for a minor cosmetic touch. The example below slightly softens thumbnail corners and adds a smooth opacity transition. Use it only after confirming that the selector matches your Modula markup.

.modula-gallery .modula-items .modula-item img {
  border-radius: 6px;
  transition: opacity 180ms ease;
}

.modula-gallery .modula-items .modula-item:hover img {
  opacity: 0.92;
}

The check is simple: refresh the page, clear the cache, hover over the images, and confirm that the effect does not conflict with Modula's built-in hover effects. If the native hover effect already uses a more complex animation, this CSS may be unnecessary. To roll it back, remove the snippet from Custom CSS or Additional CSS and clear the cache again.

How to Manage Multiple Defaults Without Creating Editorial Chaos

The more useful Modula Defaults becomes, the greater the risk of creating too many similar sets. At first this seems harmless: one editor saves "Portfolio," another adds "Portfolio new," a third creates "Portfolio mobile," and within a couple of weeks the list contains five entries with nearly identical purposes. Technically, the extension still works, but the team stops understanding which default is actually the working standard. That is why preset management is not bureaucracy. It is part of publication quality.

A good system starts with short rules. Every default should have a purpose, an owner, and an expected outcome. The purpose answers where the set should be used. The owner is responsible for changes, because a default may affect many galleries. The expected outcome should describe not every field, but the visible behavior: for example, "large portfolio with lightbox and two mobile columns" or "fast blog gallery with moderate preview size." Without that description, editors will choose a set by guesswork.

Naming That Still Makes Sense a Month Later

The Modula Defaults interface can hold several entries, each with its own name. Use that as team navigation. The name should include the content type and the main presentation principle. For a Russian-language editorial team, names like "Portfolio - large lightbox," "Blog - fast grid," or "Property - BnB browsing" may be fine. If the team is used to an English WordPress interface, you can keep a mixed working style, but do not translate half the names randomly. The main criterion is simple: any editor should be able to pick the right default without asking for a separate explanation in chat.

Do not put a date, employee name, or temporary wording into the name of a working set. "Portfolio Ivan test" may be useful during an experiment, but it should not remain the standard. For tests, use an explicit "Test" prefix and remove those entries after validation. If you need to compare two temporary variants, name them by meaning: "Portfolio - large thumbnails" and "Portfolio - compact thumbnails." That way even a test pair still helps the team make a decision.

A Defaults Map for Different Page Types

For a small site, two or three sets are usually enough. One can be the primary default for important visual pages. A second can be a lightweight default for blog posts or news entries. A third can be a special default for client or protected galleries if the site uses that workflow. You only need more sets if each one supports its own recurring use case. If the difference comes down to a single field, it may be better to apply the base default and adjust the specific gallery manually.

It is also useful to maintain a small internal table outside Modula: default name, where to use it, what to check after applying it, and who is responsible for changes. This can be a page in your editorial knowledge base or a project note. It does not need to become a huge policy document. It only needs to be clear enough that a new editor understands why "Portfolio - large lightbox" should not be used for a blog, and why "Blog - fast grid" does not belong on a photographer's homepage.

Access Rights and Responsibility

If several editors work on the team, not all of them should be editing production defaults. Official Modula Roles documentation describes granular control over gallery actions: creation, publishing, editing one's own or others' galleries, deletion, private gallery access, and file uploads. Even if you do not use a separate roles extension, the principle stays the same: the person changing the standard should understand the consequences for published pages.

A practical model is this: editors create galleries and apply ready-made defaults, while an administrator or designated content manager changes the defaults themselves. If an editor finds a problem, they should not immediately change the shared default. They should create a test gallery, describe the symptom, and propose the change. That lowers the risk of fixing one page while accidentally changing the workflow for every future publication.

For client sites, add one more rule: do not name defaults with inside jokes or temporary technical phrases. The client may see the list in the admin area, and the names should look professional. "Client proofing - clean captions" is more useful than "Do not touch v3 final." A clear name reduces support overhead and lowers the chance of mistakes during handoff.

How to Update a Default Without Breaking Published Galleries

A saved default may feel stable, but websites change. Themes change, container widths change, image sets change, performance needs change, lightbox behavior changes, and caption style can change too. Sometimes a default needs to be updated so that new galleries immediately receive the current settings. The important distinction is that editing a default is not the same as applying it in bulk. Updating the default record affects future selection and future manual application, but already published galleries should not be treated as automatically updated until you apply the set to them yourself.

Before making a change, ask one question: are you fixing an error in the current standard, or creating a new standard? If you are fixing a mistake, such as thumbnails that are too small in the portfolio default, then updating the existing set after testing may be appropriate. If you are introducing a new visual approach, it is usually better to create a new default and keep the old one for a while. That allows the team to publish new galleries under the new standard while migrating older ones gradually.

A Control Gallery as the Source of Truth

For every important default, it helps to keep a control gallery. This is just a regular Modula gallery that shows what the default is supposed to look like in practice. It can be published on a private internal page or be visible only to administrators. What matters is that it contains a typical image set and is inserted using the same method you actually use for production galleries: block, shortcode, or page builder.

When a default needs to be updated, edit the control gallery first. Check it on the internal public-facing page, test the lightbox, mobile width, speed, and sharpness. If the outcome works, save those settings into the default or create a new default based on them. The process may feel longer, but it protects you from making a blind change in a settings form that unexpectedly breaks the composition on the front end.

Versioning Without Dates in the Name, but With a Clear State

The article itself does not need years or dates, but inside a working admin area it is often useful to distinguish between an old and a new standard. You do not have to add dates to the default name. It is usually better to reflect the state instead: "Portfolio - classic grid" and "Portfolio - wide lightbox," "Blog - compact" and "Blog - editorial." Names like that describe the difference instead of the moment they were created. If the validation date matters for the internal team, record it in an internal note rather than in a name every editor will see.

If the old default is no longer needed, do not delete it immediately after creating the new one. First confirm that new galleries are being created correctly and that older critical pages do not still depend on the previous set. After a validation period, the old default can be deleted or renamed with an "Archive" prefix if the team needs to keep it for occasional edits. The key is not to leave archived sets sitting next to active ones without explanation.

Step-by-Step Update Order

1. Open the control gallery for the relevant use case and make the change in its settings.
2. Review the outcome on the internal page at desktop and mobile widths.
3. Check the lightbox, captions, hover effect, visible image limit, and loading speed.
4. If the change fixes the current standard, update the existing default or save the set again.
5. If this is a new approach, create a separate default with a new, clear name.
6. Create a new test gallery from the updated default and confirm that the settings apply as expected.
7. Only after that should you apply the default to selected published galleries through a bulk action.

After the update, do not rely on visual memory. Open one new gallery, one old gallery that has not had the default reapplied, and one gallery that received the default through bulk application. That gives you three distinct states: the future standard, the old published state, and the updated group. If those states blur together in your mind, it becomes easy to assume everything has already been updated when some pages are still using the old settings.

When It Is Better Not to Update a Shared Default

Do not change a shared default because of one problematic gallery. For example, if only one page needs less spacing because of a narrow theme container, fix that gallery locally. If only one project needs captions hidden, do not turn off captions in the main portfolio default. If one client wants a download button while the rest do not, create a separate client default or configure that gallery directly.

A shared default is worth updating when the issue repeats or when the site standard itself has changed. It is similar to updating a design system: one button style may be an exception, but if the entire typography or the lightbox behavior for portfolio galleries changes, then a new standard is needed. A good default does not need to cover every exception. It should make the typical workflow fast and predictable.

How to Train an Editor to Use Defaults Without Mistakes

Modula Defaults is often introduced by administrators, but then used day to day by editors. If an editor does not understand the line between a default and a gallery, they will either become afraid to change local settings or start creating a new default for every publication. That is why a short training pass is more useful than a long policy document. It is enough to explain three things: a default sets the starting configuration, images are added separately, and bulk application changes selected existing galleries.

Start training with a real task. Let the editor create a new gallery for a blog post, choose the correct default, add images, save the gallery, place it on a test page, and check the outcome. Then show a second workflow: a portfolio using a different default. Once the person sees that two presets produce different behavior, the urge to pick the first available option usually disappears.

A Mini Guide for Editors

Inside the team, you can use a short internal checklist. It should read like a working procedure, not like technical documentation:

1. Before creating a gallery, choose the page type: portfolio, blog, property, or client gallery.
2. In Modula - Galleries - Add New, choose the default that matches that page type.
3. Add the images for the current publication and check their order.
4. Save the gallery and insert it through the Modula Gallery block or shortcode.
5. Open the page as a visitor and check the grid, lightbox, and mobile view.
6. If something only needs to change on this page, adjust the gallery locally instead of creating a new default.
7. If the same issue repeats across multiple galleries, pass it to the person responsible for defaults.

This kind of checklist keeps people from being overloaded by every Modula setting. An editor does not need to remember every field in Lightbox & Links or Responsive if the standard is already configured. They only need to choose the right use case, add the content, and validate the outcome.

How to Tell a Local Edit From a Standard Change

A local edit is appropriate when the difference belongs to a specific publication. For example, one gallery has fewer photos, so the previews can be larger. Or one property has an unusual room order, so the editor changes the image sequence. Or one case study only needs captions for part of the photos. None of those changes requires a new default.

A standard change is needed when the same friction point keeps repeating. For example, all new portfolio galleries feel too dense on mobile. Or all blog galleries show unnecessary lightbox buttons. Or several galleries look blurry because the image size is too low. In that situation, it is better to return to the control gallery, fix the default, and then apply it to the appropriate group.

The main point for editors: a default is the team's starting agreement, not a ban on sensible local adjustments. But the default itself should only be changed when the repeatable rule changes.

When Modula Defaults Is Worth Using

Modula Defaults is a strong fit for sites where galleries are created regularly and need to preserve a consistent style. The extension is especially useful for portfolios, agencies, photographers, property catalogs, visual case studies, and editorial teams where multiple users work in one publishing system. It helps reduce repeated manual setup, preserve important lightbox and responsive settings, create new galleries faster, and update existing ones in a controlled way.

Before rolling it out, answer three questions honestly. Do you have recurring gallery types? Does the team understand which settings should be standard? Are you prepared to validate the outcome on a public-facing page before using bulk application? If the answer is yes, the extension can deliver real practical value. If galleries are rare and unique every time, manual configuration or duplicating specific galleries may be enough.

For a safe start, create one default for your most common use case, test it on a new gallery, then validate one existing gallery through bulk application. After that, you can expand the system: add one separate set for fast blog galleries, one for portfolios, and one for client galleries. When you are ready to try the extension on your site, you can download the ZIP archive and follow the setup steps from this guide.

The main success criterion is simple: the editor creates a new gallery faster, the visitor gets a predictable and easy-to-use interface, and the administrator understands what each default is responsible for. If that chain works, Modula Defaults is doing its job.