Category: Joomla

Joomla still has a future in 2026 if you need a native multilingual, ACL-heavy, or custom CMS, not a blog starter. The project is 21 years old. Joomla 6.1.3 is the current 6.x line. Joomla 5.4.8 is still supported. Market share is small next to WordPress. The architecture is not.

A friend still asks the same two questions I hear every year: do people still use Joomla, and why would anyone pick it when WordPress and Shopify dominate? Those questions are fair. The 2025 answers are not. This is the 2026 version.

I have built on Joomla since the Mambo days. At Infyways we still ship Joomla work and extensions. If the CMS had no future, we would have stopped. We have not.

What you will learn

• Where Joomla stands in 2026: versions, support dates, and market share
• Why people still choose Joomla over WordPress for complex sites
• What Joomla 6 actually changed after the 14 October 2025 launch
• Who should pick Joomla now, and who should not

Joomla in 2026: the facts, not the nostalgia

Joomla launched from the 17 August 2005 Mambo fork. It turned 21 on 17 August 2026. That history is in our separate piece on Joomla at 21. This article is about whether the CMS still deserves a new build this year.

According to W3Techs, Joomla powers about 1.2% of all websites and roughly 1.7% of sites with a known CMS. WordPress is in a different league on those charts. Popularity is not the same as fit.

Signal (August 2026)	What it means
Current 6.x	Joomla 6.1.3 (series started 14 October 2025)
Current 5.x	Joomla 5.4.8, bugfix only
5.x regular support ends	13 October 2026
5.x security-only ends	12 October 2027
6.x regular support ends	17 October 2028
6.x security-only ends	16 October 2029
Next minor on the calendar	Joomla 6.2.0 aimed at 13 October 2026

Those dates come from the official Joomla roadmap (updated 18 August 2026). If you are still on 5.x, the clock to move toward 6.x is real. If you are on 6.1.3, you have a supported major line into the late 2020s.

Why people still use Joomla

Not because it wins the blog market. Because a few core jobs are still easier in Joomla than in a plugin pile.

Native multilingual

Joomla still ships multilingual in core. If you run a government, university, or multi-country site, that is not a nice extra. It is the product.

ACL and structured content

Granular permissions, Custom Fields, and template overrides let you build portals and membership systems without bolting on half a store of plugins. That is why agencies still recommend Joomla for permission-heavy builds.

Security that lives in core

Joomla is not magic. You still patch. The difference is how much you outsource to third-party plugins. We cover that trade in Joomla security in 2026. Core updates and a smaller essential-plugin surface still matter.

No corporate owner

Joomla is still community-run. There is no single vendor who can flip the license. For public-sector and long-lived intranet work, that governance is a feature.

What is new in Joomla 6

Stop treating Joomla 5.0 (October 2023) as the news. That was two major lines ago.

On 14 October 2025 the project shipped Joomla 6.0 and Joomla 5.4 together. 5.4 is the bridge. 6.x is the current major line, with automatic core updates and a Backward Compatibility 6 plugin so upgrades are less of a cliff.

Joomla 6.1 (April 2026) added items such as POW-captcha, a graphical workflow editor, and new media custom fields for audio, video, and documents. 6.1.3 landed on 18 August 2026. 6.2 is scheduled for 13 October 2026.

If your mental model of Joomla is still “hard upgrades and a dusty admin,” you are describing 3.x to 4.x scars, not the 5.4 to 6.x path.

Who should choose Joomla in 2026

Choose Joomla when	Choose something else when
You need native multilingual and deep ACL	You need the fastest possible brochure blog
The site is a portal, membership, or public-sector system	The whole business is a Shopify-style storefront
Developers will own the template and components	You only want a page builder and a theme shop
You can stay on supported 6.x (or finish a 5.x to 6 plan)	The site is abandoned on Joomla 3 with no budget to upgrade

WordPress and Shopify are the right tools for a lot of work. Joomla is the right tool when the CMS has to behave like an application, not a newsletter.

If you need that kind of build, see our Joomla development and Joomla support and maintenance work. For content that has to show up in AI answers, pair the CMS with GEO for Joomla.

Bright or bleak: Joomla’s next years

Bleak if you only watch share of all websites. Bright if you watch whether 6.x is maintainable. Automatic core updates and a dated support window through 2028 and 2029 are the confidence signal the last decade was missing.

What still has to improve is the same list as before, just more urgent: easier onboarding, healthier extension businesses, and clearer marketing for the project types Joomla actually wins. The community does not need to become WordPress. It needs more developers who stay.

Key takeaways

1. Joomla in 2026 is Joomla 6.1.3, with 5.4.8 still on a closing support clock.
2. Small market share does not cancel native multilingual, ACL, and core security posture.
3. Joomla 5.4 to 6.x is a different upgrade story than the painful 3 to 4 years.
4. Pick Joomla for complex, multilingual, permission-heavy sites. Pick WordPress or Shopify when those products fit better.
5. The future is real for teams that will stay on supported 6.x and keep investing in extensions.

Frequently asked questions

Does Joomla have a future in 2026?

Yes, as a specialist CMS for multilingual, ACL-heavy, and custom sites. It will not overtake WordPress on raw market share. It does not need to.

What is the current Joomla version in 2026?

Joomla 6.1.3 on the 6.x line, and Joomla 5.4.8 if you are still on 5.x. 5.x regular bugfix support ends 13 October 2026. Plan the move to 6.x.

Is Joomla still worth using instead of WordPress?

Use Joomla when you need core multilingual, deep permissions, and a flexible architecture. Use WordPress when publishing speed and the plugin/theme market matter more than those native tools.

Should I start a new site on Joomla 5 or Joomla 6?

Start on Joomla 6 unless an extension forces a short stay on 5.4. New projects should not begin on a line that leaves regular support in October 2026.

Did Joomla die after WordPress took the market?

No. It lost the mass-blog market. It kept the niches where core ACL and multilingual still beat a plugin stack. That is a smaller future, not a dead one.

Conclusion

Joomla in 2026 is not the 2015 story and not the 2023 Joomla 5 launch story. It is a 21-year-old CMS on a 6.x line with a published support calendar. If your next site needs that kind of control, it still deserves a serious look. If you only need a theme and a checkout, pick the tool that already won that job.

