YOO Widgetkit 3 Pro - Joomla Extension

Guide to Configuring and Using YOO Widgetkit 3 Pro in Joomla

YOO Widgetkit 3 Pro is best understood not as a single standalone widget, but as a set of ready-made blocks for Joomla: galleries, sliders, grids, accordions, maps, article lists, and other elements you can assemble in the admin panel and display on a page. In this guide, we'll take a practical approach to the product: what to check before installation, where to find the settings, how to create your first widget, how to place it in an article or module, how to verify the result, and what to do if the block does not appear or breaks the layout.

This article does not repeat the short product description. What matters here is understanding the working logic: Widgetkit stores data sets, turns them into the selected widget type, and outputs a finished block to the site frontend. If you do not break down that chain, it is easy to run into common situations: the widget is created but does not display; the image is uploaded but looks poor; the module is enabled but hidden by menu assignment; the slider works in the admin panel but conflicts with JavaScript optimization on the site.

This guide is written for a Joomla site owner, webmaster, or content manager who needs to build visual blocks quickly without developing a separate component. Developers can also use it as a checklist: which settings should not be changed blindly, which checks to run after publishing, and which changes are better handled through the template or custom CSS rather than by editing the extension files.

From this point on, we will be careful about exact versions and licensing because those details can change. The facts about features, installation, interface, content providers, and limitations are based on official YOOtheme pages and documentation, while debatable points and common symptoms are moved into the notes and troubleshooting section.

How Widgetkit Works Inside a Joomla Site

The core idea behind the extension is simple: you create an item in Components » Widgetkit, choose a widget type, fill it with data, and then insert it into the site using one of the available methods. In Joomla, three layers matter most: the Widgetkit component itself, the Joomla module, and the output location in an article or site layout. If one layer is configured incorrectly, the widget may be fine, but users still will not see it.

The official documentation shows that Widgetkit works through a widget manager where you can create, edit, copy, and delete blocks. After creation, the widget gets a shortcode you can insert into an article, or you can select the widget in a module and assign that module to a template position. For sites using YOOtheme Pro, there is another convenient option: the shortcode can be added to a text element in the builder. On a standard Joomla site, the most common output methods are an article, a custom HTML module, or the standard Widgetkit module.

Practical takeaway: before you start configuring anything, it helps to decide not only "which block do I need," but also "where will it live." A gallery inside an article, a homepage slideshow, tabs on a service page, and a map on the contact page all require different output locations, different image sizes, and different post-publishing checks.

What the Working Chain Looks Like

Widgetkit does not replace Joomla's entire article system. It adds a widget layer on top of it. In a typical workflow, the chain looks like this:

1. The administrator creates a widget in the Widgetkit component.
2. Inside the widget, a type is selected: for example, gallery, slideshow, grid, accordion, map, or another available option.
3. The widget receives data either manually or through a supported content source.
4. Fields, order, images, display settings, and service parameters are configured.
5. The finished block is output through a shortcode, a Joomla module, or a compatible builder element.
6. The result is checked on the page, at mobile width, with cache enabled, and as a regular user without administrator permissions.

The most common mistake at this stage is starting with the visual appearance before preparing the data structure. For a gallery, it is important to decide in advance which images will be used and what size they should be. For an article list, you need to decide where the title, link, image, and description come from. For an accordion or tab-based layout, you need short, clearly separated text blocks. Otherwise, Widgetkit stops being a time-saver and becomes the place where content has to be rebuilt after publication.

It helps to think of a widget as a small content contract. That contract answers four questions: what data goes into the block, which widget type displays it, where the block appears on the site, and how the editor will know the result is correct. If even one of those questions is left unresolved, configuration turns into guesswork. For example, a gallery may be configured perfectly, but if the images use different aspect ratios and there is no consistent cropping rule, the final grid will look random. Or a module may be published but still invisible because of menu assignment, even though Widgetkit itself is working normally.

Which Widget Types Actually Change the Workflow

