Table of contents of the article:
The title is deliberately provocative, because it sums up in a few words a narrative that we hear more and more often today: WordPress would be slow, ugly, old, written with outdated technologies and destined to be replaced from new CMS developed rapidly with the help of artificial intelligence, perhaps using more “modern” stacks such as Node.js, Go, MongoDB, Redis, headless architectures, microservices, asynchronous queues and NoSQL databases.
The thesis, on the surface, even seems reasonable. WordPress was born in another era of the Web. It was born when the concept of a "modern web application" was very different from today, when blogging was still one of the main forms of online publishing, when PHP was the reference language for quickly setting up dynamic sites, and when the classic LAMP stack—that is, Linux, Apache, MySQL, and PHP—represented a simple, affordable choice, available practically everywhere and within the reach of many. WordPress was born in 2003 as a fork of b2/cafelog, created by Matt Mullenweg and Mike Little, with the stated goal of offering an elegant system for personal publishing; today the official project still describes it as software based on PHP and MariaDB and licensed under the GPL.
The problem is that, starting from this historical truth, many reach the wrong conclusion: if WordPress was born in 2003, then it is necessarily unfit for 2026. If it is written in PHP, then it is necessarily slow. If it uses MySQL or MariaDB, then it is necessarily less modern than MongoDB. If it is not born asynchronous like Node.js, then it cannot handle the traffic. If AI today can generate a CRM, a management system, or a SaaS prototype in a few days, then it should also be able to generate an editorial CMS that is better than WordPress.
This is the classic situation where you risk reinvent the wheel, confusing the modernity of the stack with the maturity of the product, and the speed of initial development with the real sustainability of a platform over time.
WordPress was born in a completely different web
To understand WordPress, we need to go back to the context in which it was born. In the early 2000s, the web wasn't dominated by JavaScript frameworks, containers, Kubernetes orchestrators, CI/CD pipelines, headless APIs, and distributed databases. The content management systems of the time were often complex, heavy, and designed for communities, portals, forums, content management, and collaborative publishing. Drupal, for example, dates back to 2001, while Joomla was born in 2005 as a fork of the Mambo CMS.
In this landscape, WordPress wasn't created to be "the definitive universal CMS." It was born with a much more concrete goal: make it easy to publish contentBlogs, articles, pages, archives, categories, comments, RSS feeds, clear permalinks, customizable themes. Its initial strength wasn't textbook engineering abstraction, but its ability to install easily on inexpensive hosting, communicate with MySQL, use PHP, run on Apache, and allow a non-technical person to publish online without having to become a developer.
It's easy to look back at that decision today and say, "They should have used Go, Node.js, MongoDB, Redis, an asynchronous architecture, and an event-driven system." The point is that those technologies, in 2003, either didn't exist yet or weren't even remotely within the realistic scope of a general-purpose open source CMS. Go was publicly announced by Google in 2009, Node.js was also born in 2009, MongoDB released its first version in 2009, and Redis also launched around that time.
Saying today that WordPress should have been built on technologies that weren't available at the time is a theoretical exercise, not a technical criticism. It's like criticizing a car designed in the 1970s for not having an electric motor with solid-state batteries. It might be interesting as an academic discussion, or at the pub with some nerdy friends over a burger and a beer, but it doesn't change the reality: WordPress won because it solved a real problem with the tools available at its time..
MySQL, MyISAM, InnoDB, and Hindsight
Another frequent criticism concerns the database. WordPress was born at a time when MySQL was the natural choice for low-cost, widespread web applications. Today, we talk casually about InnoDB, transactions, isolation, foreign keys, MVCC, crash recovery, clusters, advanced replication, advanced query planners, and optimized engines. But the MySQL of the early 2000s was a different product, and for a long time, MyISAM was an extremely popular storage engine.
MyISAM had significant limitations: no transactions, no foreign keys, no table-level locking, and no MVCC. The MySQL documentation explicitly lists the lack of support for foreign keys and transactions for MyISAM, while InnoDB supports referential integrity constraints, more granular locking, and transactional isolation levels.
Here too, with hindsight, we can say that it would have been better to design everything on top of a mature transactional database, with rigorous schema, constraints, relationships, and systematically applied ACID guarantees. But the point isn't what we would have done today. The point is to understand that WordPress built its success within a specific technical, economic, and cultural ecosystem: shared hosting, PHP everywhere, MySQL everywhere, FTP, little automation, little system skills available to the average user, and a huge need for simple publishing tools.
Today, MySQL has changed, MariaDB has become a popular alternative, Percona Server has offered improvements and optimizations, InnoDB is the norm for serious installations, and modern infrastructures allow for tuning, replication, caching, monitoring, slow query logs, profiling, and much more refined analysis. However, WordPress retains strong historical compatibility and its own database abstraction. $wpdb, which is not equivalent to a modern ORM and does not use PDO as a standard interface. The official documentation describes wpdb as the class used to interact with the WordPress database without directly writing every connection detail, while remaining within the historical logic of the CMS.
The Modern Temptation: Remaking WordPress with AI, Node.js, Go, MongoDB, and Redis
For several years now, and even more so with the explosion of AI tools for software development, a belief has been spreading: if artificial intelligence can produce code rapidly today, then it's possible to design a new editorial CMS from scratch, faster than WordPress, more modern, cleaner, more scalable, and perhaps marketable to blogs, companies, newspapers, and information portals tired of a WordPress deemed slow and cumbersome.
The business rationale is simple: we take WordPress's perceived flaws—slow queries, heavy plugins, an outdated backend, legacy code, lack of built-in asynchronicity—and turn them into a market proposition.
We'll migrate you from WordPress to a modern, custom-developed CMS optimized for publishing, with cloud-native, API-first, headless technologies, MongoDB, Redis, Node.js, or Go. No more crashes with a few hundred online users. No more server-killing plugins. No more PHP.
The problem is that this promise confuses several levels. It's one thing to generate a prototype. It's another to develop a backend that saves articles, authors, tags, and images. It's another thing to show synthetic benchmarks in which an API written in Go responds in a few milliseconds. It's quite another matter entirely to build a CMS that can be used every day by real editorial teams, with permissions, revisions, previews, workflow, SEO, a media library, editorial compatibility, migrations, roles, integrations, newsletters, push notifications, advertising, paywalls, multilingual, redirects, canonicalization, sitemaps, feeds, comments, import/export, security, updates, and ongoing support.
AI can accelerate development, but it doesn't replace product experience.It can help you write code, document functions, generate tests, create interfaces, suggest queries, find bugs, and even profile bottlenecks. But it doesn't automatically create an ecosystem, trust, marketplaces, a developer community, widespread skills, and it doesn't guarantee that the software created today will be maintainable in five years.
WordPress isn't just code: it's an ecosystem
The most underestimated point by those who want to "redo WordPress" is precisely this: WordPress is not just a CMS written in PHPWordPress is a technical, economic, and professional ecosystem.
On one side, there's the Core, with its release cycle, APIs, hooks, filters, shortcodes, block editor, REST API, backward compatibility, and the enormous amount of field-tested code. The official documentation describes the hook system as based on Actions and Filters, which are extension points that allow plugins and themes to hook into the Core's behavior; similarly, the Shortcode API and REST API are fundamental pieces of WordPress's ability to be extended and integrated.
On the other side, there's a huge market: free plugins, premium plugins, free themes, commercial themes, marketplaces like ThemeForest, page builders, integrated SaaS services, specialized agencies, freelancers, system administrators, developers, designers, SEO consultants, copywriters, editors, performance experts, security experts, and hosting providers who know WordPress inside out.
The official WordPress theme directory lists over 14.000 free themes, while the plugin ecosystem far exceeds the tens of thousands of extensions available across the official repository, marketplaces, and independent developers.
This means that when a company chooses WordPress, it is not just choosing a CMS built in PHP. It's choosing an ecosystem where almost every common problem has already been addressed by someone. Want multilingual? There are mature solutions. Want newsletters? There are integrations. Want push notifications? There are plugins and services. Want a visual builder like Elementor or Visual Composer? There are. Want e-commerce? WooCommerce. Want communities? BuddyPress, BuddyBoss, and related solutions. Want e-learning? LearnPress, LearnDash, and alternatives. Want a professional editorial theme? For a few dozen euros, you can start with a commercial theme and adapt it.
A custom CMS written from scratch may be more elegant architecturally, but it starts from scratch right where WordPress is strongest: adoption, extensions, widespread knowledge, interoperability and trust.
Numbers matter: WordPress is still dominant
According to W3Techs, As of the end of June 2026, WordPress is used by 41,5% of all websites analyzed and holds 59,2% of the market among sites whose CMS is known; the same source also indicates a significant presence of WordPress 7 installations, even though WordPress 6 is still very widespread.
These numbers are important because they demonstrate one thing: WordPress isn't a nostalgic niche. It's not the "Sunday blogger" CMS stuck in 2008. It's a global publishing infrastructure, used by hobbyists, professionals, SMEs, public bodies, international brands, media companies, and publishing outlets.
The WordPress project has reached branch 7.0, with official updates to performance, accessibility, pattern management, stylesheet loading, and admin experience improvements. WordPress is being used by publishers and brands such as Al Jazeera, News Corp, USA TODAY Sports Media Group, and others; TechCrunch is featured in the Official WordPress Showcase as an enterprise publication; Vox Media announced the migration to WordPress VIP for its sites previously powered by Chorus and Pinnacle.
Even in Italy, Il Fatto Quotidiano, a company we have consulted for among our clients, is an interesting case: already in 2014, an article published on the same site indicated it as a successful online newspaper based on WordPress, and the current site still displays resources under paths wp-content, technical signal compatible with a WordPress base or with WordPress components still present in the stack.
The real fundamental concept: an editorial site is almost always heavy read
To seriously discuss performance we must start from a fundamental distinction: an editorial CMS is almost always a heavy read systemThis means that the number of reads is vastly greater than the number of writes.
An editorial team can publish 50, 100, or 300 articles a day. A large site can update its homepage, categories, tags, authors, and live content with high frequency. But public traffic is almost entirely made up of readers.Users who open articles, category pages, homepages, galleries, tags, searches, feeds, and related content. Compared to public visits, writing operations—posting articles, uploading images, reviewing, editing, publishing—are a small fraction.
This changes everything. If an article is published, read by hundreds of thousands of users, and remains essentially unchanged for days, weeks, or months, the real question isn't, "How fast can PHP generate this page each time?" The real question is, Why should I regenerate it every time?
This is where Varnish comes in. Today, in the open source world, it's also associated with the transition to Vinyl Cache, HTTP caches, CDNs, full page caching, edge caches, persistent objects in Redis, database tuning, and proper invalidation. Varnish is described in the documentation as a web application accelerator, a caching HTTP reverse proxy installed in front of the origin server, capable of serving content from the cache without having to return to the backend each time. In 2026, the open source project was renamed Vinyl Cache, with changes also made to the packages and service names in some distributions.
At that point, the question "Is Node.js faster than PHP?" becomes less relevant than it seems. If a public page is served from an HTTP cache, the user isn't querying PHP, isn't querying MySQL, isn't running the WordPress theme, or isn't loading server-side plugins. They're receiving a ready-made response from a reverse proxy or CDN.
In this scenario, whether MongoDB responds in 20 milliseconds and MySQL in 300, or whether Go generates a response in 5 milliseconds and PHP in 100, may be interesting in specific cases, but it isn't necessarily decisive for public traffic. If the article is cached for hours, days, or weeks, the bottleneck is no longer language. Become the caching strategy, invalidation, behavior on non-cacheable pages, authenticated traffic, frontend quality, asset weight, CDN, images, JavaScript, advertising, tracking, and infrastructure stability.
“WordPress is slow because plugins are slow”: a half-truth
Saying that WordPress is slow because plugins are slow is a half-truth. There are poorly written plugins, plugins that make absurd queries, plugins that load assets everywhere, plugins that use admin-ajax.php for everything, plugins that track article views with a dynamic request for each pageview, plugins that invalidate cache unnecessarily, plugins that schedule large cron jobs, plugins that save logs in tables without indexes and plugins that transform an editorial site into an experiment in systemic self-harm.
But this isn't a condemnation of WordPress. It's a condemnation of incompetent WordPress use. A knife can cut bread or injure someone: it's not the knife that decides.
The skill of those who design, develop, and manage WordPress also lies in knowing how to say no. Say no to the "Post Views Counter" plugin that updates the database with every visit to a site with millions of page views. Say no to the page builder loaded onto a template where it's not needed. Say no to the SEO plugin duplicated with another SEO plugin. Say no to five plugins for inserting scripts into the footer. Say no to abandoned plugins. Say no to modules that generate unindexed queries on huge tables. Say no to internal statistics systems when more suitable external tools exist. Say no to commercial themes full of useless features activated all at once.
WordPress performs well when treated as serious softwareLightweight theme, selected plugins, profiled queries, persistent object cache, full page cache, CDN, properly configured database, sized PHP-FPM, active OPcache, optimized images, monitored logs, system-managed cron (not reliant on random traffic), separation between backend and frontend when needed.
Node.js is not a magic wand: the Ghost case teaches us
Ghost is often cited as an example of a modern CMS, built on Node.js and designed for professional publishing, newsletters, and memberships. Ghost officially presents itself as a platform for professional publishers and, in supported production installations, lists MySQL 8 as a supported database, along with Node.js LTS, nginx, and Ubuntu.
Ghost is a good product with a clear philosophy, and in some cases it can be a sensible choice. But practical experience shows that "Node.js" on the brochure doesn't automatically mean "faster than WordPress" in every real-world scenario.
In a specific case, on a project with over 800 posts related to the meaning of names, we found that the combination of WordPress, MariaDB, and Varnish/Vinyl Cache was more effective, more manageable, and higher performing than Ghost with Node.js and MySQL. Not because Ghost is poorly written, but because the language wasn't the issue. It was the data model, queries, caching, volume, editorial habits, available tools, ease of intervention, and the behavior of the entire stack.
This leads to a very concrete conclusion: It is not Node.js itself that makes the difference, just as it is not PHP itself that condemns a projectThe difference lies in the overall architecture. And, very often, the database remains the main bottleneck in the non-cacheable parts: backend, searches, filters, dashboards, statistics, imports, correlations, taxonomies, editorial queries, dynamic APIs.
The database remains the bottleneck, even in the NoSQL world
When a site slows down, the easiest response is to change technology. Is MySQL slow? Switch to MongoDB. Is PHP old? Switch to Go. Is WordPress monolithic? Build microservices. The problem is that changing technology without understanding the bottleneck just shifts the problem.
A slow query is still a slow query even if you call it an "aggregation pipeline." A missing index is still a missing index even in a document database. A faulty data model remains faulty even if it's stored in BSON. A non-cacheable page that makes fifty calls to external services remains slow even if the backend is written in Rust, Go, or Node.js.
Serious work is less glamorous: slow query logs, EXPLAIN, profiling, cardinality, composite indexes, normalization where needed, denormalization where convenient, aggregate tables, application cache, proper invalidation, query reduction, elimination of useless joins, workload separation, replication for selective reads, queues for asynchronous operations, scheduled jobs, continuous monitoring.
In this context, artificial intelligence can become extremely useful. A good LLM model can help read an execution plan, suggest indexes, identify inefficient query patterns, explain why a join fails, propose a backup table, generate migration scripts, write tests, and compare plans before and after a change. But the same rule applies here too: AI accelerates the skilled technician, it does not replace the expertise.
The Big Misconception: Ignoring Cache and CDN Because Language Is Fast
One of the biggest mistakes made by new, "fast" CMSs is thinking that using a high-performance language allows you to bypass the cache. This is a conceptual error.
A high-traffic editorial site shouldn't handle traffic by dynamically generating each page for each request. It must handle it by serving as much content as possible from cache. This applies to WordPress, Drupal, Ghost, a Go CMS, a custom Node.js backend, and any serious publishing platform.
The foundations are always similar:
- HTTP cache in front of the origin, with Varnish/Vinyl Cache, NGINX caching or equivalent solutions;
- CDN to distribute static assets, images, cacheable pages, and geographic traffic;
- object cache with Redis or Memcached to reduce the load on the database;
- database tuning with indexes, adequate buffer pool, slow query log and replication when needed;
- lightweight frontend, because perceived slowness is often caused by JavaScript, advertising, tracking, and unoptimized images;
- selective invalidation, so as not to empty the entire cache with every editorial update.
Without these elements, even the most modern CMS risks collapse. With these elements in place, WordPress can handle massive traffic at reasonable costs and with an ease of use that many custom solutions can't match.
What you lose when you switch to a custom CMS
The least talked about part of migrating to a proprietary or custom CMS is what you lose.
First and foremost, the plugin ecosystem is being lost. Not just the "basic" plugins, but the entire wealth of ready-made solutions for real-world applications: SEO management, redirects, sitemaps, feeds, schema markup, multilingual support, newsletters, forms, CRM integrations, visual editors, role management, editorial workflow, import/export, media handling, image optimization, security, backups, caching, e-commerce, membership, paywalls, advertising, and analytics.
The theme ecosystem is being lost. A commercial theme costing $50 or $60, perhaps purchased on a marketplace, isn't the ideal solution for every project, but for many SMEs or small publishers, it represents the difference between going live in two weeks and spending months on design, front-end, components, templates, responsiveness, testing, and refinements.
The availability of professional figures is diminishing. Finding a WordPress developer, a systems engineer who knows WordPress, an SEO consultant who understands how WordPress works, or a designer who has already worked with WordPress is relatively easy. Finding someone who knows a custom CMS developed by a small software house or an in-house team is another matter.
You also lose the freedom to opt out. WordPress is open source, documented, widely available, and accessible. A custom SaaS or PaaS CMS can be convenient as long as the relationship works. But what happens when costs rise? When the vendor changes priorities? When you need an unexpected feature? When support deteriorates? When the company gets acquired? When you want to go back to WordPress, Drupal, or another open source system?
This is where a very simple rule applies: Marriages are easy, fun, and full of smiles; it's divorces that make you cry.Joining a proprietary platform is often simple. Leaving it can mean exporting millions of pieces of content, rewriting URLs, preserving redirects, migrating media, rebuilding taxonomies, saving SEO metadata, maintaining canonicals, converting embeds, regenerating sitemaps, reconciling users, comments, permissions, and editorial history.
WordPress is general purpose, and this is its strength.
Many criticize WordPress because it isn't vertical. It wasn't born as a CMS exclusively for large editorial offices. It wasn't born as an e-commerce site. It wasn't born as an LMS. It wasn't born as a social network. It wasn't born as a marketplace. It wasn't born as a headless enterprise platform.
And that's true. But that's precisely one of the reasons for its strength. WordPress is a general purpose, highly extensible CMS, which over time has been used to do very different things: personal blogs, magazines, corporate sites, portals, communities, e-commerce with WooCommerce, e-learning platforms, memberships, institutional sites, landing pages, documentation, lightweight intranets and much more.
This flexibility is not trivial. The hooks, filters, shortcodes, custom post types, taxonomies, templates, REST API, block editor, and massive backwards compatibility are the result of years of layering. We can criticize some choices, we can find parts of the Core less elegant than modern standards, we can prefer other architectural patterns. But we can't dismiss WordPress as "spaghetti code" without acknowledging the engineering complexity of a software that must continue to run on millions of sites, with thousands of different combinations of themes, plugins, hosting, PHP versions, databases, and workflows.
A similar level of abstraction and compatibility is difficult to design even for senior developers with twenty years of experience. Thinking it can be replicated in a few months by "vibe coders" guided by Claude Code, Cursor, or similar tools is naive. You can create a convincing prototype. You can create an interesting MVP. You can create a vertical CMS for a specific use case. But Recreating WordPress as an ecosystem is another thing.
When WordPress Isn't Enough: Enterprise Alternatives Already Exist
This doesn't mean WordPress is always the right choice. There are cases where a large media company, a multinational editorial team, or a publishing group with significant print and digital needs, complex advertising systems, advanced paywalls, legacy integrations, or highly structured legal and editorial workflows may require vertical enterprise solutions.
The point is, that market isn't empty. There's no huge gap waiting for an AI-generated CMS from a small, makeshift software house. Platforms like Eidosmedia, Arc XP, Brightspot, Stibo DX/CUE, Atex, Naviga, Ring Publishing, WoodWing, and other solutions specifically designed for professional publishing already exist.
Eidosmedia lists clients such as the Financial Times, The Wall Street Journal, The Times, The Boston Globe, and Le Figaro. Brightspot lists the Los Angeles Times, US News & World Report, and POLITICO among its media clients. Atex is listed by the Google News Initiative as a solution used by publications such as la Repubblica, El País, the Daily Mail, Metro, and the Sydney Morning Herald. Naviga presents itself as an end-to-end platform for publishers and media companies, with clients and case studies including DallasNews, Newsquest, and Bonnier. Stibo DX / CUE was selected by Mediahuis as the central platform for news websites and apps. Ring Publishing positions itself as a modular, cloud-native content experience platform for creation, distribution, and editorial automation.
In other words: if a publisher truly wants to move beyond WordPress for enterprise needs, the market already offers mature, expensive, vertical, and structured alternatives. The new "faster than WordPress" custom CMS must therefore compete on two fronts: against WordPress, which is open source, affordable, widespread, and flexible; and against enterprise solutions already recognized by the publishing market.
The real problem is not WordPress: it's the improvised developers and the fake system administrators
We come to the most uncomfortable point. Many WordPress installations are slow, unstable, and fragile not because WordPress is inadequate, but because they were poorly designed, developed, or maintained.
Themes full of useless features. Plugins installed haphazardly. Undersized hosting. No HTTP cache. No CDN. Database never optimized. Huge autoloaded tables. Cron left to run on traffic. Slow queries ignored. Untested backups. No staging environments. Updates made to production without supervision. 8 MB images uploaded. Unmanageable advertising JavaScript. Nulled plugins. Security left to chance. And then, when everything falls apart, it's WordPress's fault.
In the world of CMS, we've gone through PHP-Nuke, Mambo, Joomla, Drupal, WordPress, Typo3, and even Ghost. We've seen portals handle heavy traffic with seemingly "old" stacks, and we've seen ultra-modern projects collapse because no one had thought about caching, databases, CDNs, indexes, asynchronous jobs, logs, and maintenance.
The truth is that technology doesn't save a poorly managed projectA poorly written Go CMS can be worse than a well-configured WordPress. A Node.js backend without a cache can cost more than a WordPress one served by Varnish/Vinyl Cache. MongoDB without proper modeling can become a nightmare. Using Redis as a crutch to hide incorrect queries can only prolong the problem.
Is WordPress slow, ugly, and outdated?
WordPress can be slow. It can be ugly. It can be outdated. But not by definition.
It's slow when used without a cache, with heavy plugins, overloaded themes, an unoptimized database, and inadequate hosting. It's ugly when left with shoddy templates, a makeshift UX, and a haphazardly constructed front end. It's obsolete when treated like a blog from 2008 instead of a modern, extensible, cacheable, and embeddable publishing platform.
But a properly designed WordPress can be fast, stable, secure, scalable, and perfectly suited for blogs, magazines, editorial portals, and newspapers. It can be used in classic, headless, hybrid mode, with CDN, with Varnish/Vinyl Cache, with Redis, with optimized MariaDB or MySQL, with custom frontends, and with advanced editorial workflows.
The point isn't to defend WordPress out of prejudice. The point is to avoid the opposite mistake: attacking it for the sake of fashion, technological snobbery, or to sell a custom solution that, in most cases, will be less complete, less extensible, less supported, and more risky.
Conclusion: reinventing WordPress only makes sense if you really know what you're doing
No one is stopping a software house, a team of developers, or a startup from creating a new CMS. No one is stopping them from trying to build a better, more vertical, more modern solution, better suited to a certain type of editorial team. Innovation also comes from courageous attempts.
But we have to be honest. In most cases, rebuilding WordPress “because WordPress is slow” means starting from the wrong diagnosis. If the problem is a lack of cache, the solution isn't MongoDB. If the problem is a plugin that makes terrible queries, the solution isn't Go. If the problem is a theme with 20 MB of assets, the solution isn't Node.js. If the problem is a lack of system expertise, the solution isn't a custom CMS: it's system expertise.
WordPress remains, today, one of the best possible solutions for blogging, online publishing, magazines, informational sites, and many content-driven projects. Not because it's perfect, but because it combines maturity, ecosystem, freedom, extensibility, sustainable costs, available skills and real scalability when managed well.
If a publication's needs are so complex that they exceed WordPress, then it should probably evaluate existing enterprise platforms, with well-defined budgets, contracts, SLAs, migrations, and lock-ins. If, on the other hand, the problem is that WordPress "crashes with a few hundred online visits," a new CMS is often not needed: it requires someone who truly knows how to configure WordPress, the database, PHP-FPM, Varnish/Vinyl Cache, Redis, CDN, plugins, themes, and infrastructure.
The reality is less glamorous than the slogan, but much more useful: It's not WordPress that isn't up to par with modern publishing. Often, those who install, develop, or manage it without really knowing it aren't up to par..