Most people who want a Joomla helpdesk install osTicket next to Joomla and call it done. That is the mistake.

A Joomla helpdesk is a support ticket system that runs inside Joomla. Customers open and track tickets on your domain, with your users and ACL. osTicket is good software, and it is still a second PHP app. If you want an osTicket alternative for Joomla, that split is the whole decision.

A native Joomla helpdesk lives in the same site as your customers. osTicket sits beside it as another application.

I built Easy Helpdesk at Infyways after watching buyers log into Joomla, then get sent to another hostname to attach a screenshot. You do not need another case study. You have lived that ticket.

As of August 2026, Easy Helpdesk 1.0.31 is built for Joomla 5 and Joomla 6. It is on the JED and documented on JoomlaX.

What you will learn

• Why “osTicket plus Joomla” is not a Joomla helpdesk
• How a real Joomla support ticket should use your existing logins
• When osTicket is still the smarter call
• How to choose without reading a feature brochure

Why people install osTicket instead of a Joomla helpdesk

They need support tickets. They type Joomla helpdesk or Joomla support ticket into Google.

Then they install the first famous name they know.

osTicket shows up because it is free, old, and everywhere. Custom forms. Filters. SLA plans. A client portal. A knowledge base. All of that is real. Check the osTicket feature list if you want the source.

But wait.

osTicket is a separate PHP app with its own database and its own staff logins. Joomla already has PHP, MySQL, users, ACL, and a template.

So you now patch two stacks, brand two portals, and give the customer two “accounts.” That is the cost. Not the osTicket license. The community edition is free.

If you already run Joomla support and maintenance as a long-term site, a second helpdesk stack is extra work you will still be paying for in two years.

What a Joomla helpdesk actually is

A Joomla helpdesk installs as a Joomla package. Your visitor opens a support ticket in Joomla, tracks it on your domain, and an agent works the queue from a Joomla menu, not from a foreign admin skin on another subdomain.

If the desk does not use Joomla users, Joomla menus, and Joomla updates, it is not a Joomla ticketing system. It is a neighbour.

One stack means one login story. Two stacks means you patch Joomla and osTicket as separate products.

Easy Helpdesk is the native example I ship: portal, staff console, mail intake, SLA, knowledge base, reports. I am not going to paste the spec sheet here. You can open the JED or JoomlaX page if you want every toggle.

This is the same native-vs-bolted-on choice we keep making across the Joomla stack in 2026. Keep the product on the CMS when the CMS is the business.

Why this matters for your support tickets

Joomla is already the product. Support is part of that product.

When you bolt osTicket on the side, you teach customers that help is “over there.” They already have a Joomla login. They will not create another one for a screenshot.

Here’s why this matters.

A native Joomla support ticket reuses the session they have. Guests can still open a ticket without an account if you allow it, then come back by email link or ticket number. Agents can work the queue on the frontend so they are not living in /administrator all day.

osTicket can look fine. It still does not become Joomla unless you pay for glue you will own forever. Teams that already do custom Joomla development feel that glue as soon as ACL and membership collide.

5 checks before you pick an osTicket alternative for Joomla

Use this as a buying filter. Not a slogan.

1. Where does the ticket live?
On your Joomla domain, or on support.somethingelse?

2. Who owns the user?
Joomla groups and ACL, or a second staff table?

3. How does email arrive?
Inside the same site’s scheduled tasks, or a mailbox only the other app understands?

4. Can agents work without the Joomla admin?
If the answer is no, your helpdesk will become a bottleneck.

5. Do you need one desk for every CMS?
If yes, stop. osTicket (or another standalone) is the honest fit.

If no, you want a native Joomla helpdesk.

Joomla helpdesk vs osTicket (the only table you need)

Question	Native Joomla helpdesk	osTicket
What did you install?	A Joomla package	A second PHP app
Where does the customer sit?	Your site	osTicket’s portal
Logins	Joomla users	osTicket users
Knowledge base	Can sit in the Joomla workflow	Separate KB
Best for	Support tickets on one Joomla site	One queue for many platforms

Bottom line: stay native if Joomla is the business. Stay on osTicket if the business is bigger than Joomla.

When you should still use osTicket

Do not force the alternative.

Use osTicket if you already trained a global team on it.

Use osTicket if WordPress, Shopify, and Joomla must share one queue.

Use osTicket if you want a free, CMS-agnostic core and you will treat hosting and upgrades as a second product.

Do not pick osTicket because it “sounds more enterprise.” A native Joomla desk can still do departments, SLA, canned replies, private notes, and ratings. The architecture is the differentiator. Not a vibe.

The money question, without the pitch

osTicket’s code is free.

A native Joomla helpdesk is usually a paid extension because someone has to keep it on Joomla 5 and 6.

You still pay for osTicket. You pay in extra server, extra logins, and tickets that never get filed.

That is the trade. Pick it with your eyes open.

Key takeaways

1. A Joomla helpdesk runs on Joomla. osTicket runs beside it.
2. Joomla support tickets should use your domain, your users, and your updates.
3. Easy Helpdesk 1.0.31 (August 2026) is one osTicket alternative for Joomla 5 and 6. It is not the only possible native desk. It is the one built for this exact gap.
4. Multi-CMS support still belongs on a standalone tool.
5. Choose the architecture first. Then choose the product.

Frequently asked questions

Is Easy Helpdesk an osTicket alternative for Joomla?

Yes, if your support is Joomla-only. You get queues, email, SLA, and a knowledge base without a second user database. No, if one desk must cover several platforms.

What is the difference between a Joomla helpdesk and osTicket?

A Joomla helpdesk is an extension. osTicket is its own application. Same job on paper. Different home in production.

How should a Joomla support ticket work for the customer?

They submit on your site. They track it on your site. They do not create a second password unless you force that on purpose.

Can I just embed osTicket in Joomla?

You can iframe almost anything. You still have two apps to patch, two UIs to brand, and two identity models. That is a workaround, not a Joomla ticketing system.

Do I need Joomla administrator access to answer tickets?

You should not. Daily work belongs on a frontend staff queue. Admin is for setup and reports.

Is there a free osTicket alternative for Joomla?

osTicket is free, and it is not a Joomla extension. Native Joomla helpdesks are usually paid. You are buying the integration, not a slogan.

Conclusion