The official product page lists a range of widgets: Accordion, Grid, Slideshow, Slider, Slideset, Gallery, Map, Grid Stack, List, Switcher, Media Player, Parallax, Popover, and other options. You do not need to use all of them. In most Joomla projects, these blocks fall into a few practical groups:

• Visual blocks - gallery, slideshow, slider, and slideset help showcase portfolios, projects, photos, testimonials, or promotional content.
• Navigation and structural blocks - accordion, switcher, tab-like layouts, and grid make it easier to present long information in a compact form.
• Content lists - list, grid, and grid stack help display a set of articles when you want cards rather than Joomla's standard list output.
• Special-purpose elements - map, media player, parallax, and popover are used less often, but they require more careful testing on mobile devices and on cached pages.

If the task is simple, do not choose the flashiest widget just for the visual effect. For example, an accordion is often a better fit for frequently asked questions than a complex slider. For a portfolio with several categories, a gallery or grid will usually be clearer than a slideshow where the user sees only one item at a time. For contacts, a map makes sense if it genuinely helps users find the location, not if it simply takes up space.

When the Extension Fits the Site and When It Only Adds Complexity

YOO Widgetkit 3 Pro is a good fit for sites where the editor regularly needs repeatable visual blocks. That could be a studio portfolio, a project showcase, a service page, a before-and-after block, a list of benefits, a set of testimonials, a branch location map, or a compact accordion-style knowledge block. The value appears where the same type of block needs to be updated without involving a developer.

The extension may be unnecessary for a site that needs only one static block with two images. In that case, it is often easier to build the markup directly in the template or page builder. Widgetkit also should not be treated as a replacement for a full catalog, online store, CRM, or advanced filtering system. It helps present and output content, but it does not turn Joomla into a separate business platform.

Who Usually Finds Widgetkit Convenient

The ideal use case is a site where content is updated not by a developer, but by an editor or site owner. What matters is having a clear place to manage blocks without having to edit HTML every time. That is exactly the need Widgetkit addresses: create a block, fill in the items, choose the styling, and insert it where it belongs.

• For an agency, it is convenient to prepare a set of standard blocks for the client and leave behind a clear update workflow.
• For a content manager, it is convenient to change images, headings, and item order without touching template files.
• For a webmaster, it is convenient to assemble a page quickly from several ready-made blocks and check how they behave across devices.
• For a developer, it is convenient to use Widgetkit as a visual output layer when there is no need to build a separate component.

When Another Tool Is the Better Choice

If the site is built entirely with YOOtheme Pro and all blocks are already easy to assemble in the builder, Widgetkit may be needed only for specific output types. If the project requires complex filtering logic, personalization, integration with external APIs, or advanced database handling, it is better to look at a specialized component. If minimal overhead matters and the page only needs one simple list, it may be more sensible to stick with a standard Joomla module.

A good rule of thumb: use Widgetkit where it gives the editor a clear, repeatable block. Do not use it just for animation if the same task can be handled faster and more cleanly with a normal template section.

What to Check Before Installation and First Launch

Pre-installation preparation is not just a formality. Widgetkit works with images, JavaScript, editors, Joomla's module system, and third-party content sources. If you do not check the environment in advance, it becomes much harder later to tell whether the issue comes from the widget itself, the template, cache, folder permissions, or the article editor.

Environment Compatibility and Basic Dependencies

YOOtheme documentation states that Widgetkit requires PHP with GD extension support. That matters because GD is used for image processing. If GD is disabled on the server, the problem may not appear as an obvious installation error. Instead, you may see broken thumbnail generation or missing images in the finished block. Before you start working, check PHP status in your hosting panel or through Joomla system information.

Another required checkpoint is write permissions. The documentation on file permission issues explains that incorrect file and folder permissions can prevent Widgetkit from creating the files it needs. In practice, this is especially common after a site migration, a backup restore, or a manual FTP upload. If the extension installs but images, thumbnails, or service files behave oddly, permissions should be one of the first items in your troubleshooting process.

