Category: Joomla

Using Joomla eCommerce for your Online Business

Implementing and leveraging online businesses can make your consumer base far beyond the existing local audience.
Creating an online store used to be a challenge a few years ago, but new and improved eCommerce tools and platforms make this process easier than ever.
Are you looking for the easiest way to start your own online business immediately?
Every online store needs a content management system (CMS) to simplify the creation and modification of online store content (lists, purchase orders, etc.). Partly due to its free and open source format, Joomla has become one of the most popular CMS options available to all potential online store operators.
Many people have questions in mind if Joomla is good for eCommerce. Let me tell you, it is very easy to create a website with Joomla. Even so, beginner eCommerce operators may still need help when using Joomla to build an online store. Therefore, I created this tutorial to teach you how to use Joomla to create an eCommerce website. After mastering this e-commerce website tutorial, you will immediately build your own powerful and versatile online store.

Find the best web host

Before choosing a domain name, you need to find the best online hosting service for your website. There are many options in this step, including the hosting provider you choose and the type of service (dedicated, shared, hosted, etc.). In fact, many web hosting providers now offer options to meet the needs of online store operators. These options may be your best choice.
Since you intend to use Joomla as a CMS, I strongly recommend that you seek dedicated Joomla hosting. These providers have optimized their user experience to maximize Joomla’s built-in features, allowing you to make the most of online stores.

Choose a domain name

Regarding building an online store, you must start from scratch. This usually means buying a digital “land” on which an online store will be built. To do this, you need to buy a domain name.
Your domain name serves as a logo on the front of the online store. In other words, it should be unique and memorable, but it shouldn’t be too complicated.

Download and Install Joomla

Once you have booked the domain name, you can take the next step and download Joomla from the official website.
After the download is complete, you will have two options to install Joomla on the website: automatic and manual. Depending on the web hosting provider you choose, you may be able to install Joomla on your new website in one click. In your website console, search for the one-click installation option, and then navigate to the colored Joomla button (if available).
However, in most cases, you will need to manually install Joomla on your website. The first step of this process can be done from the main control panel of your website. Create a MySQL database from there. This is where all your website data (including Joomla software) is stored. After completing this step, you can upload Joomla and implement it on your website.
To implement Joomla, open a new window and navigate to the URL of your website. This will start the Joomla installation process, and then you can follow the instructions on the screen to successfully complete the installation.

Install Templates and Extensions

There are two free and premium extensions available for Joomla eCommerce website. For Joomla eCommerce website development, the best component to use is Virtuemart which is non-commercial. It’s easy to integrate and user friendly. I also find HikaShop relatively useful for Joomla eCommerce solutions. And it will become an excellent alternative to Virtuemart. The eCommerce extension comes with many features that have minimal restrictions in the free version and wide opportunities in the commercial version. Therefore, in addition to the user experience, I generally like the extension. There are a lots of tutorials available over internet to setup and configure these Joomla eCommerce component.
Incase you seek any professional help or Virtuemart Services, you can contact us anytime.

Configuration and Setup of Joomla eCommerce

With the main features and appearance, you can begin to configure the many options that make up a customized online store. These options can run the color gamut in all aspects of your website, including templates, checkouts, SEO, shopping cart, etc. Be prepared to spend some time carefully reading and applying these initial settings.
Configuration is not just a step-by-step process. You need to make configuration changes regularly, especially after adding a product list. The best way to check if your changes are working as expected is by testing the site in real time and running it on a separate browser that is not logged in as the site administrator.

Addition of Products

Many people are eagerly waiting for this step, and now the product list can finally be released. At this point, you can use Joomla’s built-in functions to create and manage lists without adding trouble. In this regard, Joomla can intuitively handle a large amount of “behind the scenes” information, including price and availability.
In addition to the product list, you can also use this time to enrich your online store. This should include the creation of a homepage and important pages such as “About Me” and “Contact Us”. Each of these additional pages can improve the spirit of your online store and increase the likelihood that visitors will remember your store later.

Summary