You have two honest options.

Run a Joomla helpdesk so a support ticket in Joomla stays on the site you already maintain.

Or run osTicket because you need a desk that does not care which CMS is in front.

Do not mix those goals and hope the customer will not notice.

If native is the call, look at how Easy Helpdesk is put together on JoomlaX and the JED listing. Then decide. Now it is your turn: pick the architecture this week, before you install another stack you did not need.

Joomla turns 21 today, 17 August 2026. Twenty-one years after the Mambo fork on 17 August 2005, it is still a production-ready open-source CMS for multilingual, ACL-heavy, and enterprise-style websites. Market share is smaller than WordPress. The next chapter depends on developer confidence, smoother upgrades, and core strengths that still outpace many competitors.

I have used Joomla since the Mambo days. At Infyways we still ship Joomla extensions used worldwide. Looking only at market share, it is easy to say Joomla lost. Looking at architecture, security, and real project fit, that conclusion is incomplete. Today is a birthday, not a eulogy.

What you will learn

• Why 17 August 2026 is Joomla’s 21st birthday, and how the 2005 fork actually started
• Why Joomla’s decline was mostly confidence and migration friction, not weak technology
• Which core capabilities still make Joomla a strong CMS choice in 2026
• Where Joomla 5.4.x and 6.x stand on the current roadmap
• When to choose Joomla instead of trying to copy WordPress

17 August 2026: Joomla is 21

The date is not marketing copy. The Joomla project and the official 20 Years of Joomla timeline put the start of the story on 17 August 2005: a fork of Mambo so the CMS would stay truly open source. The name Joomla (from the Swahili jumla, “all together”) was announced on 1 September 2005. Joomla 1.0 shipped on 22 September 2005.

That makes today, 17 August 2026, twenty-one years of a volunteer-run CMS with no corporate owner. Last year’s 20th birthday week is documented in the Joomla Community Magazine. Year 21 is quieter, which is fine. The work is in releases, not merch shops.

Date	Milestone
17 August 2005	Mambo fork. The project that became Joomla begins.
1 September 2005	The name Joomla is announced.
22 September 2005	Joomla 1.0 ships.
17 August 2025	Official 20th anniversary.
14 October 2025	Joomla 6.0 and Joomla 5.4 ship together.
17 August 2026	Joomla turns 21.
18 August 2026	Planned Joomla 5.4.8 and 6.1.3 on the project roadmap.
21 to 22 August 2026	Global Pizza, Bugs and Fun contributor event.

Joomla market share vs WordPress in 2026

According to W3Techs, Joomla currently powers about 1.2% of all websites and roughly 1.7% of sites that use a known CMS. WordPress powers over 43% of all websites and nearly 62% of the CMS market.

Signal	Joomla	WordPress
Share of all websites	~1.2%	~43%+
Share of known CMS market	~1.7%	~62%
Core multilingual	Native	Usually plugin-based
Granular ACL	Built into core	Often plugin-dependent
Best-fit use cases	Complex, multilingual, permission-heavy sites	Publishing speed and mass adoption

Bottom line: market share measures popularity. It does not measure whether Joomla is still the better tool for a university portal, government site, membership platform, or multi-language enterprise build.

Joomla never lost because of technology

The most common misconception is that Joomla declined because it could not keep up technically. I disagree. Modern Joomla is one of the strongest releases the project has ever shipped.

• Native multilingual support
• Enterprise-grade Access Control Lists (ACL)
• Custom Fields for structured content entities
• Template overrides for full front-end control
• Web Services / API endpoints for headless and hybrid builds
• Modern PHP architecture, cleaner code, and a strong security posture

Many of these capabilities existed in Joomla before they became table stakes elsewhere. Technology was never the core weakness.

The real challenge was confidence

The harder problem was investment confidence. Major releases modernized the platform, but they also created painful migrations, broken extensions, template rewrites, and changing APIs.

Businesses delayed upgrades. Developers spent months on compatibility instead of new products. Agencies hesitated before recommending Joomla for long-term roadmaps. Some extension authors moved ecosystems or stopped shipping altogether.

That uncertainty, not a lack of features, slowed Joomla’s commercial momentum.

The biggest loss was developers, not just users

A CMS is only as strong as the ecosystem around it: extension developers, template creators, agencies, hosts, educators, and community contributors. When developers stop building, users eventually stop arriving. That developer attrition was Joomla’s deepest challenge over the last decade.

What Joomla still gets right in 2026

Joomla still wins on flexibility, security, scalability, and developer freedom. Unlike platforms that outsource essential capability to plugins, Joomla keeps many advanced features in core.

• Multilingual: still among the best native CMS implementations
• Permissions: ACL depth most competitors still struggle to match cleanly
• Architecture: enough freedom to build complex applications, not only brochure sites
• Trust: a long security track record with businesses, education, and public-sector projects
• Governance: still community-run. No venture owner can flip the license.

As cybersecurity and data ownership become non-negotiable, those strengths matter more, not less. For a practical hardening view, see our Joomla security 2026 guide.

Where Joomla 5.4 and Joomla 6 stand on its 21st birthday

On 14 October 2025, the project released Joomla 6.0 and Joomla 5.4. 5.4 is the bridge. 6.x is the new major line, with automatic core updates and a Backward Compatibility 6 plugin to reduce upgrade risk.

The Joomla roadmap (updated 16 August 2026) is the right snapshot for today:

• Joomla 5.x current: 5.4.7. Bugfix only. Regular bugfix support until 13 October 2026. Security-only until 12 October 2027.
• Joomla 6.x current: 6.1.2. Bugfix support until 17 October 2028. Security-only until 16 October 2029.
• Tomorrow, 18 August 2026: planned 5.4.8 and 6.1.3.
• Joomla 6.2.0 is aimed at 13 October 2026, with Beta 1 listed for 18 August 2026.

This week the community also runs Pizza, Bugs and Fun on 21 to 22 August 2026, a hybrid global event for testing, docs, and patches, including work toward Joomla 6.2. Birthdays are nice. Contributor weekends keep the CMS alive.

Why I still build with Joomla

People ask why I keep investing after two decades. Because the product still solves hard problems well. At Infyways we keep releasing and maintaining Joomla products, and we stay active on the Joomla Extensions Directory. If we did not believe Joomla had a future, we would not keep putting time and capital into that ecosystem.