Template, Cache, and JavaScript Optimization

Widgetkit uses its own styles and scripts. Because of that, before publishing on a live site, it is important to understand which optimizers are already enabled: JavaScript merging, deferred script loading, CSS minification, Joomla cache, template cache, a third-party caching plugin, or a CDN. These tools are useful, but they can sometimes change the file load order, which causes sliders, maps, or interactive blocks to stop working.

Do not disable optimization permanently at the first sign of trouble. A better approach is to run a controlled check: temporarily disable the questionable setting, clear the cache, reload the page while logged out, and see whether the symptom disappears. If it does, the next step is not to abandon optimization entirely, but to configure an exclusion for the specific script or mode. Those exclusions depend on your template and caching extensions, so any universal code example here would be unreliable.

Content Plan Before Installation

Before installing, it is helpful to sketch out one working scenario that you will use for the first test. Do not start with ten widgets at once. Pick one: for example, a gallery with 8 to 12 images, a homepage slideshow, or an accordion for a service page. Prepare properly sized images, short headings, descriptions, and a link to the page where the block will be displayed.

The minimum setup for the first check looks like this:

• One widget type the site actually needs.
• A folder with prepared images and no random oversized files.
• A Joomla article or module position where the result will be displayed.
• Access to cache clearing and the ability to temporarily disable script optimization.
• A clear understanding of which users should see the block: all visitors, only a specific section, or only selected menu items.

This stage may seem boring, but it saves time. If the first widget has been tested on a simple page, it becomes much easier to add advanced settings, content sources, and different output methods later.

Installing, Enabling, and Verifying the Component

Installing Widgetkit in Joomla works like installing any standard extension through the Extension Manager. The exact interface depends on your Joomla version and administrator permissions, but the logic is standard: upload the installation archive, wait for the installation to finish, open the component, and make sure it is available in the menu. You do not need to connect to the database or edit files manually.

A Safe Installation Order

Before installing on a live site, create a backup. That is not because Widgetkit is inherently dangerous, but because any Joomla extension changes the file set and may interact with the template, cache, and editor. If the site is commercial or actively visited, it is better to test the extension on a copy of the site first.

1. Create a backup of the files and database.
2. Make sure the administrator user has permission to install extensions.
3. Open Joomla's Extension Manager and upload the installation ZIP archive.
4. After installation, go to Components » Widgetkit.
5. Create a test widget with one or two items.
6. Insert it on a test page using a shortcode or module.
7. Clear the cache and open the page as a regular visitor.

If the component does not appear in the menu, first check whether the installation completed successfully and whether the administrator has the required permissions. If the component opens but the widget does not display, do not reinstall the extension right away. First make sure the shortcode was inserted without extra characters, the module is published, assigned to the correct menu item, and not hidden by access settings.

The First Test Widget

For the initial check, it is better to choose a simple scenario rather than the most complex one. Pick a widget that quickly shows whether the connection between the component and the site is working. A basic gallery or list is a good choice. Add two items, save the widget, and display it on a test page. At this stage, there is no need to configure every animation, effect, content provider, or advanced field. The goal is simply to confirm that Widgetkit can create a block and Joomla can display it.

After saving, check three things: whether the HTML block appears on the page, whether the styles and scripts are loading, and whether the images display correctly. If one of those pieces is broken, further visual customization will not help. The base output issue needs to be fixed first.

How to Tell the Installation Went Smoothly

A successful installation is more than just a Joomla message after the archive upload. A working result should be confirmed in several places:

• The component is available under the Components menu.
• The Widgetkit manager opens without errors and lets you create a new widget.
• The test widget saves successfully and receives an output method.
• The page with the widget opens without browser console errors that break interactivity.
• Images and styles load correctly on the site frontend.

If all of these checks pass, you can move on to configuring a real block. If not, stop at the first point where the chain breaks. That is much easier than changing several settings at once and then guessing which one fixed the issue.

