There is a particular moment — I recognise it the instant it begins — when someone describes what they want from their website and I try not to blink. Not from professional coldness.
I am not the sort who looks down at clients from behind a parapet of technical superiority, confusing that posture with actual competence. I try not to blink because something in me reaches instinctively towards the person sitting across from me, and that instinct insists on patience. Because the person is not lying. They are not exaggerating for effect. They are not attempting to deceive me or themselves. They simply believe. They believe, with a disarming sincerity, that somewhere in the vast universe of plugins and modules and extensions and Joomla versions, a solution already exists that does everything. A solution that thinks on their behalf, optimises without being asked, translates without misreading the nuance, protects without needing to be told why, sells without requiring the owner to understand the economics of selling. A solution that, if asked politely enough, would probably also make the coffee.
I have been working in web development for eight years. I have built websites for local councils and hospitals in Botoșani County, for schools only just discovering they needed an online presence, for private firms dreaming large on modest budgets, for entrepreneurs who confused enthusiasm with feasibility. I have seen requests of every conceivable variety. I have delivered projects I am proud of and a handful I would approach quite differently now. And throughout all of it, the most consistent thread running through the work has not been PHP, has not been PSR-4 architecture, has not even been Joomla in any of its versions. It has been the distance — sometimes enormous, always revealing — between what users believe technology can do and what it actually does.
I am writing this not to scold anyone. Not because users are less intelligent or less capable than those who build. I am writing it because I recognise myself in that same naivety whenever I wander into territory I have not properly studied. And because understanding this gap — with humility, without exasperation — is, in itself, the first movement towards genuine digital maturity.
"I want a chatbot that can answer any question about my site"
My father was a mechanic his entire working life. He knew nothing about writing code, but he knew something considerably more valuable: he knew that any broken machine is repaired piece by piece, that no single turn of a spanner resolves everything at once, that any promise made too beautifully conceals either a lie or an ignorance. He would tell me sometimes, wiping his hands on an old cotton rag, with a calm I have never quite managed to replicate: "If someone tells you it's easy, it means they haven't understood what needs fixing."
The AI chatbot is, today, the thing that is supposed to be easy in the imagination of users. They request, with complete seriousness, a chat module that will answer absolutely any question about the site — content, services, features, prices, internal policies, exceptions, company history — without prior training, without configuration, without any additional cost beyond the hosting they are already paying for.
The reality is less romantic and, I find, considerably more interesting. A functional chatbot requires structured content to be made accessible to it — vectorisation, embeddings, semantic mapping — none of which happens by itself and none of which is inexpensive. It has context limits: a token window beyond which it simply forgets what it has read. It has API latencies that fluctuate with traffic. It has monthly costs that rise in proportion to the volume of interactions. There is no magic behind the chatbot — there is preparatory work that the user perceives as a minor technical detail and that the developer knows represents at least half the entire project.
The expectation is legitimate at its core — who would not want a digital assistant available round the clock, one that never tires and never has a difficult morning? The distortion arrives the moment that legitimate desire becomes a demand that everything must function immediately, perfectly, without effort from anyone and without costing a penny more than it already does.
"I want a search engine that understands me, like Google"
I stop working sometimes and think — with a curiosity that strikes me as healthy, though my son would call it an obsession — about how we have arrived at the collective conviction that Google, a company employing tens of thousands of engineers, operating data centres across multiple continents, and investing billions annually in research, has created something that a €49 plugin can reproduce on a shared hosting account costing a few pounds a month. This is not irony. It is a genuine question about how perception functions in the digital world.
Semantic search is a function of remarkable complexity. It involves language models trained on enormous corpora of text, real-time NLP processing, vector databases capable of comparing meanings rather than merely matching strings, continuous indexing and re-indexing with every content change. It demands infrastructure that a shared server cannot support, either theoretically or practically. Services such as Pinecone or OpenAI Embeddings make this power accessible, but at a real and ongoing cost, with configuration that requires hours of considered work, with maintenance that does not end at first installation.
What I can realistically build for Joomla is an improved search experience compared with the native one — faster, more relevant, with autocomplete suggestions and category-based filtering. Not Google's semantic search. And this distinction deserves to be stated plainly, without embarrassment, in the first conversation with the client — not at the end of the project, when the disappointment has already taken hold.
"Tell me which pages to write so I get more traffic"
This is the expectation that amuses and saddens me in equal measure, because it reveals a confusion not merely about what AI can do, but about what SEO actually is at its foundation.
SEO is not a formula with known variables that one solves once and puts aside. It is, at best, a practice grounded in understanding human behaviour — how people search, which words they choose, from what context, with what intention. An AI plugin can generate content ideas, analyse keyword density, suggest article structures and serviceable meta descriptions. But it does not know that your business in a provincial town is competing with a firm in the capital that spends ten times more on content marketing. It does not know that your specific audience uses regional expressions or has a search culture that diverges from the national average. It knows nothing about you, about your customers, about the particular story of your business.
SEO solved automatically by AI is a comfortable utopia. It consoles because it promises results without the slow and sometimes painful work of genuinely understanding who you are, to whom you are speaking, and why anyone ought to read you rather than someone else.
"Give me product recommendations like Amazon does"
My son has a habit — which I value and dread in equal parts, because its precision is consistently disarming — of asking direct questions when he sees me working. He looked at my screen once, where I had a client's email open, and asked me: "Why do people ask for impossible things and then get cross when it doesn't work out?" I had no coherent answer for him then. Now I would say: because they do not see the effort behind the finished thing. They see the "Customers who bought this also bought…" button and it seems straightforward. They do not see the millions of transactions that train the recommendation model, the hundreds of engineers who calibrate it, the distributed infrastructure running it in real time for hundreds of millions of users simultaneously.
Joomla, as a PHP content management system, does not natively have either the architecture or the data required for intelligent real-time recommendations. Simple and genuinely useful recommendations are possible — related articles within the same category, products linked by shared tags, popular content from the same period. That is useful. That is honest. It is not Amazon, and it will not be Amazon on a server costing thirty euros a month, regardless of how many plugins are installed.
"Translate my entire site into ten languages, perfectly"
Automatic translation has advanced enormously. DeepL produces results that a human translator of ten years ago would have found startling. GPT-4 can render a text from one language into another while preserving register and tone with considerable precision. But "enormously" does not mean "perfectly", and "considerable precision" does not mean "without errors that matter".
I have one example I return to frequently in conversations about machine translation: an algorithm can produce a grammatically correct Arabic rendering of an article about hiking in the American outdoors. But it will not know — because it has not been taught and because it has no cultural context — to remove the references to alcohol consumed on a picnic, or to adapt the descriptions of light clothing for a conservative readership. Translation is not transposition of words. It is transposition of meaning, of intention, of cultural context. And cultural intention remains, for now, a territory in which a human being is necessary.
A translation module integrated into Joomla can be an excellent starting point — it dramatically reduces the time required, it produces a usable first draft. It cannot be the final solution without human review, especially on legal, medical, or institutional sites, or anywhere that errors of nuance carry a real cost.
"Generate all my articles so I don't have to write them myself"
This is, very likely, the most frequently requested thing of all, and the most difficult to refuse gracefully — not because it is technically impossible, but because when it happens without any human involvement, it produces something that resembles an article without being one in any meaningful sense.
I have read dozens of articles generated entirely by AI, with no human hand applied afterwards. They are grammatically correct. They follow a recognisable structure. They are empty. What they lack is what I call, without any great philosophical pretension, the author's trace — that quality which makes a piece of writing feel as though it was written by a particular person, from a particular experience, for a particular reader, about something that genuinely mattered to the one who wrote it. Without that trace, the text becomes a product rather than a communication. And readers feel this, even when they cannot name what is absent.
AI can be a genuinely valuable editorial assistant — it can suggest structures, complete technical passages, rephrase clumsy sentences, propose angles that hadn't occurred to you. But if you leave it alone at the keyboard, Google's algorithms will detect the pattern and your readers will sense the absence. Content without a human behind it is content without substance.
The magic-button syndrome: SEO, performance, and security
There are several variants of this syndrome — the conviction that somewhere a single button exists that resolves everything — which recur with an almost melancholy regularity in conversations with Joomla users.
Duplicate URLs are one such variant. The user wants a plugin that identifies every duplicate across the site, decides independently which version ought to be canonical, implements the redirects and corresponding tags, and does all of this without breaking anything and without requiring the user to understand why the duplicates exist in the first place. The difficulty is that duplicate URLs in Joomla can arise from dozens of different sources: menu configurations, URL parameters appended by third-party extensions, custom routers, component-specific settings. A plugin cannot second-guess editorial intention. It can assist with identification and implementation; it cannot decide alone what matters and what does not.
Perfect performance — a score of 100 on Google PageSpeed — is another expression of the magic-button myth. Someone wants that score and believes a plugin will produce it. But a web page's performance depends on the server, the quality of the hosting, the chosen theme, the installed extensions, unoptimised images, embedded video, and code contributed by ten different third-party providers who know nothing of one another. A caching and optimisation plugin can make a real and measurable difference. It cannot compensate for poor hosting, a bloated theme laden with unnecessary CSS, and fifteen active modules on every page.
Complete security is the third recurring myth. Users constantly ask for security modules that will automatically block all hackers, with no configuration, for a budget of a few pounds. The reality is that genuine security is a continuous process: architecture decisions, monitoring, regular updates, fundamental good practices — strong passwords, extensions kept current, correct file permissions, components installed only from trusted sources. A security plugin adds important layers: backend access monitoring, blocking of suspicious IP addresses, email alerts for unusual activity. It cannot substitute for the habit of updating extensions and the discipline of not installing components from unknown sources.
Who actually makes these requests
It is worth pausing to understand who, in practice, formulates these demands. It is not someone poorly informed out of malice. It is, most typically, someone from one of these categories: a freelancer trying to build a client's site quickly without the time to master every technical aspect. A small business owner trying to market their enterprise on limited resources, with no means of knowing what things genuinely cost. A designer with clear visual ideas who does not want to write code. A passionate blogger seeking customisation beyond what the default theme provides. All of them share one legitimate common need: to achieve results without being required to become technical experts. And it is precisely this desire — reasonable in essence — that produces demands which sometimes exceed the boundaries of what is possible.
The web industry has contributed to this confusion. We have promised "turnkey solutions" when we were really delivering starting points. We have concealed complexity behind apparently simple interfaces. We have sold "ease of use" when we should have been selling "understanding of the process". It is not the users' fault that they have grown accustomed to asking for the moon. It is partly our fault for having presented it as something within reach.
What is genuinely possible — and worth building
I do not want to leave the impression that everything is impossible or that users ask for foolish things. There is a broad and valuable category of features that are entirely achievable in Joomla and that solve real problems, delivering measurable value.
An intuitive SEF URL configuration system, with real-time preview and presets for common structures — achievable, useful, with a direct impact on visibility. A library of templates for frequently used article types — how-tos, reviews, listicles, Q&As — achievable, practical, and genuinely saving editorial time. A simple comments module, GDPR-compliant, with email moderation and CSV export — achievable, without the drama of impossible configurations. A security plugin monitoring backend access, blocking IPs displaying suspicious behaviour, and sending email alerts — achievable, necessary, honest in what it promises. A simple payment module for a single product, connected to Stripe or PayPal, without the full architecture of a dedicated e-commerce platform — achievable, and genuinely useful for small traders who are selling one thing.
The difference between a realistic request and a utopian one is not a matter of ambition. It is a matter of understanding that every feature carries a real cost — in development time, in required infrastructure, in ongoing maintenance — and that this cost must be borne by someone, whether explicitly in the price or implicitly in the quality of what is delivered.
The gap between desire and technology: a broader reflection
I come back to my father's workshop — to the smell of engine oil and warm metal, to the particular sound of spanners dropped on the workbench, to his certainty that anything can be repaired if you know what you are looking for and are prepared to work. Nobody walked in there with the idea that a gearbox repairs itself through the mere desire that it should. Everyone understood, instinctively, that there is a mechanism, that the mechanism fails in specific ways, that every fault has its cause, and that the repair requires a correct diagnosis, the right parts, and time — not less time than is necessary, never that.
The digital world has created the illusion that things have no visible mechanism. That somewhere there is an "on" and an "off", and that pressing the right place makes everything work beautifully. This illusion is, in part, a product of technology's own success at concealing its complexity — and that is precisely why it is so difficult to correct. You cannot show someone a semantic search engine with the same directness with which you can show a dismantled car engine laid out on a workbench.
Users are not naive. They are uninformed about a domain in which they have been led to believe that being informed is unnecessary. And that is a problem no plugin resolves, however well it is written.
What you can do as a developer: a few practical instincts
If you build extensions for Joomla — or for any platform — a handful of principles acquired, sometimes painfully, over eight years of practice.
State clearly what your plugin does not do. Documentation that explains limitations is more valuable than documentation that lists features. A user who understands from the moment of installation that a caching plugin will not compensate for five-pound-a-month hosting will not raise an furious support ticket a fortnight later.
Convert the utopia into realistic stages. "I cannot do that" is less useful than "here is what is possible now, and here is what would be required to reach what you're describing." Guide the person rather than simply declining. The person is not trying to be unreasonable — they are trying to be helped.
Build properly from the start. Joomla 4 and 5 compatibility, PHP 8.1+, PSR-4 autoloading, correct namespaces, MVC architecture where it applies. Not because users explicitly demand these things — because they are what survives over time and what does not generate problems at updates.
Be present in the community. Forums, support groups, direct conversations — these are where real needs take shape and where genuine understanding of user pain develops. And there, sometimes, a patient explanation achieves more than an additional feature.
20 Questions Worth Keeping — with Unambiguous Answers
1. Why do users request impossible features? Because they do not see the complexity concealed behind the simple interface. The success of modern UX design lies precisely in making the underlying work invisible.
2. Can an AI chatbot fully replace human support on a Joomla site? Not in the current state of the technology, without significant configuration and training on specific content. It can complement human support; it cannot replace it.
3. Is semantic search accessible for a small site on shared hosting? Technically, partially — through external APIs such as OpenAI or Pinecone. Practically, the cost and complexity exceed the benefit for the majority of small sites.
4. Can AI do SEO entirely in my place? It can automate repetitive tasks and offer useful suggestions. It cannot substitute knowledge of your business, your audience, and your specific competition.
5. Why can no plugin give me a PageSpeed score of 100/100? Performance depends on dozens of independent factors — server, theme, extensions, images, third-party code. A plugin controls only some of them.
6. Is automatic translation sufficient for an institutional website? No, without human review. Errors of legal, medical, or cultural nuance can compromise the credibility of the institution.
7. Why is content generated entirely by AI penalised by Google? Because it tends to be generic, lacking genuine expertise and the signals of E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) that Google actively evaluates.
8. Can I have Amazon-style recommendations on a standard CMS? You can have recommendations based on categories and tags — simple and useful. Real-time machine learning systems require infrastructure and data that a standard CMS does not natively possess.
9. Is a website's security resolved with a single plugin? No. Security is an ongoing process: updates, correct practices, monitoring. A plugin adds useful layers; it does not provide absolute guarantees.
10. Why is documenting a plugin's limitations more important than its feature list? Because unmanaged expectations produce disappointment, poor reviews, and costly support. Documenting limitations selects the right users from the beginning.
11. Is it still worth supporting PHP 7.1 in 2025? No. PHP 7.1 reached end of official support in 2019. Joomla 5 requires a minimum of PHP 8.1. Maintaining backward compatibility is expensive and delivers no real value.
12. Does GDPR inevitably complicate every interactive module? Yes, though not intolerably. Any collection of personal data — including comments — requires informed consent, the possibility of deletion, and documentation. It is a necessary and ethical cost.
13. Can a simple e-commerce plugin replace a full e-commerce platform? For a single simple product or service — yes, with Stripe or PayPal connectors. For complex catalogues, stock management, and automated invoicing — no, there is no solid shortcut.
14. Why are utopian expectations partly the web industry's own fault? Because marketing has promised "turnkey solutions", "all-inclusive packages", "no technical knowledge required". We sold simplicity when we should have sold understanding.
15. What is more valuable to a user: a plugin with fifty features or one with five solid ones? Invariably, the plugin with five solid, well-documented, conflict-free features. Feature count is marketing. Reliability is genuine value.
16. How do you explain to a client that what they want costs a hundred times their budget? Through a concrete analogy: "Amazon invested billions to build that button. We can build something that works for your specific case, within your budget, if we adjust the requirements accordingly."
17. Can a plugin make a site go viral on social media automatically? No technology can guarantee virality. Virality is a social phenomenon, not a technical one. A plugin can facilitate sharing — the decision to share is made by people.
18. Why do users confuse a CMS template with an enterprise application? Because the visual interface of both looks similar to an untrained eye. The difference lies in architecture, scalability, and the invisible work that never appears in screenshots.
19. What is the most honest promise a Joomla plugin can make? "It solves one specific, defined problem better than the native solution, under the hosting and architectural conditions documented in the readme."
20. What remains, in the end, from all of this? That technology does not solve problems of understanding. Understanding is built patiently, through honest communication, through continuous education — and that is work no plugin can do in our stead.
Author's Note — On Limits, Tensions, Comparisons, and Rhetorical Choices
I write these closing lines with a clear awareness of several choices made in the writing, choices that deserve to be named.
On limits: The article speaks about Joomla, but the observations apply to any CMS or web platform. I chose Joomla because I know it best, and because specific examples are more honest than vague generalisations. The discussion's limits are therefore also the limits of my direct experience — I have no experience of enterprise infrastructure at the scale of Amazon or Google, and I make no claim to any.
On tensions: There is a genuine tension, which I felt throughout the writing, between the wish to be empathetic towards users and the need to be direct about unrealistic expectations. I opted for empathy as the starting point — not out of formal politeness, but because I believe that people who ask for impossible things are not foolish: they lack context. The critical tone towards the industry — which includes myself as part of it — comes from the same place.
On comparisons: The comparison with my father the mechanic is not decorative nostalgia. It is a deliberate rhetorical device: the physical world of mechanics makes visible a complexity that the digital world conceals. People intuitively understand that an engine seizes without oil; they do not understand with the same intuition that a site fails without correctly configured caching. The analogy transfers understanding from a familiar domain to a more opaque one.
On rhetorical choices: I used the confessional first-person voice not for literary effect but because it is the voice that permits the acknowledgement of one's own errors. When I say "the industry overpromised", I include myself. My son's questions are real — he does ask things like this, with a directness that regularly disarms me. I included them because a truth spoken by a child carries a clarity that the technical argument does not reach.
Select Online Bibliography
On the limits of AI in semantic search and NLP:
- OpenAI Documentation — Embeddings Guide: platform.openai.com/docs/guides/embeddings
- Pinecone — What is a Vector Database?: pinecone.io/learn/vector-database
On SEO, AI-generated content, and E-E-A-T:
- Google Search Central — Creating helpful, reliable, people-first content: developers.google.com/search/docs/fundamentals/creating-helpful-content
- Moz — What is E-E-A-T and Why Does It Matter?: moz.com/learn/seo/what-is-eeat
On machine translation and its cultural limits:
- DeepL Blog — The limits of machine translation: deepl.com/blog
- Nimdzi Insights — The Language Services Market (annual industry reference report)
On web security and the realism of protection:
- OWASP — Top Ten Web Application Security Risks: owasp.org/www-project-top-ten
- Joomla Security Strike Team: docs.joomla.org/Security
On Joomla, PHP, and development standards:
- Joomla Developer Documentation: docs.joomla.org
- PHP-FIG — PSR-4: Autoloader Standard: php-fig.org/psr/psr-4