For teams also optimizing content for AI search answers, pair this CMS strategy with our practical guide to GEO for Joomla.

Joomla does not need to become WordPress

Comparing Joomla only to WordPress misses the point. WordPress won by making publishing extremely simple. Joomla won by giving developers and organizations deep flexibility. That identity should stay.

Instead of chasing raw market share, Joomla should keep improving what already makes it exceptional, while making onboarding, upgrades, and sustainable extension businesses easier.

Key takeaways

1. Joomla is 21 today, 17 August 2026, counting from the 17 August 2005 Mambo fork.
2. Smaller market share does not mean the CMS is obsolete for complex builds.
3. Core multilingual, ACL, Custom Fields, and Web Services remain durable advantages.
4. Joomla 6.1.2 is the current major line. 5.4.x is still supported. 5.4.8 and 6.1.3 are on the calendar for 18 August 2026.
5. Joomla should double down on its identity, not imitate WordPress.

Frequently asked questions

When did Joomla turn 21?

On 17 August 2026. The project began as a Mambo fork on 17 August 2005, was named Joomla on 1 September 2005, and shipped 1.0 on 22 September 2005.

Is Joomla still worth using in 2026?

Yes, when you need native multilingual, deep ACL, structured content, or a flexible architecture for complex sites. It is not always the fastest path for a simple brochure blog, but it remains a strong CMS for demanding projects.

Did Joomla lose to WordPress because of bad technology?

No. Joomla’s harder problem was confidence: migration pain, extension compatibility risk, and uncertain long-term investment signals. The core technology stayed competitive.

What should I run on Joomla’s 21st birthday?

Joomla 6.1.2 on the 6.x line, or 5.4.7 if you are still on 5.x. Watch for 6.1.3 and 5.4.8 around 18 August 2026 on the official roadmap, then plan toward 6.2 later in 2026.

Who should choose Joomla over WordPress?

Teams building multilingual portals, permission-heavy applications, government or education sites, or custom systems that benefit from core ACL and overrides, rather than assembling the same stack from many plugins.

Conclusion

Twenty-one years in, Joomla’s next chapter will not be written by market-share charts alone. It will be written by developers who keep building, businesses that keep investing, and a community that treats security, ownership, and flexibility as first-class product values. I am still building extensions, still contributing on the JED, and still recommending Joomla when it is the right fit, not from nostalgia, but because the platform still has enormous potential.

Happy 21st birthday, Joomla. Here’s to the next 21 years.

Joomla security is strongest when you treat the CMS as a full stack: core access control, server configuration, updates, monitoring, and incident response. Joomla is still one of the most defensible open-source CMS platforms for serious sites because ACL, user groups, and many security controls live in core instead of a pile of plugins. WordPress can be secured too. It usually needs more third-party layers to reach the same baseline.

July and August 2026 proved the other half of that sentence. Popular add-ons such as JCE and SP Page Builder were the main takeover path, not Joomla’s architecture. If your site is already hacked, or you want it hardened without depending on one security extension, that is the work Infyways does: cleanup, hardening, upgrades, and ongoing maintenance.

What you will learn

• Why Joomla’s core security model still compares well with WordPress
• Why infection counts are not the same thing as “WordPress is weaker core”
• How to harden Joomla with hosting, ACL, updates, and process, not only a plugin
• What the July and August 2026 JCE, SP Page Builder, and core CVEs actually mean
• When to call for hack recovery versus a planned security upgrade

Why Joomla is still a strong security CMS versus WordPress

Joomla did not become “insecure” in 2026. The summer CVEs hit extensions that sit on top of Joomla, the same way WordPress incidents cluster in plugins and themes. The difference is how much security you get before you install anything extra.

Security need	Joomla core	Typical WordPress setup
User groups and permissions	Enterprise-style ACL in core (view, create, edit, publish, admin by group)	Simple roles in core; granular ACL usually needs plugins
Admin vs public split	Separate /administrator application, easier to restrict by IP or VPN	Shared front/back patterns; lockdown is plugin or server work
Multilingual and access by language	Native multilingual plus ACL on menus and modules	Usually a plugin stack
Extension surface	Fewer must-have plugins for ACL, multilingual, and routing	Large plugin economy, which is also the main attack surface
Who gets attacked most	Smaller install base, fewer commodity mass exploits	Largest CMS share, so the default target for automated bots

That last row needs an honest citation. In Sucuri’s 2023 Hacked Website and Malware Threat Report, WordPress accounted for 95.5% of CMS infections in their cleanup data. Joomla was 1.7%. Sucuri is clear this tracks popularity and their customer mix, not a lab score of core code. Still, the operational fact remains: WordPress is the default target. Joomla’s smaller, more ACL-heavy footprint is an advantage if you actually maintain it.

The same report found 39.1% of infected CMS apps were outdated, 49.21% had at least one backdoor, and 13.97% had a vulnerable plugin or theme at cleanup. Those numbers are the real lesson. Security is a maintenance system. Joomla gives you better native controls. It does not forgive abandoned page builders.

Secure Joomla without betting everything on one extension

A firewall or “security” extension can help. It is not a substitute for hosting, permissions, and patch discipline. This is the stack we use when a client wants the site secured, not just a new plugin invoice.

Server and PHP

• Current PHP that Joomla 5 or 6 actually supports
• TLS everywhere, SSH keys not shared passwords, isolated hosting accounts
• Disable PHP execution in images, media, and tmp
• Restrict /administrator by IP, VPN, or HTTP auth where the business allows it

Joomla core controls

• MFA on every Super User and Manager
• Least-privilege ACL: editors should not be Super Users
• Global Configuration: strong session settings, HTTPS, sensible error reporting off on live
• Hide unused components, modules, and templates instead of leaving demo code online

Updates as a process

• Core on the current security line (Joomla 5.4.x or 6.1.x in 2026)
• Editors and page builders on a weekly check, not a yearly project
• Staging first for major upgrades, then production
• Off-site backups you have restored at least once

Infyways can run that as a one-off harden, a Joomla upgrade, or ongoing Joomla support and maintenance. If the site is already compromised, start with cleanup, then hardening. A plugin on a backdoored site only hides the problem.

July and August 2026: what actually broke