Widget Manager, Content Sources, and Fields

What makes Widgetkit distinct begins in the widget manager. This is not just a list of blocks. It is where you decide what data goes into the widget, how that data is interpreted, and how it becomes the final result on the page. The official documentation describes different widget types and the content provider mechanism: data can be entered manually or pulled from supported sources, and then mapped to headings, images, links, and other content.

Manual Content and Content Providers

For small blocks, manual entry is usually faster. For example, if you are building a slideshow with five promo slides, it is often easier to add the items manually than to build a separate data source. Manual mode gives you direct control over headings, images, and order.

Content providers are useful when the widget should update itself based on existing content. YOOtheme documentation describes integration with ZOO, where app items can be displayed through Widgetkit and ZOO fields can be mapped to widget fields. For sites that use ZOO as a catalog or content database, this is a strong use case: the content lives in one place, and Widgetkit handles the visual presentation.

Do not connect a content source just for the sake of "automation." If it is easier for the editor to update five cards manually, a manual widget will be more transparent and more reliable. A content provider makes sense when the data already lives in a separate system and needs to be reused.

Field Mapping Without Guesswork

Inside a widget, field mapping matters: which element becomes the heading, which becomes the image, which becomes the link, and which becomes the description. Mistakes here often look like "the widget works, but it displays the wrong thing." For example, a blank area appears instead of an image, the cards link to the wrong pages, or the description turns into an overly long text block.

For each field, use a simple check:

• The heading should be short and should not break the card grid.
• The image should be prepared in advance and should make sense as alt content on the page if it is used in visible content.
• The link should take the user to the next step in the journey, not just back to the homepage.
• The description should be shorter than a regular article paragraph, otherwise the cards will end up with uneven heights and be harder to scan.
• Tags or categories should match the filtering logic if the selected widget uses filtering.

Do not rely only on the visual preview in the settings. Save the widget, output it in the real location, and see how the fields behave in the context of the page: next to the menu, breadcrumbs, nearby modules, and the footer.

Copying Widgets and Keeping the Library Organized

The Widgetkit manager documentation shows that widgets can be copied. This is a convenient way to create a second similar block, but it carries some risk: you can easily forget to change the data source, heading, or output location. If you copy a widget, rename it immediately based on its actual purpose: for example, "Gallery - Projects," "Accordion - Service FAQ," or "Slideshow - Home hero." Clear names matter more than a clever internal system, because several months later they are what will help you find the right block.

For a larger site, establish a simple naming rule. You can start with the page type or section, then add the widget type and purpose. This does not affect the site frontend, but it reduces the risk of editing the wrong block.

How to Use ZOO Integration Without Confusion

The official documentation describes Widgetkit integration with ZOO and field mapping. This is useful if ZOO is already being used on the site as a catalog, project database, or structured directory. In that scenario, Widgetkit should not become a second place to store the same data. The right logic is this: ZOO stores the items and their fields, while Widgetkit selects the required set and presents it as a gallery, grid, or another visual block.

Before enabling that workflow, make sure the ZOO fields already contain data suitable for visual output. The heading should be short, the image should not be just a technical thumbnail, the link should lead to the correct page, and the description should not turn into an oversized card excerpt. If the fields are filled inconsistently, Widgetkit will faithfully display that inconsistency. So first clean up the source data, and only then configure the visual output.

The safest way to test a ZOO-based scenario is to display 3 or 4 items on a hidden test page and compare them with the original cards. If the widget shows exactly the headings, images, and links you expected, you can expand the selection. If not, fix the field mapping rather than the block styling.

Configuring Galleries, Sliders, and Interactive Blocks

The configuration stage should start not with effects, but with structure. Most widgets have three layers: data, presentation, and behavior. Data determines what is being displayed. Presentation defines the grid, card layout, images, and captions. Behavior includes animation, switching, autoplay, maps, popovers, or other interactive features. If you mix up that order, you can end up with a block that looks nice but is frustrating to use.