Ultimately, Joomla makes building and deploying an eCommerce platform as easy as possible. Joomla eCommerce is simplified from start to finish, from installation to product listing.
Joomla e-commerce sites are among the most comprehensive today and are just a few clicks away to take advantage of this versatility in your own business.
Now that you have learned how to successfully implement Joomla with this eCommerce website tutorial, you can start taking the first steps towards increasing your online success.

Sometimes you may want to uninstall Joomla from the server for one of the following reasons:

• You want to move the Joomla website to another server and you want to use the current host to delete all information related to the website.
• There was a problem with your initial installation and you want to redo everything from the beginning.
• You just want to get rid of your Joomla website!

Unlike installation, there is no such method to uninstall the Joomla directly from the server. Uninstall of Joomla is done manually. For this, you need to delete all the Joomla files and drop the MySQL database that has been created during installation.

• Well, the process is very simple, here is what you can do:
• Log in to the FTP of your website and delete all Joomla folders and files.
• Make sure you do not delete folders that do not belong to your Joomla website.
• If you have installed a lot of extensions and/or a lot of images/files on your website, this process may take a long time.
• Go to phpMyAdmin and delete the database containing the data of the Joomla website.
• Make sure not to delete shared databases (databases shared by different websites, the only difference is the table prefix). Go to the “Cron Jobs” page (or Cron Manager) in cPanel and delete all cron associated with the Joomla website.

Generally, it takes a lot of time to delete the files through FTP, so its recommended to remove data through host manager (ex: Cpanel, Plesk).

How to uninstall Joomla from cPanel?

If you have installed the Joomla through any of the Joomla website using Softaculous an auto-installer in cPanel, then you can uninstall the Joomla in a single click. Softaculous is a commercial script library that automatically installs commercial and open source web applications onto websites. Most of the hosting provides like Godaddy, Siteground and Hostgator provides cPanel with Softaculous in it.
If you need help uninstalling the Joomla website, or if you think the process is daunting, then we will help you. Please contact us and we will serve you.

Summary

If you are afraid to perform this process, please don’t do it and seek help from a Joomla professional.
Remember, if something goes wrong, it will definitely go wrong! Be careful while you delete the files or folders.
If you are not sure about a file or directory, please do not delete it, and then seek the help of a Joomla professional again.
This process does not delete the email account associated with your Joomla domain.

Disabling cookies for visitors on a Joomla website does not mean deleting the core session cookie. That cookie is strictly necessary for forms, CSRF tokens, and login safety. What site owners usually need is to stop non-essential cookies (analytics, marketing, embeds, preference trackers) until the visitor gives informed consent under GDPR, ePrivacy, and similar laws. On Joomla 4, 5, and 6 the practical path is a consent module such as Easy Cookie Alert by Infyways, not a core hack that turns sessions off.

Thin “7 steps to disable cookies” posts still tell people to kill Global Configuration settings that do not exist, or to patch index.php so guests have no session. That breaks forms and security. This guide is the operator correction: cookie categories, what Joomla core actually sets, how to gate third-party tags, how to configure Easy Cookie Alert, and how to verify the result without inventing a free DIY banner that fights your template.

What you will learn

• Necessary vs optional cookies on a real Joomla site
• Why you should not disable the guest session cookie
• How consent, Reject all, and prior blocking differ from an information-only bar
• Step-by-step setup with Easy Cookie Alert on Joomla 4, 5, and 6
• Google Consent Mode v2, embed freeze, and consent proof
• How to test in DevTools and what still fails if tags stay in the template

What Joomla sets by default

Core Joomla is not an ad network. The Joomla Project’s own cookie policy treats the random session cookie as strictly necessary. It ties the browser to a server-side session so CSRF tokens and forms work. Official core does not ship Google Analytics or marketing pixels. Most compliance risk comes from extensions, template scripts, GTM, and embeds you add later.

Primary references: Joomla cookie policy, the long-running discussion that core does not ship a full cookie manager, and EU ePrivacy rules that require consent before non-essential storage on the device.

Do not disable the guest session cookie

Older forum advice suggests editing index.php to start the site application with session => false for guests, or hacking session table inserts. That belongs in the museum next to Joomla 1.5 tips.