Use this section as a patch briefing, not as proof that Joomla “lost.” The pattern is familiar: commodity extensions with public endpoints, then automated scanning.

Product	What happened	Safe version
JCE editor	CVE-2026-48907 unauthenticated RCE via profile import, CVSS 10.0, CISA KEV from 16 June 2026	2.9.99.6 or later
SP Page Builder	CVE-2026-48908 unauthenticated takeover (KEV), then July SQLi and mail-relay CVEs, then 12 August file-inclusion RCE	6.8.0 (covers the full summer chain)
Joomla core	12 XSS and access-control fixes on 7 July 2026	5.4.7 or 6.1.2

JCE CVE-2026-48907

JCE is a widely used editor, not Joomla core. CVE-2026-48907 let unauthenticated visitors create profiles and upload PHP. Fixed in 2.9.99.5, with 2.9.99.6 recommended. If this was unpatched on a live site, assume a backdoor until you prove otherwise.

SP Page Builder through 12 August 2026

Do not stop at 6.6.2 or 6.7.1. June’s CVE-2026-48908 was a no-login takeover. 27 July’s 6.7.1 closed unauthenticated SQL injection and a mail-relay issue documented by mySites.guru. 12 August’s 6.8.0 closed CVE-2026-67285 (PHP file inclusion) and CVE-2026-67286 (file write).

Joomla 5.4.7 and 6.1.2

The 7 July 2026 core release patched XSS and incorrect access control in media, contact, MFA, templates, installer, workflow, modules, privacy, and fields webservices. Apply it. It is still a smaller class of risk than unauthenticated editor and page-builder RCE.

If the site is already hacked

Patching a KEV-class RCE after weeks online is not a cleanup. Typical Joomla compromise leftovers are extra Super Users, PHP in tmp or image folders, modified templates, and poisoned .htaccess. Infyways handles that as incident work: isolate, take forensic copies, remove malware, rotate credentials, patch, then harden. See how we repair a hacked Joomla website if you need the recovery path.

What Infyways actually delivers

• Hacked site recovery: malware removal, backdoor hunt, Google Safe Browsing / host blacklist help
• Security hardening: server rules, ACL, MFA, admin lockdown, PHP-in-uploads blocks, backup design
• Extension and core upgrades: JCE, SP Page Builder, and Joomla 5/6 on a staging copy first
• Retainer maintenance: updates, monitoring, and a human response when the next CVE drops

We will install a reputable security extension when it fits. We will not pretend it replaces hosting controls, ACL, or a clean codebase. If you want a quote, use the contact form on this site and tell us whether you need emergency cleanup or a planned harden.

Key takeaways

1. Joomla’s core ACL and admin split still give it a security architecture WordPress usually buys as plugins.
2. Sucuri’s infection mix is mostly WordPress because WordPress is everywhere. Maintenance still decides who gets hacked.
3. Summer 2026 takeovers were JCE and SP Page Builder. Update those, then core.
4. Real Joomla security is server, ACL, updates, backups, and response, not one extension.
5. Hacked sites need cleanup first. Hardening a backdoor in place fails.

Frequently asked questions

Is Joomla more secure than WordPress in 2026?

Joomla’s core ACL, separate administrator app, and smaller install base are genuine advantages. WordPress is attacked more because it is the default CMS. Either platform fails if editors, page builders, or plugins stay unpatched.

Can I secure Joomla without a third-party security extension?

Yes. Start with current PHP and Joomla, MFA, least-privilege ACL, no PHP in upload folders, restricted administrator access, backups, and a patch process. A security extension can add WAF or scanning. It should not be the only control.

What were the main Joomla security issues in July and August 2026?

JCE CVE-2026-48907 (unauthenticated RCE), SP Page Builder’s June to August chain ending in 6.8.0, and Joomla 5.4.7 / 6.1.2 core XSS and access-control fixes from 7 July 2026.

Which SP Page Builder and JCE versions should I run?

JCE 2.9.99.6 or later, and SP Page Builder 6.8.0. Older “almost patched” builds still leave summer 2026 holes open.

We were hacked. Should we migrate to WordPress?

Usually no. Migration does not remove a backdoor and it throws away Joomla ACL you already paid for. Clean the site, patch, harden, then decide. Infyways can do the recovery without forcing a CMS change.

Conclusion

Joomla remains a strong security CMS when you use the controls it already ships: ACL, a real administrator app, and a smaller, more intentional extension set. The July and August 2026 headlines were about unpatched JCE and SP Page Builder, plus a normal core security release. Keep Joomla, patch the stack, and harden the server. If you need that done as a project, from hacked-site cleanup to a maintenance retainer, Infyways is built for that work.

If you’ve tried integrating MailerLite with Joomla, you already know the problem.

There’s no solid, dedicated module.

Most people end up doing one of these:

• Using embed forms from MailerLite
• Writing custom API code
• Installing outdated or unsupported extensions

None of these feel right.

Embeds look out of place.
Custom code takes time.
And exposing API keys in the browser is risky.

So I built a proper solution.

👉 https://joomlax.com/mailerlite-newsletter.html

A clean, secure, AJAX-based MailerLite newsletter module for Joomla.

The Problem with Existing MailerLite Integrations

Let’s be honest.

Most integrations are not built for real Joomla workflows.

Here’s what usually goes wrong:

• API keys exposed in frontend scripts
• No control over design
• Poor mobile layout
• No proper module positioning
• Hard to maintain across Joomla updates

If you’re running Joomla 4, 5, or planning for 6, this becomes a bigger issue.

You need something native.

Something that works the Joomla way.

---

The Solution: MailerLite Newsletter Module (AJAX-Based)

This module is built specifically for Joomla.

No hacks. No workarounds.

Just install, configure, and publish.

👉 Live Demo: https://demo.joomlax.com/demo/utilities/mailerlite-newsletter
👉 Documentation: https://joomlax.com/documentation/mailerlite-newsletter

---

Why This Module Is Different

1. Your API Key Stays Secure

Most solutions expose your API key in JavaScript.

This one doesn’t.

Everything runs server-side using Joomla’s AJAX system.

• No API key in browser
• No leaks in DevTools
• Clean and secure integration

Your credentials stay where they belong.

On your server.

---

2. Works Like a Native Joomla Module