The First Settings Worth Checking

After creating a real widget, walk through the key settings. The section labels are not always identical across every widget type, but the logic stays the same: source, items, visual appearance, behavior, and service parameters.

The table is not a substitute for testing. After configuration, always open the page where the widget will actually be used. The admin panel does not always reflect the real environment: container width, template styles, neighboring modules, and optimization scripts.

Gallery and Images

A gallery requires careful media preparation. The official Widgetkit page emphasizes image handling and fast output, but real performance still depends on the source files, the template, and the site settings. If you upload oversized images, the widget may look fine on a fast connection while still slowing down the page for a typical visitor.

For your first gallery, use images with the same aspect ratio. That gives you a more stable grid. If the images vary, decide in advance what matters more: preserving the full frame or getting a clean, even card layout. In the first case, expect uneven heights. In the second, expect cropping. Check not only the desktop width, but also a narrow screen, because long captions and mismatched proportions usually break there first.

Gallery Check After Saving

• All images open without 404 errors.
• The cards do not overlap after the cache is cleared.
• Captions do not take up more space than the image itself.
• Links point to the expected pages or items.
• At mobile width, users can understand the item order without horizontal scrolling.

Sliders and Slideshows

Sliders and slideshows work well when you need to show several equally important visual elements in a limited space. But they are a weaker choice for information the user needs to read in full. If a slide contains a long text block, visitors may not finish reading it before the frame changes, or they may not even notice the next slide.

When configuring a slideshow, check two things: whether the meaning of the first slide is clear without waiting, and whether the user can control the switching manually. If the slider is used on the homepage, the first frame should explain where the visitor has landed. If it is a project gallery, the user should be able to pause and take a closer look.

Accordion, Switcher, and Compact Knowledge Blocks

Accordion and switcher widgets work well on long service pages, FAQ sections, technical specifications, and comparisons. But they have a limitation: hidden content is harder to scan. So do not hide critical terms, pricing, warnings, or the main call to action inside an accordion. Those should stay visible in the main text, while the accordion is better reserved for supporting detail.

If an accordion is being used as an FAQ, make sure the question headings are specific enough. A weak heading like "Learn more" explains nothing. A strong heading tells the reader what is inside: "Why the gallery is not visible after clearing the cache" or "How to replace an image without changing the card order."

Output Methods: Shortcode, Joomla Module, and Template Page

Once the widget is ready, it needs to be displayed on the site. In Joomla, this is a separate and important stage because simply creating a widget does not mean it is published. The widget may exist in the component but never appear on the page until you insert the shortcode, assign a module, or add the block to a compatible layout.

Shortcode in an Article

A shortcode is a good fit when the widget should be part of a specific Joomla article: for example, a gallery inside a project page, an accordion in a how-to article, or a slideshow in a service description. Insert the shortcode exactly where the block should appear, and check that the editor has not altered the braces, spaces, or service characters.

The troubleshooting documentation specifically mentions issues with visual editors that can break special tags or code. If the widget does not display after being inserted into an article, check the editor's source mode and the saved HTML. In some cases, the editor automatically changes the markup and the shortcode is no longer recognized.

Joomla Module

A module is convenient for repeatable placement: the homepage, sidebar, footer, a block above the main content, or a dedicated template position. In a module, it is not enough just to select the right widget. You also need to configure publication, position, menu assignment, and access level correctly. If the module exists but is not visible, the cause is often in Joomla's standard settings rather than in Widgetkit itself.

Check the following:

• The module is published.
• An existing template position is selected.
• The menu assignment includes the correct page.
• The access level allows regular visitors to see the module.
• The cache has been cleared after changing the position or assignment.

For debugging, you can temporarily assign the module to all pages and place it in a known working position where other modules already display. If the widget appears, restore the precise menu assignment and test that part next.

Output Through YOOtheme Pro or Another Layout