• Sessions power form tokens. No session means weaker CSRF protection and broken logins.
• Bots and humans still hit login URLs even if you hide the menu item.
• Security vendors (including Akeeba guidance historically) treat guest session cookies as required for safe forms.
• “Disable cookies” in a privacy sense means do not set tracking cookies, not “run a CMS without sessions.”

If your goal is fewer database writes from guests, use Session settings such as limiting session metadata for non-registered users where your Joomla version supports it. That is a performance tweak. It is not a consent solution and it does not remove the cookie.

What “disable cookies for visitors” should mean

Why lead with Easy Cookie Alert

Infyways builds Easy Cookie Alert for Joomla 4, 5, and 6. It is a module (vanilla JS, no jQuery) with Accept all, Reject all, Cookie settings, layouts (Bar, Floating, Modal, Overlay), category script slots, Google Consent Mode v2, embed blocking, optional consent proof logging, and CCPA Do Not Sell support. Full setup notes: Easy Cookie Alert documentation.

Vendor CMP suites and generic “paste this banner” snippets can work, but on Joomla they often fight template assets or leave tags in index.php. A native module that owns the script slots keeps the consent decision and the tags in one place.

Step 1: Inventory cookies and scripts

1. Open the site as a guest in a private window.
2. DevTools → Application → Cookies. Note first-party and third-party names.
3. Network tab: find analytics, ads, chat, and social hosts.
4. List every extension or template feature that injects those tags.
5. Write a short privacy policy section that names necessary cookies and optional categories.

If the inventory is mostly session cookies and nothing else, you may only need a clear policy statement. The moment you add GA4, Meta Pixel, Hotjar, or third-party embeds, you need consent gating.

Step 2: Install and publish Easy Cookie Alert

1. Download the package from the JED listing and unzip it.
2. System → Install → Extensions → upload mod_cookiealert_…zip.
3. Content → Site Modules → Easy Cookie Alert.
4. Status: Published. Hide Title.
5. Assign a module position (debug is fine; the banner portals to the document body).
6. Assign menu items for every public page that needs consent.
7. System → Clear Cache.

Step 3: Configure content, layout, and categories

• Content: message, privacy policy link, Accept / Reject / Settings labels, optional CCPA Do Not Sell copy
• Layout: start with Bar Bottom; use Overlay or Modal with Force consent when choice must happen first
• Categories: Necessary stays on; enable Analytics, Marketing, Functional, and custom categories you need
• Consent days: how long a choice is remembered
• Consent version: bump when the policy changes so returning visitors are asked again

Reject all must be as easy as Accept all. A banner that only offers OK is not enough for modern EU expectations.

Step 4: Move tags into category scripts

1. Remove GA / ads / chat snippets from the template head and from “custom code” plugins that always fire.
2. Paste each tag into the matching category script slot in Easy Cookie Alert.
3. If you use Google Tag Manager, enable Consent Mode v2 so defaults are denied in the head before tags run, then update after the visitor chooses.
4. Turn on embed blocking if articles include YouTube, Vimeo, or Maps.
5. Optional: enable consent proof logging when you need anonymised receipts.

If tags remain hard-coded in the template, the banner cannot undo them. Consent UI without prior blocking is theatre.

Step 5: Verify as a guest

1. Private window, no prior consent cookie.
2. Confirm Reject all leaves analytics and marketing cookies unset.
3. Confirm Accept all (or category save) loads only what was allowed.
4. Submit a contact form and confirm it still works (session cookie present).
5. Reopen Cookie settings from the floating control and change a choice.
6. Bump consent version on staging and confirm the banner returns after a policy change.

Multilingual, shops, and logged-in users

What thinner articles get wrong

When you also need an upgrade

Consent modules expect a current Joomla 4 / 5 / 6 stack and PHP 8. If the site is still on Joomla 3 with abandoned analytics plugins, fix the platform first. Infyways runs migrations from $149 with a free audit within 12 hours: Joomla Upgrade Services.

Key takeaways

1. Do not disable the Joomla session cookie for visitors. It is strictly necessary.
2. “Disable cookies for visitors” means block non-essential cookies until consent.
3. Use Accept all, Reject all, and category preferences with prior blocking.
4. Move analytics and marketing tags out of the template and into consent-controlled slots.
5. Easy Cookie Alert covers Joomla 4, 5, and 6 with Consent Mode v2, embed freeze, and optional proof logs.
6. Verify in a private window. A banner that never changes the Network panel is not compliance.

