<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#0b5394">I know this is old but thought I would add some perspective. WordPress' plugin ecosystem is too big. Its primary audience is what I call site builders - individuals with some coding experience mainly in html, and CSS and maybe a bit of javascript's jquery library. Although that latter is probably pushing it. I went to WordCamp 8 years ago in Phoenix as a GoDaddy rep. Most of the people and even the talks were geared towards non-coding professionals. Most people there wouldn't have been able to explain what an object was in any language and couldn't blueprint a class declaration or any of its mechanics. <br><br>Where do they go - If they don't want to pay for real development they head to Squarespace or Weebly or other no-code solutions.<br><br>Most of the use cases for WordPress I am familiar with are for small businesses. Most hosting companies have auto site builders that construct the website in 30 seconds. But then people quickly get bogged down in even finding, picking, installing and implementing the plugins correctly after the initial build. Often they are left with hacked, or bloated sites that leave them exposed and filled with malware. I helped an agency clean up a WordPress website for a plastic surgeon where the MySQL database had been injected with Russian phishing data. The site was 5 years old and I found over 150k nefarious entries that had to be cleaned up and removed. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#0b5394"><br>Later I worked for a tech firm that consults for large corporate clients that use WordPress for limited sites, like a digital magazine for high end real estate holdings, almost like a brochure version of Architectural Digest. In these cases WP works because we would limit the number of plugins and user interaction with the site. We could have easily built these sites without WP and often did, but if they were going to maintain the site the contracts would dictate that we had to build it in WP.<br><br>I think that the current metrics are around 43% of the web uses WordPress. I would estimate that easily 70% of the database and the codebase in WP is for managing the application and has little to do with the actual visual website that the general public see and interact with - excluding ecommerce and subscription-based web apps that need user account transactions. A typical WP site is over 1 million lines of code. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#0b5394"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#0b5394">But when the same companies hired us to build enterprise-based solutions and wanted a PHP-based web application the choices were usually Drupal for sites that needed a CMS and Laravel for sites that didn't. Even if they wanted a SPA (single page application) like React, Angular, or Vue, we recommended the backend be built in Laravel and not Express (Node). Drupal is based on the Symfony PHP framework and Laravel hooks into it. Symfony is by far the most well supported open source PHP solution. The irony is that there are enough good libraries both on the JavaScript and PHP that are better written, more secure, and just as easy to implement than going to a WP-based approach. Plus I have to wonder what is going on with Automatic and WP Engine and what is the future of WordPress.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#0b5394"><br>For sites that need to be sped up and are limited to remain on older server instances. My advice is to simplify the code base as much as possible. So roll your own framework or use a lightweight MVC framework. Turn on opcode (APC) and object caching (Redis) and if you are using Apache as your Webserver play with the MaxClient settings to dial in the amount of preforking that Apache does. Setting the number too high in MySQL will cause thrashing when the database constantly has to write data out to the disk to clear up memory to add threads. Or switch to Nginx as the webserver.<br><br>Package These up in a Docker container or containers (web server, database server) running a lightweight Linux instance and you have a portable web application that can be installed anywhere and spun up in seconds.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Nov 15, 2024 at 12:17 PM Keith Smith via PLUG-discuss <<a href="mailto:plug-discuss@lists.phxlinux.org">plug-discuss@lists.phxlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank You David,<br>
<br>
I agree WordPress is bloated and it is one-size-fits-all. I saw a video <br>
recently that WordPress has 40% market share.<br>
<br>
I am hoping to build my own infrastructure within a year and a half.<br>
<br>
I think potentially the back end JS issue is my problem. That is why I <br>
mentioned my daily driver is a 10 year old Dell with an i5 and 16G of <br>
RAM. It is running an SSD that helps. Seems 32G is the minimum <br>
now....Yikes<br>
<br>
Another issue is Google has removed 12 of my articles because of <br>
redirects. I've looked at it several times and cannot figure it out. I <br>
did not add the redirects. I wonder if it is WordPress that is doing <br>
something.<br>
<br>
Other than a more powerful CPU and more RAM what is the solution? Is <br>
there a point when people start to exit WordPress, and where do they go?<br>
<br>
<br>
<br>
<br>
On 2024-11-13 12:47, David Schwartz via PLUG-discuss wrote:<br>
> Javascript runs in the browser. Most issues I hear about and encounter <br>
> myself end up being browser-related.<br>
> <br>
> You mentined all of the things that aren’t connected to JS, and did not <br>
> mention the one(s) that are. JS is the primary source of problems <br>
> today. And hackers that break into the back-end.<br>
> <br>
> I operate almost exclusively on Macs and my Android phone, and I’ve got <br>
> between three and six browsers on each one. None of them work the same <br>
> — which is to say, when I run into a problem on one, I can usually <br>
> solve it by switching to another browser. Every week it’s something <br>
> different.<br>
> <br>
> The source of the problem is not worth my time to figure it out, and <br>
> it’s really easy to switch to another browser.<br>
> <br>
> Don’t blame php or the back-end for quirks that are endemic to JS <br>
> running in one specific browser. Even updates of the same browser can <br>
> behave differently. And the behavior on the same browser can change <br>
> from one day to the next, or one hour to the next. Nobody is changing <br>
> the back-end that frequently, I can assure you. It’s the libraries the <br>
> pages are loading up, or the code the site’s developers changed last <br>
> night.<br>
> <br>
> I’ve been writing code in Delphi using TMS WEB Core, which is available <br>
> both as a Delphi addon and a standalone package that runs in Visual <br>
> Studio Code. It takes Delphi code (Object Pascal) and translates it <br>
> into JS and packages it up so it runs in the browser. NONE of it is <br>
> running in the back-end! It’s 100% browser based. And 100% of the weird <br>
> issues I have are all browser related. Sure, there are bugs in the <br>
> platform, but they are typically reproduced the same in every browser. <br>
> Browser issues show up differently in one browser, maybe two, but not <br>
> in all of them.<br>
> <br>
> A lot of browsers are using the Chromium engine, so quirks in it can be <br>
> reflected elsewhere, but they usually need to be running the same <br>
> version of the engine for them to show up.<br>
> <br>
> It used to be that you had to test software on different machines from <br>
> different vendors, different versions of Windows or MacOS, and it cost <br>
> you a lot of money to have all of those combinations of software and <br>
> hardware available for testing.<br>
> <br>
> Today you just need to test on one hardware platform with variations of <br>
> browsers loaded on it, probably running in separate VMs or docker <br>
> images to ensure you test with different versions of Chromium and <br>
> whatnot.<br>
> <br>
> Same old sh*t, different approach.<br>
> <br>
> As far as WP goes, I think it’s internal architecture has become <br>
> obsolete. Layers and layers of crap have been added to convert <br>
> asynchronous events into something that serializes them, and the people <br>
> writing plugins and themes are mostly inexperienced coders who don’t <br>
> have a clue what’s what. Meanwhile there are people who have nothing <br>
> else to do with their life but find ways to sneak into cracks and <br>
> crevices in the back-end, and sometimes wide-open doors, left by said <br>
> inexperienced coders who didn’t do a good job testing their code. “It <br>
> works! Ship it!”<br>
> <br>
> The UX/UI logic is all being pushed out to the browser, and the <br>
> business logic is being hidden behind REST APIs. I can build something <br>
> in TMS WEB Core way faster than it takes to build in WP — it runs <br>
> faster, is more solid, and is far easier to maintain. That can probably <br>
> be said of most JS-based UX/UI dev tools today.<br>
> <br>
> The problem with Wordpress is … it’s Wordpress. The UX/UI is tightly <br>
> coupled to the back-end because all of the user’s state is managed in <br>
> the back-end. And it’s not an API, but just a huge mess of functions <br>
> that are designed to be hijacked by programmers to get it to do pretty <br>
> much anything out of the ordinary — if you can’t get it to support <br>
> something in the UI, you need to build a plugin or theme to add it. And <br>
> that code lives on the BACK-END and is susceptible to all of the myriad <br>
> ways there are for hackers to throw sand in the gears. The whole damn <br>
> platform is open to anybody who wants to poke and prod it’s guts! They <br>
> even added an API but nobody uses it.<br>
> <br>
> If I need something to work a certain way using WEB Core, I can easily <br>
> program it. I hide necessary business logic behind an authenticated <br>
> REST API and the JS in the browser manages it all. The events are all <br>
> asynchronous and I don’t have to worry about someone hacking into the <br>
> back-end code and hijacking everything. I can build the services in any <br>
> language and host it on any platform I want.<br>
> <br>
> In WP, you have to build a plugin and plan to maintain it as further WP <br>
> updates will very likely break it in some unexpected way. Or if not the <br>
> WP code than maybe one of the UI libs you’re working with change and <br>
> someone updated a theme that loads a different version and screws up <br>
> your code.<br>
> <br>
> IMHO, WP is just a big fat ugly mess that only gets worse over time.<br>
> <br>
> Just switch to a no-code / low-code solution that lets you custom-build <br>
> what you need, and that isn’t dependent on dozens of things that can <br>
> change from week to week and month to month as the underlying platform <br>
> is patched to fix newly-discovered exploits and the UI libs get updated <br>
> by updates in the plugins and themes.<br>
> <br>
> -David Schwartz<br>
> <br>
> <br>
> <br>
> <br>
>> On Nov 13, 2024, at 9:12 AM, Keith Smith via PLUG-discuss <br>
>> <<a href="mailto:plug-discuss@lists.phxlinux.org" target="_blank">plug-discuss@lists.phxlinux.org</a>> wrote:<br>
>> <br>
>> Hi,<br>
>> <br>
>> This is kind of off topic, however WordPress is Open Source and I <br>
>> would expect that the vast majority of WordPress is run on LAMP <br>
>> servers.<br>
>> <br>
>> My daily driver is a 10 year old Dell that has an i5 with 16G of RAM <br>
>> that runs Kubuntu 24.04lts.<br>
>> <br>
>> I am running a blog using WordPress that is hosted on an Ubuntu <br>
>> server.<br>
>> <br>
>> I am having issues with the WordPress Gutenberg back end. I cannot <br>
>> get it to do the things I want to do like bold text. At times is is <br>
>> sluggish. I've read that WordPress has a 10 year plan to move to <br>
>> JavaScript. There is not a lot of info available so it is unclear if <br>
>> the PHP code will be replaced as well. If WordPress replaces the PHP <br>
>> back end I will leave WordPress. As it is WordPress is hanging by a <br>
>> thread.<br>
>> <br>
>> These problems are new. I am also having formatting issues which might <br>
>> be due to my theme.<br>
>> <br>
>> Is anyone having these issues or maybe other issues with WordPress?<br>
>> <br>
>> Ultimately I may create my own infrastructure or start building my own <br>
>> theme.<br>
>> <br>
>> Any feedback is very welcome.<br>
>> <br>
>> Keith<br>
>> ---------------------------------------------------<br>
>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
>> To subscribe, unsubscribe, or to change your mail settings:<br>
>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
> <br>
> ---------------------------------------------------<br>
> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
> To subscribe, unsubscribe, or to change your mail settings:<br>
> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
---------------------------------------------------<br>
PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#0b5394">James</font><div><br><span style="color:rgb(255,255,255)"><span style="background-color:rgb(11,83,148)"><b><a href="http://www.linkedin.com/pub/james-h-dugger/15/64b/74a/" target="_blank"><span style="background-color:rgb(255,255,255)"><span></span><span style="color:rgb(11,83,148)">Linkedin<span></span></span></span></a></b></span></span><br></div></div></div>