If the site uses YOOtheme Pro, the shortcode can be inserted into a text element. This is useful when the page is being built in the builder, but a specific block is easier to manage through Widgetkit. What matters is not mixing responsibilities: the builder controls the page layout, while Widgetkit controls the widget content and behavior. If everything is edited in both places at once, page maintenance becomes more complicated.

For other templates and builders, use the method that does not interfere with Joomla's standard output. Do not insert code into template files unless there is a real need. If the block should be a permanent part of the layout, it is usually better to create a module and assign it to a position than to hardcode the output into the template.

Practical Example: A Project Gallery for a Service Page

Now let's build a concrete scenario. Imagine a studio or agency site with a service page that needs to showcase several completed projects. The goal is not just a decorative carousel, but a clear working block: images, short titles, categories or captions, a link to a detailed description, and a visible result on the site frontend.

Scenario Goal

The goal is to create a project gallery that an editor can update without editing the template. The user should see several examples, quickly understand what type of work they represent, and then move to the detailed project or service page. For this scenario, gallery or grid is usually the best fit because visitors can see several items at once and compare them.

Preparing the Content

Before creating the widget, prepare 6 to 12 images with similar proportions. Each project needs a short title, a one-sentence description, and a link. If you plan to use tags, think them through in advance: for example, "Website," "Catalog," "Landing Page," or "Redesign." Do not create too many tags for a small gallery, or the filter will feel more complicated than the content itself.

Steps in the Admin Panel

1. Open Components » Widgetkit and create a new widget.
2. Choose the type that works best for showing several projects: gallery or grid.
3. Add the items manually or select a confirmed content source if the projects are already stored in the system.
4. For each item, fill in the title, image, short description, and link.
5. Check the item order: the most representative project should come first, not a random entry.
6. In the display settings, choose a grid that does not overload the page: for main content, 2 or 3 columns are usually enough.
7. Add a custom CSS class such as wk-services-gallery if you plan to fine-tune the appearance safely through the template.
8. Save the widget and display it on a test page using a shortcode or module.

Verifying the Result

Open the page as a regular visitor. Check whether all items are visible, whether important parts of the images are being cropped, whether the captions are too long, and whether the links work. Then narrow the browser window or test at mobile width. The gallery should remain easy to understand even if the number of columns decreases.

Quick conclusion for this scenario: if the visitor can see several projects, understand the categories, open the details, and the page still behaves correctly after clearing the cache, your first working widget is configured properly.

A Detail That Often Gets in the Way

The issue may not be in Widgetkit itself, but in the output location. For example, the module may be assigned only to the homepage while you are testing a service page. Or the shortcode may be inserted into an article, but the editor has altered the service markup. So when something goes wrong, separate the chain first: the widget is saved, the output method is valid, the publication location is active, the page cache has been cleared, and the browser console shows no JavaScript errors.

Checking Speed, SEO, and Usability After Publishing

Widgetkit helps you create a visual block, but the quality of the page depends on the whole site. After publishing, you need to check not only the appearance, but also speed, information accessibility, indexing, and behavior across devices. This matters especially for galleries, slideshows, and interactive blocks, where images and JavaScript are involved.

Speed and Images

The official Widgetkit page promises optimized resource handling, but source images and the environment still matter. If you uploaded large photos, the page can become heavy regardless of the widget. So check page weight after publishing. If the block is on the homepage, it affects the first-time visitor much more than a gallery on an inner page.

Useful practical checks:

• Open the page in a regular browser while logged out and make sure the images are not loading too slowly.
• Check that there are no unnecessarily huge source image files.
• Make sure the slider or gallery is not blocking the site's first screen.
• After enabling cache, test interactivity again, not just load time.

SEO and Hidden Content

Interactive blocks can help users, but they should not hide important meaning. If the main benefits of a service are hidden in the third slide, some visitors will never see them. If the FAQ is fully hidden in an accordion, users should still be able to understand from the headings what answers are inside.