Frequently asked questions

Can I fully disable cookies for Joomla visitors?

No, not if you want a safe dynamic site. Keep the necessary session cookie. Disable or delay optional tracking cookies until consent.

Does Joomla core require a cookie consent banner by itself?

Often no, if you only use the session cookie and document it. Yes as soon as you add analytics, ads, or many third-party embeds.

Is an information-only cookie bar enough for GDPR?

No. Visitors need a real choice, including Reject all, and non-essential scripts must not run first.

Will Reject all break my contact form?

It should not. Forms rely on the necessary session cookie, which stays available.

What is Google Consent Mode v2 in this context?

It tells Google tags to default to denied until the consent module updates the choice, so tags do not behave as if consent already existed.

Where do I get Easy Cookie Alert?

From the Joomla Extensions Directory listing. Setup details are in the JoomlaX documentation.

Does System – HTTP Headers disable cookies?

No. That plugin manages security headers such as CSP and HSTS. It is complementary hardening, not a consent manager.

How do I re-ask visitors after a policy change?

Increase the consent version in the module so stored choices are invalidated and the banner shows again.

Where do we start if the site is old and full of abandoned trackers?

Request a Joomla upgrade audit, then install a current consent module on the upgraded stack.

A Joomla browser compatibility issue is a page that works in one current browser and fails in another. Joomla 4, 5, and 6 support the current major version and the one before it of Chrome, Edge, Firefox, and Safari (the n-2 policy the project adopted in 2019). Internet Explorer is not supported. Most reports are not browser bugs at all: they are a cached stylesheet, a browser extension, a Joomla 3 template, a cookie scoped to the wrong host, or one of three documented core bugs (Safari 15 and Joomla’s ranged media queries, Firefox 148 and TinyMCE in Joomla 5.4.3 / 6.0.3, and Conservative caching breaking the Web Asset Manager). This guide separates them in order and gives the fix for each.

Generic cross-browser posts tell you to “test on real devices” and “check Can I Use.” That does not help when the administrator dashboard renders as a single column on a client’s Mac or the article editor flickers forever in Firefox. Those are known Joomla issues with issue-tracker numbers, version ranges, and specific fixes. You will find them here, together with a triage that stops you rewriting CSS for a problem the private window would have solved.

What you will learn

• Which browsers Joomla 4, 5, and 6 actually support and where that policy is written
• How to tell a browser bug from cache, an extension, a responsive bug, or a PHP error
• The three documented Joomla core bugs that only show in one browser, with fixes
• Which modern CSS features are safe for Joomla templates in 2026 and which still need fallbacks
• Safari-specific quirks (100vh, hover, date inputs, backdrop-filter, autoplay) and how to code around them
• The Safari login failure that is really the site URL
• A tested one-command fix that makes Cassiopeia render on Safari 15 from a child template
• Which testing tools are worth using and in what order

Supported browsers by Joomla version

Bootstrap’s rule, which Joomla’s UI follows, is the latest stable browsers, not Internet Explorer: Bootstrap browsers and devices. The IE11 bundle removal is recorded in the Joomla 4.4 to 5 removal list. The wiki page Joomla Browser Support is a Joomla 3 document. Do not use it as the matrix for Joomla 5 or 6.

What n-2 means in practice: Safari ships one major per year, so a Mac that cannot go past Safari 15 (macOS Monterey and older) is outside support for every Joomla 4.4.1 or newer release. Chrome, Edge, and Firefox update monthly and auto-update, so “old Chrome” is almost never the cause. Firefox ESR is supported because it tracks a recent major.

Documented one-browser bugs in Joomla core

Check this table before you touch any CSS. If the symptom, browser, and Joomla version match, the fix is known.

Name the failure before you edit CSS

Step 1: Write down the browser, the version, and the URL