This is not a plugin hack.

It behaves exactly like a Joomla module:

• Assign to any module position
• Show on selected menu items
• Create multiple instances

Just like you expect.

---

3. Fully Customizable Design

You control everything.

• Heading and intro text
• Button label and icons
• Success and error messages
• Colors, spacing, typography

Horizontal or vertical layout.

It adapts to your design. Not the other way around.

---

4. Built for Modern Joomla (4, 5 & 6)

No legacy code.

No compatibility issues.

This module is designed for current and future Joomla versions.

So you don’t have to worry about migrations later.

---

5. Multilingual Ready

Running a multilingual site?

No problem.

• Create separate modules per language
• Translate content easily
• Use Joomla language files

Works perfectly with standard Joomla workflows.

---

MailerLite Forms vs This Joomla Module

At first glance, you might think:

“MailerLite already gives me a form. Why do I need this?”

Fair question.

Let’s break it down.

MailerLite Embedded Forms

MailerLite’s default forms are:

• JavaScript-based
• Submitted without page reload (AJAX-like)
• Easy to copy and paste

Sounds good.

But here’s where things fall short:

• Runs entirely in the browser
• Limited control over layout inside Joomla
• Styling can clash with your template
• Harder to manage across multiple module positions

It works.

But it doesn’t feel native to Joomla.

---

This Module (Server-Side AJAX Approach)

This module takes a different approach.

• AJAX on the frontend
• Processing handled on the server via Joomla
• API token never exposed
• Full control over design and placement

So you get:

• Better security
• Cleaner integration
• More flexibility

And most importantly…

It behaves like a real Joomla module.

---

Quick Comparison

MailerLite Embed:

• Frontend-driven
• Limited customization
• Not Joomla-native

This Module:

• Server-side secure processing
• Fully customizable
• Built for Joomla workflows

---

The Bottom Line

MailerLite forms are fine for quick setups.

But if you’re building a serious Joomla website…

You need something more controlled.
More secure.
And easier to manage.

That’s exactly what this module delivers.

---

How to Install and Set It Up

This is where things get simple.

Step 1: Download the Module

Go here:
👉 https://joomlax.com/mailerlite-newsletter.html#download

Download the ZIP file.

---

Step 2: Install in Joomla

• Go to System → Install → Extensions
• Upload the ZIP file
• Wait for success message

Done.

---

Step 3: Create the Module

• Go to System → Manage → Site Modules
• Click New
• Select MailerLite Newsletter

Now assign:

• Module position
• Menu items

---

Step 4: Connect MailerLite

You’ll need two things.

API Token:

• Go to MailerLite dashboard
• Navigate to Integrations → Developer API
• Copy your API token

Group ID:

• Go to Subscribers → Groups
• Open your group
• Copy the numeric ID

Paste both into the module settings.

That’s it.

---

Step 5: Customize the Form

Now make it yours.

• Add heading and description
• Set placeholders
• Update button text
• Style colors and layout

Preview it.

Adjust it.

Publish it.

---

What Happens After Setup

Once live:

• Visitors enter name and email
• Form submits via AJAX
• Data is sent securely to MailerLite
• Subscriber is added to your group

No page reload.

No messy redirects.

Just smooth user experience.

---

Who Is This For

This module is perfect if you:

• Use Joomla and MailerLite
• Want a clean newsletter signup
• Care about security
• Don’t want to write custom code
• Build websites for clients

It’s especially useful for agencies standardizing their workflow.

---

Why I Built This

I couldn’t find a proper solution.

Every project needed the same thing.

A simple and secure MailerLite integration for Joomla.

So instead of repeating the same workaround again and again…

I turned it into a reusable module.

---

Try It Yourself

👉 Product Page: https://joomlax.com/mailerlite-newsletter.html
👉 Demo: https://demo.joomlax.com/demo/utilities/mailerlite-newsletter
👉 Documentation: https://joomlax.com/documentation/mailerlite-newsletter
👉 MailerLite Newsletter Joomla Extensions Directory – https://extensions.joomla.org/extension/login-popup-pro/

---

Final Thoughts

MailerLite is powerful.

Joomla is powerful.

But without the right bridge, things get messy.

This module fixes that.

Simple setup.
Secure integration.
Clean design.

That’s how it should have been from the start.

If you upgraded from Joomla 3, you’ve probably run into this issue.

Your login popup stopped working.

No warning.
No support.
No clear replacement.

And suddenly, your website’s login experience is broken.

Let’s fix that.

What Happened to Login Popup by ExtStore?

The popular extension Login Popup by ExtStore was widely used across Joomla 3 websites.

It helped you:

• Show login forms in a popup
• Improve user experience
• Avoid redirecting users to a separate login page

But now, it’s no longer available.

The listing on the Joomla Extensions Directory has been unpublished.

Reason: PE1 error and no ongoing support.

Most importantly, it does not support Joomla 4, 5, or 6.

Why This Became a Big Problem

When users migrated to newer Joomla versions, things broke.

Here’s what started happening:

• Login popup stopped appearing
• JavaScript errors showed up
• CSS conflicts with templates
• Some sites even displayed blank pages

And there was no proper alternative that behaved the same way.

The Real Reason It Broke

This is not just about compatibility.

Joomla 4 and above introduced major changes:

• Namespaced PHP
• Modern APIs
• New extension architecture
• Different asset handling

Old extensions built for Joomla 3 cannot work without a full rewrite.

That’s exactly what happened here.

My Experience Fixing This

I’ve migrated multiple Joomla websites using this plugin.

Every time, the same issue came up.

Clients wanted the same popup login experience.

But no extension could match it properly.

So instead of trying to patch outdated code, I rebuilt it from scratch.

Introducing Login Popup Pro

Here’s the solution:

Login Popup Pro

This is not just an update.

It’s a complete rewrite built specifically for Joomla 4, 5, and 6.

And it keeps everything users loved about the original plugin.

Try the Live Demo

See it in action:

https://demo.joomlax.com/demo/popup-and-iframes/login-popup-pro

What Makes Login Popup Pro Better?

Built for Modern Joomla

No hacks or legacy code.

It uses:

• CMSPlugin architecture
• Factory, LayoutHelper, HTMLHelper
• Namespaced structure

This makes it faster, cleaner, and more stable.