For search optimization, do not turn Widgetkit into a container for all of the page text. The main content should remain in the normal article structure: headings, paragraphs, lists, and tables. A widget is better used as a visual supplement, a navigation block, or a compact way to present related items.

Usability and Accessibility

Check how interactive blocks are controlled. The user should understand that an element can be opened, switched, or scrolled. Autoplay that is too fast, arrows that are too small, long text inside a card, or weak contrast can make a block look attractive while still being inconvenient to use. If in doubt, choose a calmer display mode.

For maps and media player widgets, check privacy and external loading. YOOtheme documentation includes a separate privacy and GDPR page explaining that some features may interact with third-party services. Do not add a map or video just for visual appeal if your site has strict privacy requirements or needs to minimize external requests.

Result Verification as a Separate Stage

After publishing, do not stop at saying "the page looks good." A live site needs a repeatable check that can be performed by someone other than the developer. That check should include the page both while logged in as an administrator and while logged out, mobile width, cache clearing, clicking links from the cards, and checking the browser console for errors. This is not bureaucracy. It is the fastest way to distinguish a content problem from an output problem.

Create a small checklist for the editor. For example: "after replacing an image, open the page, check the first and last card, click the link, clear the cache, and review the mobile width." That checklist is especially important if Widgetkit is used on the homepage or in a commercially important section. In those places, even a small error, such as an empty slide, a broken link, or a title that is too long, becomes immediately visible.

For blocks that use external services, add one more check: what exactly loads from outside. A map, video, or media player may pull resources from more than just your own domain. If the site has a strict privacy policy, that should be agreed on before publishing. There is no universal answer for every site, so it is better to document the decision in the project documentation: where the external service is used, why it is needed, and how to disable the block if requirements change.

Safely Refining the Look with a CSS Class

Sometimes the built-in settings are enough, but the block still needs to fit the template a little more cleanly: reduce the top spacing, align captions, calm down the cards, or remove excess visual noise. The safest way is to use the widget's custom CSS class, if one is set in the settings, and add CSS in the template's standard location or the site's custom CSS file.

Do not edit Widgetkit files. Those changes may disappear after an extension update, and a mistake inside the extension files makes the site harder to maintain. A safe customization should be small, reversible, and tied to one specific class. Below is an example for the project gallery from the practical scenario. It does not change the widget logic. It only makes the captions and spacing cleaner.

.wk-services-gallery {
  margin-top: 24px;
}

.wk-services-gallery .uk-card,
.wk-services-gallery .uk-panel {
  border-radius: 6px;
}

.wk-services-gallery h3,
.wk-services-gallery .uk-h3 {
  line-height: 1.25;
}

.wk-services-gallery p {
  margin-bottom: 0;
}

You should add this code only after the widget has been assigned the wk-services-gallery class. Check the result on the service page and at mobile width. If the widget looks worse, remove the CSS or temporarily rename the class in the widget settings. That kind of rollback does not affect the content and does not require reinstalling the extension.

If the site has several similar galleries, do not use the same class for all of them without a reason. It is better to give each important block its own name and combine styles only where there is a true shared pattern. That way you avoid a situation where changes to cards on the service page unexpectedly alter the portfolio, testimonials, or partner block. When maintaining a Joomla site, that kind of discipline matters more than having shorter CSS.

When It Is Better Not to Add CSS

Do not add CSS if the issue is not visual, but an output error. An empty block, broken shortcode, image 404s, a JavaScript error, or incorrect module assignment cannot be fixed with cosmetic styling. First restore the working chain, then improve the visual layer.

Also, do not use CSS as a substitute for a proper content structure. If the cards have different heights because the descriptions are too long, shorten the descriptions and normalize the data first. If the images are inconsistent in quality, prepare the media properly. Styles should polish an already solid block, not mask poor preparation.

Why the Widget Does Not Display or Works Incorrectly

Troubleshooting is best handled from simple to complex. Widgetkit may be installed correctly, but the final block still may not appear because of the module, the editor, cache, access permissions, or a script conflict. Below are common symptoms for a Joomla site and a careful order for checking them.