1. Note the browser name and a major version (Chrome 14x, Safari 18, Firefox ESR). “Doesn’t work on Mac” is not a report. On a Mac, Safari → About Safari shows the version; the macOS version tells you the maximum Safari it can run.
2. Note the exact URL. Site homepage, one article, and /administrator/ are three different products.
3. If the browser is Internet Explorer, stop. On Joomla 4, 5, or 6 that is expected. Send the user to current Edge, Chrome, Firefox, or Safari.
4. If the browser is Safari 15 or older and the layout is the complaint, go to the core bugs table. You are done diagnosing.
5. If every current browser fails the same way, you are not debugging compatibility. Fix the error, the missing file, or the template, then come back.

Step 2: Rule out cache and extensions

1. Open a private window with extensions disabled. Retest the same URL.
2. If the private window is fine, the cause is a cached file or an extension (ad blockers block scripts and fonts, Firefox Enhanced Tracking Protection and Brave Shields block third-party hosts). Clear that browser’s cache for the site. Then clear Joomla’s cache (System → Maintenance → Clear Cache) and any CDN.
3. If the private window is still broken, the site is serving the failure. Continue.

Joomla appends its media version to core asset URLs, and that version changes when you update Joomla or an extension. A hand-edited user.css does not change it, so browsers can keep the old file for days. Clear Joomla cache after CSS edits, and on a CDN purge the CSS path.

Step 3: Read the console, not the homepage