Clean Asset Structure

No more dependency issues.

All assets are properly organized:

• CSS
• JavaScript
• Images

Everything is loaded cleanly without conflicts.

Full Appearance Control

No need for custom CSS.

You can control:

• Colors
• Shadows
• Border radius
• Popup width
• Overlay styling

All through simple settings.

Improved User Experience

Small features that make a big difference:

• Auto-open with URL hash like #login or #logout
• ESC key to close popup
• Click outside to close
• Flexible placement for registration links

Scoped and Conflict-Free Code

Everything is properly namespaced:

• CSS classes use jx-lp-*
• JavaScript uses Jx.LoginPopup
• Language keys are isolated

This avoids conflicts with templates and other extensions.

Proper Documentation

Everything is clearly documented.

You get:

• Structured feature files
• Detailed documentation
• Easy setup instructions

Documentation link: https://joomlax.com/documentation/login-popup-pro

Important Links

Product Page
https://joomlax.com/login-popup-pro.html

Download
https://joomlax.com/login-popup-pro.html#download

Documentation
https://joomlax.com/documentation/login-popup-pro

Demo
https://demo.joomlax.com/demo/popup-and-iframes/login-popup-pro

Why Not Use Other Alternatives?

You might find a few plugins out there.

But most of them:

• Don’t match the original behavior
• Have limited customization
• Break in newer Joomla versions
• Are not actively maintained

This solution was built specifically for real migration issues.

Who Should Use This?

This is for you if:

• You upgraded from Joomla 3
• You used ExtStore Login Popup
• You want the same experience back
• You want more flexibility and control

Final Thoughts

Extensions may stop working.

But your website doesn’t have to.

If your login popup broke after upgrading Joomla, you now have a proper fix.

A modern, stable, and feature-rich replacement built for today’s Joomla.

The Problem: Static Website with No CMS

A client had a clean, fast static website.

Everything looked good.

But there was one missing piece.

They needed a blog.

Not just a simple page. A proper system where they could:

• Log in securely
• Add new articles
• Manage categories
• Update content anytime

Building a CMS from scratch would take time.

And honestly, it didn’t make sense.

So I looked for a smarter approach.

The Idea: Use Joomla as a Headless CMS

Instead of building something new, I used Joomla as the backend.

No frontend.

No templates.

Just content management.

Then I connected it to Next.js.

This gave me:

• A ready-to-use admin panel
• Secure authentication
• API access to content
• A fast frontend

The result was simple and powerful.

Final Architecture

Here’s what I built:

• Main website → clientsite.com using Next.js
• Blog section → /blog (dynamic)
• Joomla backend → joomla.clientsite.com

Joomla handles:

• Content creation
• Content storage
• API responses

Next.js handles:

• UI
• Routing
• Rendering

This separation makes everything cleaner.

Step 1: Install Joomla 6 on a Subdomain

Create a subdomain like:

• joomla.clientsite.com
• or api.clientsite.com

Install a clean Joomla 6 setup.

Then simplify it:

• Disable frontend modules
• Ignore templates
• Use it only for managing content

Think of it as a backend dashboard, not a website.

Step 2: Enable Joomla Web Services API

Joomla 4+ comes with built-in Web Services.

Go to Plugins and enable:

• Web Services – Content
• API Authentication

Once enabled, your API is live.

Example endpoint:

https://joomla.clientsite.com/api/index.php/v1/content/articles

Step 3: Generate Authentication Token

Joomla supports token-based authentication.

Steps:

• Go to Users
• Open your user profile
• Generate API token

Now every API request can be secured.

Example header:

Authorization: Bearer YOUR_API_TOKEN

Step 4: Fetch Articles from Joomla API

Use the API to fetch content.

Example request:

GET https://joomla.clientsite.com/api/index.php/v1/content/articles

The response includes:

• Title
• Slug
• Content
• Categories
• Metadata

Everything needed to render a blog.

Step 5: Connect Next.js 16 (App Router)

In Next.js, I used App Router with native fetch.

Here’s a simple example:

export async function getArticles() {
  const res = await fetch(
    "https://joomla.clientsite.com/api/index.php/v1/content/articles",
    {
      headers: {
        Authorization: "Bearer YOUR_API_TOKEN",
      },
      cache: "no-store",
    }
  );

  if (!res.ok) {
    throw new Error("Failed to fetch articles");
  }

  return res.json();
}

This pulls data directly from Joomla.

Step 6: Render Blog Page

Now create your blog listing page:

export default async function BlogPage() {
  const data = await getArticles();

  return (
    <div>
      {data.data.map((article) => (
        <div key={article.id}>
          <h2>{article.attributes.title}</h2>
        </div>
      ))}
    </div>
  );
}

Clean and simple.

Step 7: Create Dynamic Blog Pages

Use slugs from Joomla.

export async function generateStaticParams() {
  const data = await getArticles();

  return data.data.map((article) => ({
    slug: article.attributes.alias,
  }));
}

Now each article becomes:

/blog/my-article-slug

Fully dynamic.

Important: Avoid Duplicate Content

This step is critical.

Your Joomla backend is public.

So the same content exists in two places:

• Joomla URLs
• Next.js blog pages

This creates duplicate content.

Fix it:

Go to Joomla Global Configuration and set:

• Robots → noindex

This ensures only your Next.js site gets indexed.

Why I Didn’t Use WordPress

You might ask:

Why not use WordPress?

It has an API:

/wp-json/wp/v2/posts

And yes, it works.

But here’s the reality.

How WordPress Works in Headless Mode

By default:

• API is public
• No authentication required
• Anyone can access your content

Example:

https://example.com/wp-json/wp/v2/posts

You get everything instantly.

The Limitations

Authentication is not strict by default

To secure it, you need:

• Application passwords
• JWT plugins
• OAuth setups

This adds complexity.

Plugin dependency

For real projects, you often need:

• ACF for custom fields
• Authentication plugins
• API extensions

More plugins means:

• More maintenance
• More risks

Less control over API behavior

Customizing APIs requires:

• Hooks
• Filters
• Custom coding

It’s flexible, but not clean.

Larger attack surface

Because of its popularity:

• More bots target it
• Plugin vulnerabilities are common
• APIs are often exposed

Why Joomla Worked Better