The Shortcode Is Visible on the Page Instead of the Widget

Symptom: the visitor sees a service string instead of a finished block. A likely cause is that the shortcode was inserted in a place where it is not processed, or the editor changed it when saving.

What to Check

• Open the article in source HTML mode and confirm that the shortcode was saved without extra characters.
• Make sure the widget still exists and was not deleted or renamed after copying.
• Check whether the shortcode was inserted into an area where the template outputs text as a plain string.

The fix usually starts by reinserting the shortcode from the Widgetkit manager. If the visual editor changes the code again, temporarily switch to source mode or use module output instead.

The Module Exists, but the Block Does Not Appear

Symptom: the module is present in the admin panel, the widget is selected, but nothing is visible on the page. In most cases, the cause is standard Joomla settings rather than Widgetkit itself.

What to Check

• The publication status of the module.
• The template position and whether that position exists in the current layout.
• The menu assignment: the module may be hidden on the page you are testing.
• The access level and user groups.
• Joomla cache and template cache after changing the settings.

For a quick check, assign the module to all pages and place it in a known working position. If the block appears, restore the precise assignment gradually. If it still does not appear, check the selected widget and the browser console for errors.

The Slider or Gallery Displays but Does Not Switch

Symptom: the HTML and images are visible, but the arrows, switching, map, or popover elements do not work. A likely cause is a JavaScript conflict, script loading optimization, or an error from another extension on the page.

Start with the browser console. If there are JavaScript errors there, do not randomly change widget settings. Temporarily disable script merging and deferred loading, clear the cache, and test again. If the problem disappears, configure exclusions in the optimization tool. If it does not, check whether another module on the same page is causing the conflict.

Images Are Missing or Thumbnails Are Not Being Generated

Symptom: the block is displayed, but some images are missing, thumbnails are not generated, or the path leads to an error. Possible causes include incorrect folder permissions, migration issues, missing PHP GD support, or an invalid file path.

Check GD support, write permissions, and whether the images are physically present. If the site was recently migrated, compare file ownership and permissions with the working Joomla folders. Do not try to solve this by editing the widget HTML. If the server does not let the extension create files, cosmetic settings will not help.

The Block Looks Fine in the Admin Panel but Breaks in the Template

Symptom: everything looks clean in the settings, but on the page the cards stretch, captions overlap, the slider is wider than the container, or the grid does not match the layout. The cause is often template CSS, container width, or neighboring modules.

Check the page in the real layout. If the issue is purely visual, use a custom CSS class and a small template-level adjustment. If the issue comes from placing the widget in a position that is too narrow, it is better to change the output location or the widget type. Not every slideshow works well in a sidebar, and not every gallery belongs in a narrow module.

When It Is Better to Roll Back a Setting

A rollback makes sense if enabling an effect, autoplay, external service, or script optimization makes the block less clear or less stable. Return to the last working version, clear the cache, and note which setting triggered the symptom. On a live site, that approach is safer than trying to force an effect to work at any cost.

When YOO Widgetkit 3 Pro Is the Right Choice

YOO Widgetkit 3 Pro is worth using if your Joomla site needs repeatable visual blocks that an editor can manage: galleries, slideshows, grids, accordions, maps, lists, and other elements. It is especially useful when you do not want to build a separate component, but instead need to assemble a clear block quickly, output it through an article or module, and verify the result on a real page.

Before using it in production, do more than just install it. Create a test widget, verify the output method, check the page while logged out, clear the cache, and make sure the images, scripts, and styles work correctly in your template. If everything is stable, you can download the ZIP archive and move on to careful configuration on your site or a staging copy.

The best results come when Widgetkit is treated not as a set of effects, but as a working visual content system: clear widget names, prepared images, a deliberate output type, speed checks, and troubleshooting along the chain of "component - output method - page - cache - browser." In that case, the extension genuinely helps maintain a Joomla site instead of becoming one more source of random blocks.