1. Open developer tools in the broken browser. Console and Network.
2. Reload. Copy the first red error. The file name is the extension or the template.
3. On Network, filter CSS and JS. A red row is a 404 or a blocked request. An unstyled page with a 404 on template.css is a path problem, not a rendering engine.
4. Mixed content (HTTPS page calling http:// assets) is blocked hardest by Chrome and Safari. Fix the URLs in the template and in article HTML. Do not tell users to allow insecure content.
5. “Refused to load” or “violates the following Content Security Policy” means the System – HTTP Headers plugin (or the host) set a CSP that the extension does not satisfy. Browsers enforce CSP slightly differently, which is why it can look like a one-browser bug. Fix the policy or the inline script, do not disable CSP site-wide.

Step 4: See if the template is the only broken piece

1. On a staging copy, set the site template to Cassiopeia (System → Site Templates).
2. Retest the broken browser.
3. If Cassiopeia is fine, your template or one of its overrides is the bug. Update it to a build for this Joomla major, or replace it. Joomla 3 templates (Bootstrap 2, IE conditional comments, MooTools menus) will not become compatible by adding a script.
4. If Cassiopeia fails too, the template is not the cause. Look at modules on that page, then at the core bugs table.

Confirm the template prints a viewport tag. Cassiopeia does. A custom index.php that omits it makes phones look “broken in Safari” while the desktop looks fine:

<meta name="viewport" content="width=device-width, initial-scale=1">

Step 5: Disable the extension named in the console

The first console line usually names a file under /media/, /templates/, /modules/, or /plugins/. Disable that extension on staging and reload.

• A menu or slider that calls MooTools or an ancient jQuery will fail in current browsers even when the rest of the page is fine. Background: remove MooTools from Joomla.
• Do not “fix” it by loading jQuery again. Joomla 4, 5, and 6 core UI does not need jQuery. A second copy fights over $ and creates a new one-browser failure.
• HTML5 Shiv and Respond.js were IE8 hacks. They do nothing on Joomla 4+ and add a script current browsers do not need. Remove them if a ten-year-old tutorial put them in the template.
• Page builders and Helix-style frameworks that still ship -moz-, -ms-, and -webkit- prefixed rules from 2015 produce console warnings but rarely break layout. Update the template; do not hand-edit its compiled CSS.
• Custom scripts you added yourself belong in a child template or a proper include, not pasted into index.php: add or remove custom JavaScript in Joomla.

Step 6: Audit modern CSS the template uses

When the template is yours or a child template, check the newer CSS features it relies on. This is the 2026 state of the features that most often produce “works in Chrome, broken in Safari or Firefox” on Joomla sites. Verify current numbers on Can I Use.

Pattern for anything not yet universal:

.hero { min-height: 100vh; }
@supports (height: 100dvh) {
  .hero { min-height: 100dvh; }
}

Step 7: Safari and iOS quirks that are not bugs

Step 8: Fix Safari login separately from CSS

If the page looks right in Safari but login or the administrator session dies, stop comparing stylesheets.

1. Global Configuration → Site → Site URL, and the live host, must be the same scheme and host. https://example.com and https://www.example.com are different cookie hosts. Chrome is more forgiving of the redirect. Safari drops the session.
2. Force one host in the server redirect, then clear cookies and test again.
3. Global Configuration → System → Cookie Domain and Cookie Path: leave blank unless you run subdomains that must share the session.
4. If the Joomla page is inside an iframe on another site, Safari blocks that third-party cookie. Do not embed the login.
5. Session and consent cookies are covered in disable cookies for Joomla visitors.

Step 9: Fix it in a child template, not in core

Joomla 4.1 and newer support child templates. Every browser fix you write belongs there so updates do not erase it.

1. System → Site Templates → Cassiopeia (or your template) → Create Child Template.
2. Add rules to media/templates/site/{child}/css/user.css. Cassiopeia loads user.css automatically after its own CSS.
3. Need to override a core stylesheet? Joomla resolves a relative asset such as template.min.css by looking in media/templates/site/{child}/css/ first and only then in the parent’s folder (HTMLHelper::includeRelativeFiles). A file with the same name in the child wins. No joomla.asset.json edit is needed.
4. Never edit media/vendor/bootstrap, media/templates/site/cassiopeia, or media/system. The next Joomla update replaces them and the “fix” disappears in one browser first, which restarts the whole hunt.

Tested: make Cassiopeia render on Safari 15 from a child template

We inspected the files Joomla 6.0.0 and 6.1.0 ship. Cassiopeia’s template.min.css contains 111 media queries, all in range syntax and none in min-width form. Atum has 118, and media/vendor/bootstrap/css/bootstrap.min.css (Bootstrap 5.3.8) has 81. Cassiopeia does not load the vendor Bootstrap file at all; Bootstrap is compiled into template.min.css, so swapping the vendor file does nothing for Cassiopeia. The fix is to transpile the template CSS.

1. Create the child template (step 1 above). Note its folder name, for example cassiopeia_legacy.
2. On any machine with Node.js, run Lightning CSS against the shipped file with a Safari 15 target:

   npx lightningcss-cli --targets "safari >= 15" --minify 
     media/templates/site/cassiopeia/css/template.min.css 
     -o media/templates/site/cassiopeia_legacy/css/template.min.css

3. Result on Joomla 6.1.0: 111 ranged queries became 111 min-width / max-width queries, file size 247 KB to 251 KB, everything else unchanged. Repeat for template-rtl.min.css if you serve RTL.
4. Clear Joomla cache. Load the site in Safari 15 (BrowserStack macOS Monterey works) and the grid returns.
5. After every Joomla update that changes Cassiopeia, rerun the command. Your child file is never touched by the updater, but it also does not receive core CSS fixes until you regenerate it.

For the administrator, the same approach works with an Atum child template and media/templates/administrator/{child}/css/template.min.css. In practice, updating Safari on the one editor’s Mac is the cheaper fix. For third-party templates that load media/vendor/bootstrap/css/bootstrap.min.css, transpile that file into the child’s css/ folder and change the template’s asset URI to point at it.

Step 10: Retest the supported browsers, in this order

1. Chrome or Edge on desktop (same engine, still check Edge once if the client uses it).
2. Safari on a real Mac or iPhone. Desktop Chrome does not stand in for iOS Safari; on iOS, Chrome and Firefox are WebKit under the hood, so “works in Chrome on iPhone” tells you nothing about Chrome on desktop.
3. Firefox, including ESR if the client is a locked office build.
4. The administrator on each, not only the homepage. Article edit screen included (that is where the Firefox 148 bug shows).

Tools, in order of cost: your own devices and a colleague’s Mac; Safari Technology Preview and Firefox Developer Edition for what is coming next; Playwright (free, runs Chromium, WebKit, and Firefox from one script) for regression screenshots; BrowserStack or LambdaTest when you need a specific old macOS and Safari 15 to confirm the ranged media query case. A paid lab is not the first step, and it will not make Internet Explorer run Joomla 6.

Do not sniff the browser

Joomla’s old browser class, and any template switch based on the user-agent string, will mislabel current Edge, Brave, and in-app webviews. Safari on iPad reports itself as macOS Safari. Serve one template. Fix the CSS with @supports and media features like (hover: none). User-agent hacks are how a site ends up with a broken stylesheet that only one browser ever loads, which then looks exactly like a compatibility bug.

When the honest fix is an upgrade

If the site is Joomla 3 and the goal is “works in current Safari and Chrome”, Protostar and a pile of IE scripts are the wrong project. Move to a Joomla 5 or 6 template built on Bootstrap 5, on staging, then retest. Path notes: Joomla upgrade issues and benefits of Joomla migration. Infyways runs those jumps from $149, with a compatibility audit within 12 hours: Joomla Upgrade Services.

What thinner articles leave out

Key takeaways

1. Joomla 4, 5, and 6 support the current and previous major of Chrome, Edge, Firefox, and Safari. Not Internet Explorer, not Safari 15.
2. A wide screen showing the mobile layout in Safari 15 or older is the ranged media query bug. Update Safari, or transpile template.min.css into a child template. Do not edit core CSS.
3. Firefox 148 and a flickering TinyMCE on Joomla 5.4.3 or 6.0.3 means install the hotfix or update.
4. Same failure in every browser is not a browser bug.
5. Private window first, then the console, then Cassiopeia, then the extension named in the error.
6. Safari login failures are usually the site URL and cookie host.
7. Use @supports, 100dvh, and (hover: none) instead of user-agent sniffing.
8. Put every fix in a child template. Do not add HTML5 Shiv, Respond.js, or a second jQuery.

Frequently asked questions

Which browsers does Joomla support?

For Joomla 4, 5, and 6: the current major version and the one before it of Chrome, Edge, Firefox, and Safari. Internet Explorer is not supported. The old Joomla 3 browser list is not the matrix for current releases.

Why does the Joomla administrator show one column on a Mac in Safari?

Safari 15 and older do not understand the ranged media queries in Joomla 4.4.1 and newer core CSS, so the responsive grid collapses. Update to Safari 16.4 or newer, or use Chrome or Firefox on that Mac.

Why does the article editor keep reloading in Firefox?

Firefox 148 broke TinyMCE in Joomla 5.4.3 and 6.0.3. Install the Firefox 148 TinyMCE hotfix from the Joomla download page or update to 5.4.4 / 6.0.4 or newer.

Why does the site look fine in Chrome and broken in Safari?

Check a private window, then the console. If the layout is the mobile layout on a wide screen, check the Safari version. If only login fails, compare the Global Configuration site URL with the host Safari is using, including www and HTTPS.

Why is the administrator broken in Internet Explorer?

Joomla 4 and newer use Bootstrap 5 and modern JavaScript. IE11 is outside that support. Use Edge or another current browser.

Will HTML5 Shiv or Respond.js fix it?

No. Those scripts patched Internet Explorer 8. They do not fix Joomla 4, 5, or 6, and they should come out of the template.

The layout breaks on phones but not on desktop. Is that a browser bug?

No. If every browser breaks at the same width, it is responsive CSS or a missing viewport tag. If only iOS overflows at the bottom, replace 100vh with 100dvh.

One browser still shows the old design after I changed the template. Why?

That browser cached the CSS. Test in a private window, then clear Joomla cache and the CDN. Editing user.css does not change Joomla’s media version.

Should I load jQuery so older browsers work?

No. Extra jQuery copies cause $ conflicts. Current Joomla does not need jQuery for the core layout.

Can I make Cassiopeia work on Safari 15 without editing core files?

Yes. Transpile media/templates/site/cassiopeia/css/template.min.css with Lightning CSS targeting Safari 15 and save the output as template.min.css inside your child template’s css folder. Joomla loads the child’s copy first. Replacing media/vendor/bootstrap does nothing for Cassiopeia because Bootstrap is compiled into template.min.css.

Does Cassiopeia work in all browsers?

It works in the browsers Joomla supports. Use it as the control. If Cassiopeia is fine and your template is not, fix or replace the template.

Who can fix a template that only fails in one browser?

Infyways traces the console error and upgrades templates that cannot be patched. Request a Joomla upgrade audit.