With Joomla, things were straightforward.

• API is structured
• Authentication is built-in
• No extra plugins needed
• Better control over access

It gave me:

• A secure backend
• Clean API integration
• Less maintenance

Performance Benefits

This setup is fast.

Because:

• Main site is static
• Blog is dynamic only where needed
• API calls are lightweight

This improves:

• Load speed
• SEO
• User experience

Pros of Using Joomla as Headless CMS

• No need to build CMS
• Secure admin panel
• Built-in API
• Easy for clients
• Works well with modern frameworks
• Scalable

Cons You Should Know

• Requires initial setup understanding
• API is less beginner-friendly
• Token handling required
• Joomla UI may feel heavy for small tasks

When You Should Use This Approach

Use it when:

• You have a static site
• You need dynamic blog content
• You want a secure backend
• You want to save development time

Avoid it when:

• You need full CMS-driven frontend
• You want everything in one system

Final Thoughts

This setup worked perfectly.

The client got:

• A fast website
• A simple backend
• Full control over content

And I avoided building a CMS from scratch.

Sometimes the smartest solution is not building more.

It’s choosing better tools.

If you’re working with Next.js and need a CMS, give Joomla headless a try.

If K2 is holding back a Joomla upgrade, this is the exact problem most site owners face.

K2 worked great for years.
But it doesn’t support newer Joomla versions.

That means one thing.

You’re stuck.

Stuck on Joomla 3.
Stuck with outdated code.
Stuck risking security and performance issues.

And if your site has hundreds or thousands of K2 articles, migration feels impossible.

Let’s fix that.

What Happened to K2 in Joomla 4, 5, and 6

K2 was once the go-to CCK for Joomla.

But development slowed down.
And eventually, it stopped keeping up with Joomla’s core changes.

Joomla 4 introduced a new architecture.
Joomla 5 improved it further.
Joomla 6 continues that direction.

K2 never fully adapted.

Result:

• K2 doesn’t work properly in Joomla 4, 5, or 6
• No official long-term support
• Compatibility issues with modern extensions

So upgrading without a plan breaks your site.

Why K2 Users Are Stuck on Joomla 3

Most websites using K2 are content-heavy.

We’re talking:

• Blogs with 1000+ articles
• News portals
• Directory-style websites
• Custom content built using extra fields

Migrating this manually is not simple.

You’re not just moving articles.

You’re dealing with:

• Categories
• Extra fields
• Images
• Tags
• Metadata

One mistake can break structure or SEO.

That’s why many users delay upgrading.

The Real Problem with Migrating K2 Content

Thousands of Articles and Data Complexity

The more content, the harder it gets.

Manual export and import isn’t practical at scale.

Loss of Extra Fields and Media

K2 relies heavily on extra fields.

If those don’t migrate correctly, content loses meaning.

Images and attachments are another challenge.

Manual Migration Is Time-Consuming

Even for developers, this can take days or weeks.

And still not be perfect.

What Are Your Options If You Still Use K2

Stay on Joomla 3 (Not Recommended)

This is risky.

• No long-term security updates
• Outdated PHP compatibility
• Increasing vulnerability

Manual Migration (Risky and Slow)

Possible, but:

• Time-consuming
• Error-prone
• Requires deep technical knowledge

Use an Automated Migration Tool

This is the practical approach.

Fast.
Accurate.
Scalable.

The Easiest Fix: One-Click K2 Migration with JoomlaX

This is where things change.

Migrate K2 Pro is built specifically to solve this problem.

Instead of manually rebuilding your site, you can migrate everything in a few clicks.

You can check the product here:
https://joomlax.com/migrate-k2-pro.html

And full documentation here:
https://joomlax.com/documentation/migrate-k2-pro

What Is Migrate K2 Pro

It’s a Joomla extension that converts K2 content into Joomla core content.

No complex setup.
No custom scripts.

Just install and run.

Key Features That Make Migration Easy

• One-click migration process
• Converts K2 items into Joomla articles
• Maps extra fields to Joomla custom fields
• Migrates images and media correctly
• Preserves categories, tags, and metadata

How It Saves Time and Effort

What normally takes weeks can be done in minutes.

No manual copying.
No data loss risks.
No guesswork.

Step-by-Step: How to Migrate K2 to Joomla 5

Here’s the simplified process.

Step 1: Install the Migration Component

Download from:
https://joomlax.com/migrate-k2-pro.html

Install it like any Joomla extension.

Step 2: Configure Basic Settings

Set:

• Source (K2 data)
• Target (Joomla articles)
• Field mappings

Step 3: Start One-Click Migration

Click migrate.

The tool handles:

• Articles
• Categories
• Fields
• Media

Step 4: Verify Migrated Content

Check:

• Article structure
• Images
• Custom fields

Everything should be intact.

What Gets Migrated Automatically

Articles and Categories

All K2 items become Joomla articles.
Category structure is preserved.

Extra Fields to Custom Fields

K2 extra fields are mapped to Joomla custom fields.

No data loss.

Images and Media

Images, attachments, and media are transferred correctly.

Tags and Metadata

SEO data remains intact.

Who Should Use This Tool

This tool is perfect if:

• Your site has 100+ K2 articles
• You want to upgrade to Joomla 5 or 6
• You want a fast and safe migration
• You don’t want to rebuild everything manually

Prefer a Done-for-You Service?

Not everyone wants to handle migration.

That’s completely fine.

If you want experts to handle everything, check:

Infyways Joomla K2 Migration Services
https://www.infyways.com/joomla-k2-migration-services/

You get:

• Complete migration handled by experts
• Zero downtime approach
• Data accuracy checks
• Post-migration support

Common Questions About K2 Migration

Will I lose my data?

No.
If done correctly or using the right tool, everything is preserved.

Can I migrate a large website?

Yes.
The tool is designed for large datasets.

Does it support Joomla 5 and 6?

Yes.
That’s the whole point.

Do I need coding knowledge?

No.
The tool is built for non-developers as well.

Final Thoughts

K2 served Joomla users well.

But it’s no longer future-proof.

Staying on Joomla 3 is not a long-term solution.

The smart move is simple.

Migrate.

And do it the easy way.

Use a tool that saves time, protects data, and removes complexity.

Or let experts handle it for you.

Either way, upgrading is no longer a problem.