Reporting from a budget Android Tablet with Firefox, the response times aren't exactly instantaneous but aren't any different than running full LAMP on a reasonable cloud instance or VPS which is surprising to say the least.
Also imagine the software layers at play here. Whole PHP Interpreter plus whole thousands of lines from WordPress codebase plus SQLite.
Absolutely. The other day, I took my slow Wordpress server hosted at Vultr on bare metal (£200/pm) and put it on a server at £500 per month and even after doing all the performance tuning I could with MySQL and PHP I couldn’t notice a difference in speed when I was on the back-end where Cloudflare wasn’t caching it.
I then tested on a lower performance server which costs £80 per month at Vultr and again couldn’t detect any difference when in the back-end.
No matter what performance tuning I done, I couldn’t make it work faster for us. But at least I am on an £80 server instead of a £500 server I guess.
I don’t work for Automattic but after spending years trying to “save money” on wordpress hosting I agree just spend the extra cash for a proper managed soloution. Life is too short to spend optimizing page load for your marketing site when its already a solved problem
There is a worry that I have about switching to a company like yours…
What really happens if you decided you didn’t like the products a website sold?
…Would you give them the time to move and take their backups with then or would you immediately hit the delete button on their data?
These are the reasons we switched to self-hosted Wordpress in the beginning. You don’t need to be on HN for long each day to see the same stories being told continuously about how the big guys treat the wee people.
Does wordpress.com used a forked version? Last time I remember that the custom themes were limited for the hosted solution. Maybe this was for performance reasons?
I've got a client using LearnDash, BuddyBoss, WPML, ACF and Woo for their subscription platform. It's dog-slow on the uncached pages, even on a very beefy server with only 5 concurrent users, choking the database apparently. Serving only 2 countries so don't need a CDN per se. (Why) Would this be faster on wp.com?
I just noticed WP.com Business tier exists recently. It’s a no-brain, indeed. On Thursday I signed with you guys and planning to move my site today. (Wish me luck!) Moving will save me ~90% of what I was paying for a managed VPS.
What's the answer to making WordPress sites faster?
I too have tried better hardware, CDNs, plugins like WP Super Cache, and others means of optimizing. Very little impact. Is the problem PHP?
I'm thinking of trying one of those plugins that convert the WordPress site to static web site. I'd imagine that'd have a big impact, at least for sites that don't need e.g. login, shopping carts, etc.
PHP is fast for a dynamic language (compared to say Ruby/Python and even JS). It has the disadvantage that it gets slow by default the more code you have, because it has a static execution model.
WP is extremely bloated and slow though. You can only make it fast by telling Apache to not execute it and hitting your cache (or with a caching layer in front).
With heavy caching (flushed on data changes), hand written themes and plugins, modern build tools for frontend assets, image optimization etc. You can get get top metrics.
However, that's just frontend. The admin panel is always slow.
If your use-case allows it, you rather build one with something like hugo. Hugo and similar are very easy to use and net you much better results.
My general tip is to not build websites with WP if you have web development skills.
WordPress is very fast out of the box considering all its capabilities, it's not hard to get in the range of 100ms TTFB out of the box on dirt cheap VPS servers, which is pretty good in my book. The problem is that people add very heavy themes and plugins that push them well above acceptable TTFB numbers.
Full Site Editing with the new Gutenberg editor have amended a lot of that, it's very performant out of the box. Just as an example, I have a site averaging about 200ms for uncached requests, it has an FSE theme and 20 installed plugins, including heavy ones like ACF.
This is all out of the box without cache, but by adding a simple static page cache (either a plugin or something like Fastly, Varnish etc.) you can make it so that the p95 latency drops by 80-90% because most people will see cached page views any way.
Wordpress at its core execute most of its user-facing code trough an un-parallelizable, self-modifying single threaded queue, which has to be run at every page reload[1] and everything and anything will have to inject stuff in it. From handling your pictures in your media library, to checking your server can actually send mails, to managing your page and posts content and layout, everything goes trough it. It's also a system that doesn't really play ball very easily with most PHP accelerators outside of baseline PHP opcache.
You may have better luck using a static cache or memcached. Depending on the theme you're using (90% of what's available from envato themeforest, for example) the improvement will be negligible due to the impact of all the uncachable third-party jquery plugins that are usually included on a commercial theme.
All of the data you're accessing is also for the most part queried from two tables of a single database instance[2] which again handles everything from your mail configuration, page routing and redirection, page layout, contents, stored forms, etc. No sharding, load balancing is natively available. Heck, most WP hosted solutions run MySQL on the same instance running Apache and PHP.
Also the data is usually stored as serialized php values, which have to be parsed and reformatted, again, at every page load using the system described beforehand.
The problem is the ecosystem. You can get response times for the main page down pretty low (especially with caching plugins) and the time to serve static assets is the same for Wordpress or a static site. Most likely if your site feels slow, the culprit is your theme and one or more plugins on your site. You can usually track down problem plugin(s) using PageSpeed Insights since their frontend assets are served from the plugin folders.
First, seconding everything dgb23 said in this thread.
I think if you don't have a need for that dynamic stuff, yes a static site generator is a slam dunk in my humble opinion.
The PHP/Wordpress model where pages are composited dynamically for each pageview was an idea that made sense 20+ years ago. Whereas today, regenerating 1000 (or 10,000) static HTML pages can be done in a few seconds anytime a new blog post is made, giving up-to-date sidebars, homepage and stuff. Other code which needs to be dynamic can usually be fully client-side. And for comments, I don't think almost anyone uses the WP comment feature anymore. It's either off due to spam, or delegated to Disqus or similar. That, combined with the constant stream of WP 0-day exploits, really argues for having your actual WP instance behind your firewall and serving your files from an S3 bucket or plain Nginx (etc).
Use a plugin like 'Cache Enabler' by KeyCDN, it's very lightweight and does exactly one thing very well.
Get rid of as many plugins as possible, many of them add a ton of load time and browser load. Woocommerce is especially bad.
Use a lightweight theme, there are a few good ones out there for that. Or just the default one it comes with.
And yeah if you have zero dynamic content needs then a static site generator can work fine. But with minimal plugins and a cache enabler, response time should be very fast anyways.
I worked on a Strattic conversion some time back - they basically scrape all your pages and serve them statically, but you do have to do some things to support search, forms, etc and you'll end up pruning plugins that don't work well with it.
But, serving static pages is very very fast afterwards.
I'll bet on future WP updates eating whatever perf improvements new hardware will give. Besides, Moore's Law is about the number of transistors. Speed - and especially single threaded speed which is what matters for PHP sites - is not going up nearly as fast anymore.
Yes, but practically speaking, waiting 20 years isn't an option. Moore's Law has stopped delivering rapid single-threaded performance gains and not everything is trivially parallelable.
The fastest single-threaded cpus today are only 2x faster than the fastest single-threaded cpus of a decade ago...
Mine renders pages in under 50ms under BAU load and it's hosted on a $1/month cPanel. The only trick I have used is to run it on PHP 8.1 with Lightspeed Cache
you also need a small footprint theme like (Neve), and customizing Apache with right modules to compress files, or with less customization ( nginx) might be faster
Yes, but: Number of concurrent visitors can change dramatically on lower vs higher. A caching plugin mitigates this somewhat, but I find that most companies don’t test whether their site can handle surges, or even if it can handle the projected traffic load.
That's horrifying because, theoretically, it should be a tiny, tiny fraction of that: on bare-metal we can run PHP + MySQL (let alone SQLite) + Apache within a few dozen MB of RAM.
(Historical personal anecdote: my first-ever dev-server machine I built before high-school ran Windows Server 2003, IIS, SQL Server, and Adobe Photoshop 7.0 (in a Terminal Services session) concurrently just fine well-within 256MB with little-to-no paging)
Let's be generous and assume that 64MB should be a reasonable upper-bound (though I think that getting it under 16MB should be possible), in which case what exactly is the other 1.09GB of RAM being used for?
I'm not entirely sure on this, but I believe that what we're seeing is the WASM runtime allocating memory for its potential needs, but not totally using it all.
The entire filesystem, all the executables, all uploaded files, and all database data lives in memory in the virtual filesystem. I think we could trim down the default allocation but it might actually be meaningless anyway; that GB won't steal real RAM unless it fills up inside the environment.
Someone can probably check me on this, but if my memory serves me right this is what's going on.
In like 1997 I was doing some work with a 5x86-133 with 24mb ram and a 2gb disk, running NT 3.51, MS SQL server, IIS and Visual Studio 4. IIRC, the servers usually ran in less than 500kb committed each.
> That's horrifying because, theoretically, it should be a tiny, tiny fraction of that: on bare-metal we can run PHP + MySQL (let alone SQLite) + Apache within a few dozen MB of RAM
Only being half-facetious here: if the old stack was so great, why aren't you still using it? I know someone who swore by ColdFusion, but won't use BlueDragon or Lucee because the world has moved on from CFML; templated HTML-generation on the server is no longer the only game in town
> if the old stack was so great, why aren't you still using it?
I am, granted, current-versions-thereof - though with more recent OS versions the RAM requirements just go up, because modern OSes (especially Windows Server) are built to more aggressively cache things in RAM to avoid paging to disk.
I work primarily in .NET and that is also RAM-hungry: it allocates a huge chunk of RAM for each CPU core for per-thread GC purposes - which does drastically improve GC perf in production - and if prod has only 1-4 VM cores assigned this isn't a problem - but on my dev box with its 24-core Xeon CPU it means even a Hello World program will consume probably 500MB+ of RAM - ugh. To-date, I haven't found a way to control or limit this.
But my post wasn't me complaining about my current situation - more about my despair at the lack of belt-tightening from certain platform vendors like Chromium - or in this case, why compiling to WASM instead of native results in this level of RAM usage.
The browser task manager may claim that, but actually watching Windows Task Manager, my total memory usage increases by about 300MB when I visit the playground, not 1GB. Maybe a lot of the memory is uncommitted.
"Whether you want to build a note-taking application for mobile devices, an automated testing environment, or demo a live WooCommerce store on your site – Playground will support you."
The last two make a ton of sense, but the idea of building a mobile app that's powered by Wordpress running PHP in webassembly in the browser is wrecking my brain.
Except this is already running on a js environment in the browser (usually v8 if you use chrome, edge or any of their derivatives, the engine behind node). So you are running something to not run the thing you are already running.
There are plenty of Python apps now running in WebAssembly too. A lot of Node's stack directly runs in browsers (browserify is "ancient" tech at this point and influenced so much of modern "bundling" including Webpack and many things post-Webpack). (Deno's doing its own work with browser-compatible Node APIs, too.)
- one group recognizes WordPress for what it is: a value-multiplier used by non-coders for websites so they don't have to deal with the coding and can focus on their core competencies
- the other group hates WordPress because of the ugly codebase, and meanders off to work on their own perfectly formatted, ultra-scalable code that has no little to no value because it's never actually going to be used by anyone outside of their startup.
WordPress powers more than half of the Web. It might not be the best tech, it might very well be the worst possible tech, but the lesson that so many programmers continuously fail to take from WordPress is that NOBODY CARES HOW THE SAUSAGE IS MADE.
This is a reasonable position and with the utility sites I build for, say, bands I play with I totally agree. I toss some shit on commodity hosting and hope the band breaks up before the gcal integration breaks.
-=-=-=
However.
I will now take this opportunity to vent a bit, though it has little to do with your imminently reasonable post. Mostly because I am procrastinating on porting a 3rd-party SSO system from a very old and shitty WP site to a new and shitty WP site and it's hurting my brain to decide how much of the mess of jQuery and bootstrap I really need to keep.
So hopefully this will be understood as venting and not a personal attack against your reasonable observation.
-=-=-=-
Consider that there are those of us who have to fix the first group's problems and make things keep working so they don't have to care how the sausage is made.
That is to say, there is a very real third group of folks: those of us who support the first group.
=-=-=-
I've been doing that work for about 14 years for all kinds of folks. I host 300 or so WP sites for a mid-sized university, I built and maintain a .gov site for a three-letter-agency, and I've built plenty of react-based blocks (across 3 majorly different patterns because the GB team doesn't give a fuck about anything, as far as I can tell).
I've worked on every element of WP from deploying servers to fixing CSS so it works in IE6, to scraping non-availible CMSs so that I can migrate thousands of pages and tens of thousands of images to WP. I've written plenty of WPCLI commands to do dumb tasks, I've written plenty of shit-tier code to make, say, calendar events propagate across the bad-for-most-purposes multisite functionality.
=-=-=-
Someone has to know how the sausage is made. I do.
And I know the difference between the teetering pile of steaming crap that is WP.
I've worked on actually useful codebases in my life with tooling that is easy and databases that are grokkable. I am aware that other platforms have issues, and have encountered them in my work.
However, WP is really bad.
And I have no problem bitching about it- I'm burnt the hell out and am about ready just quit and live in my truck and play music.
It's a shitty platform, and people do not pay well to keep it working.
=-=-
So anyhow, yeah, you've got a fair point, but there those of us who, because of circumstance, keep heading back into the burning building that is WP and our collective hatred of the platform is well-founded.
Going to go out on a limb here and say that a sales pitch doesn't address parent's comment...but it does seem to be implicitly acknowledge that Wordpress is too cumbersome to maintain and even host yourself.
As appealing as it is to think that if we just have more rigorous processes and infrastructure a crappy system will become more stable, it misses the point I was making.
We do have our sites on functional WP stacks. With enough caching, it's not super hard to make things work (until you hit some edge case with a custom theme/plugin that didn't anticipate a supposedly non-breaking change in the core).
Unfortunately, figuring out why the calendar plugin suddenly isn't producing a functional ical output for windows PCs or figuring out why the s3 offloading plugin has started timing out intermittently becomes a large time investment.
So it's kind of fun to suggest that the people who have the pleasure of servicing WP at a high level are just holding it wrong, but the reality is that there are a lot of talented and experienced people out here working on a platform that fundamentally sucks to work on.
It's not logically inconsistent that, on one hand, people chose it because it's an easy-to-implement solution whose benefit massively outweighs its TCO and, on the other hand, when it break or requires extension it's a pain in the ass for those of us charged with doing that work.
WP is fantastic for the first group you mentioned. I put it up there with Excel, Filemaker, Visual Basic and similar software that democratize software and make it accessible to everyone.
Naturally all of these things have limits and quality issues that some percentage of users eventually face. That is in of itself fine.
The problem arises when it is expected of a professional to integrate or build on top of these.
People come to web developers with quality expectations, unique problems and requirements. But the legacy that is WP puts so many stumbling blocks and gotchas in the way of these goals that it's not worth it to put a square peg into a round hole.
(Similar can be said about common CRM and ecommerce platforms and solutions.)
It's very interesting to me since I have an interest in porting various hitherto "server-side" applications to run in-browser. Doubly interesting because it's the first real product I've seen running SQLite -- so far I've only seen toy demos.
But, wondering about something -- poking around in the code a bit, and realizing I know next to nothing about present-day php, I realized this may be not using the "traditional" SQLite-over-OPFS approach to get persistence?
Actually, after a bit more reading it's not clear to me that persistent storage is available yet via Emscripten.
There is partial support for persistence, for browsers that have origin private file system (OPFS) implemented.
> OPFS is only supported in Chrome-based browsers at the moment like Edge, Android browser. Safari and Firefox users won't be able to benefit from this feature yet
Very interesting, but I don't think sync from MEMFS to OPFS will work for my use case :(
Is there a reason why using OPFS directly from SQLite doesn't work?
The Playground stores more than the SQLite database in OPFS. This includes things like installed plugins and file uploads and other artifacts brought in during boot. If there's enough interest and time I could imagine support being added to separate these, but for now it's easiest to have a single load and store mechanism for everything.
There's a third option supported only in Chrome at the moment which loads a directory from your computer's filesystem, bypassing even OPFS.
> using OPFS directly from SQLite doesn't work?
not entirely following your question. any way you could reword and explain what you were hoping to accomplish?
The reason for this, I believe, is that the primary use case is/was to have the entire file system in memory, including SQLite's database file. This was the original implementation, and is still the default behavior. Persistence was later added as an optional feature.
The good news is that browser support for OPFS seems to be getting better. From the SQLite docs:
As of March 2023 the following browsers are known to have the necessary APIs:
- Chromium-derived browsers released since approximately mid-2022
- Firefox v111 (March 2023) and later
They estimate ~155MB just to get PHP running in Workers. It will be more to load WordPress. And there is extra work to get it running with Cloudflare D1. Plus everything else that likely won’t work by default there (e.g. image uploads).
I did know of those, I'm just assuming its going to cause some sort of problem with network calls and sockets and what not (they mention this specifically as part of the caveats)
Replying to myself. I guess I read that a bit too quickly:
> In Node.js, the answer involves a WebSocket to TCP socket proxy, Asyncify, and patching deep PHP internals like php_select. It's complex, but there's a reward. The Node.js-targeted PHP build can request web APIs, install composer packages, and even connect to a MySQL server.
I use WP all the time for a variety of nearly static sites that I can let someone else non-technical continue to add content. It works great for this purpose. There is nothing close to WP for this purpose.
It does need careful curating of plugins that one uses, set up suitable cloudflare frontends and preventing users from doing something seemingly simple but dangerous.
I get the feeling that a good chunk of the hate comes from people who tried it many years ago; or had needs which don't get met by WP; or received it as a legacy.
A combination of the second, third and a client who insisted on using it for a project where a headless CMS + custom code would have worked a lot better did the trick for me.
Still not really WP's fault, but it doesn't change the fact that I recoil a bit in horror when it's mentioned.
I think the coolest thing about this is you avoid so many round trips to the server. Every single database call and asset request happens on the client! (After you accept the several seconds of loading time.) I think it's also hilarious, because WordPress is probably the most-used MPA solution out there, but this basically turns it into an SPA. And it performs even better than most SPAs, because it doesn't need to do API requests to a server constantly.
I also think the SPA parts of this (the post/page and site editors are very complex React applications) feel snappier in this demo than they do on my local dev environment. Really shows how good SPAs can be when you cut out server round trips.
Disclaimer: I work for Automattic, and this has been a super cool experiment to watch.
No need to dunk on wordpress but it has a lot of history and issues. It would be great to have a modern alternative self-hosted solution that doesn't require static site generation or complex hosting.
Any competitor has a nasty chicken/egg problem to overcome. Wordpress is still hard to avoid because there's a plugin—usually with paid support available—that can do damn near anything. The codebase isn't great, developing against it sucks, and the way it's designed and the official store curated does nothing to prevent some real messes & risks on the database side—but, two days of set-up and $80/m in plugins/themes is just a much easier sell than "OK, first we'll need at least two months of development time..."
There's also the scale-benefit that you can hardly throw a ball without hitting someone who's done Wordpress development, if you do need development work, and Wordpress-focused agencies are abundant, if you'd rather not hire to get the work done. Not true for any up-and-coming competitor.
Designing a system—even an extensible one with plugin and theming architecture—that is a lot better than Wordpress isn't a small task, but is also far from impossible and wouldn't take some super-genius team to accomplish; however, that's the easiest step on the path to actually displacing Wordpress in the market.
See also Salesforce and Shopify, whose app store/plugin ecosystems give them a network effect in their spaces in much the same way - but equally tie them to antiquated API surfaces due to their commitment to backwards compatibility.
Damn right. Forget nocode platforms, you can build sophisticated apps by choosing the right plugin combo. And edit some PHP files if needed (or add your own plugin for bespoke stuff).
There are many functionally perfect substitutes, unfortunately the WordPress value proposition is actually it's ecosystem of plugins, developers and advocacy of it's users.
We've all met the client who wants WP and nothing else. And there are countless times we've rolled a clean new solution out, but the client goes back to WP.
I have seen value in hybrid approaches, a custom app written in some other framework for complex requirements, and a WP instance and connector for content, so the client is comfortable.
Wordpress is the success it is today because over the years, while other CMS kept breaking API, Wordpress remained mostly stable, allowing the development of a large ecosystem of plugins.
Another thing is that Wordpress PHP API uses very little OOP. It's mostly functions + arrays. So people who know very basic programming could write their own plugins, themes and co.
There are CMSes developers want to work with, and CMSes companies want to use. To get into the latter bucket, you have to make a lot of pragmatic choices that causes you to fall out of the former. Also, companies like things that have been around a long time, and such things tend to be old-fashioned by definition.
I am very sure the Github page I linked to doesn’t have any mouse animations. It has a README right on the page, with all the info. It also lets you clone the code and try it out, watch videos and much more.
Did you purposely seek out a different page, see a mouse animation, and then announce to everyone that you did not read further down THAT page because you were distracted by an animation? It seems like a petty thing to announce, but OK.
Sorry, not my intention. I did give feedback on that animation on main project website before (where I always look in addition to a README). Project is nice, animation is awful. My feedback stands: better to remove it.
Really cool tech behind this demo! I wish I could see the realtime php error/warning log (configured to log everything, of course); it would be interesting to see how perfect this simulator is, especially with the SQLite db rewrite.
It's also awesome how easy it is to use this to test out a plugin (or a theme) - you just need to add &plugin=plugin-slug-from-dir where the slug matches the plugin's WordPress.org url and it'll be automatically downloaded and added to the sandbox!
The full query api used to configure the sandbox (tech and loaded env) is documented here [0].
Genuine question, can anyone explain what the practical applications of this are to someone who's never developed with Wordpress? Is this a gimmick? A game changer? A nice-to-have?
Seems like a great way to test plugins and themes in a clean environment. Premium themes could use this as their demo too instead of having to keep a demo Wordpress running.
Then you don't get updates/fixes. And may need to edit the code after acquiring it, to stop license checks. And you'll need to go to the effort of extracting the relevant files from the environment in the browser.
Overall... yeah, sure, maybe, but anyone with any amount of money in their budget for this at all is just gonna pay instead of dealing with that.
Wordpress operates a plugin & theme marketplace. This could be very nice as a way to demo those products without adding meaningful infrastructure development and operational expenses.
[EDIT]: Very nice for WP/Automattic and the people who develop plugins to sell on that marketplace, that is.
The infra cost can be very tiny tho. Digital ocean has 1 click installers for WordPress, which you can use for a few hours and then shutdown and only pay a few pennies.
Now you have to build or configure a system for spinning those up and down at the command of anonymous visitors to your website. Or eat the cost of running a whole bunch of them all the time. And test that system. And monitor it. And secure it (and no matter how well you do that, you're now exposed to a wider set of risks than you were if you hadn't built this thing). And do maintenance development as dumb crap happens under & around you ("fucking [vendor] API broke on us again, with what was allegedly just a bugfix update, that they rolled out at local midnight on a Saturday without warning..."). And have another thing to look at & talk about in budgeting discussions and spending audits.
Yes, of course you can do it, and the cost of running it may be low, but the cost of bandwidth transfer to send the files to browsers so they can run these instead is probably a lot lower, and saves 100%[1] of that initial and ongoing development & operational spending. There's a largish complexity cost to the whole thing, that's all but completely absent if you run it in the browser instead.
The raw cost of running ephemeral VMs isn't the meat of the expenses I meant.
[1, edit] OK, not 100% exactly because they did have to develop this thing the link is about, but that's also a thing that can be used for other stuff, too, not just yet another way to press a button and spin up a cheap VM running Wordpress—this is a unique product, potentially, with many uses, one application of which happens to be filling the role of providing live demos in Automattic's theme/plugin marketplace.
There have been other solutions to run Wordpress locally or hosted without having to setup PHP and MySQL; this appears to be the first such first-party tool for doing so.
RIP static site generators. Just run this in your browser and export a static site. No more complicated setups. No more running ruby in docker or fighting hugo templates. Install the themes and plugins and go nuts!
how would you export a static site if you are running on the browser? you can do some cache management with local storage, or just leverage the browser built in system, but as every rendering session is on the edge, you would not have the benefit of a static site.
Or are you talking about, developing it on the browser, export it and upload it somewhere as static files for internet access (eg a cheap host with no server side languages)?
I'm curious as to how useful this will be. Tying it to SQLite makes it portable, but abstracting it so that it can be used with any db would be far more powerful. Why? Because the SQLite implementation is enough to get it working in the browser, but it does not make WordPress 100% SQLite compatible. For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried.
I installed WordPress in a standard PHP environment, and use the db.php dropin and SQLite compatibility plugin, and actually got WordPress installed on the file system. It works, but when I tried to migrate using all-in-one-wp-migration, it failed.
A neat concept with niche use, but not a panacea for agencies and other devs who need an extensive playground, even if it's self hosted on a persistent PHP server.
> For example, a WordPress site built on MySQL can't be migrated into an SQLite powered WordPress using a common migration plugin. I know, because I tried.
Ok, didn't expect that response! I tried this today.
I admit I didn't try super hard- I have a lot of other things to work on, was a 20 minute curiosity mission. I just downloaded the zip file and grabbed the files out of that. Don't get me wrong- it worked- but I couldn't do an import as mentioned.
If you want lots of detail, I can spend more time on it. Email me at my hn user at the google mail.
the Playground can connect to a MySQL instance when running in a Node environment. it's not supported in the browser because there's no existing mechanism to relay the necessary socket connection there.
WordPress was where I got my start, a while ago now. From poking around with PHP files, to building my own things, to Django, and on.
It would have been inconceivable back then (mid noughties) that the whole thing could be done client side. The Web has come on a long way.
These days I tend to hate WordPress with a passion. Occasionally I will be asked to peek at some technical problem with a WordPress installation and it's never not like opening some awful Pandora's box of out of date, brittle, scary plugins, these days most of which seem to be trying to upsell via ads in the admin.
However I will always be thankful for WordPress and what it enabled in its heyday, and say a silent prayer of thanks every time I think of the people tasked with keeping creaking old sites alive.
Wordpress is one of those things I've plenty of experience with, but leave off my résumé and avoid mentioning to bosses and colleagues, so I won't get roped into that bullshit if it comes up—and it often does, sooner or later.
"Wordpress? I can take a look if you need me to, but I don't really know much about that. I think Fred said something about Wordpress the other day, maybe ask him...."
I've known others who confided they do the same thing. I think it's fairly common.
Plus the PHP market, and especially the Wordpress market, doesn't tend to do great in the compensation department (short of making and selling a successful plugin yourself, anyway) so I'm not exactly eager to put more weeks/months/years of experience in that column when it's not worth much.
The plugin documentation/architecture is a bit gnarly (at least from what I remember). That being said, I feel like most WordPress plugins are awful.
I've sometimes wondered if I could make a better version of X plugin, but I fear I'm missing something - like providing customer support or covering every version of WP.
The customer support and testing are key challenges. You have to be ready to help people with things that aren't even your fault if you don't want your rating on the marketplace(s) to go to shit. Plus you'll need to do lots of sales/ads/marketing to get your zero-ratings zero-downloads plugin off the ground, no matter how good it is. Writing a decent and useful plugin is helpful (almost wrote "necessary", but it's actually not—at least the "decent" part) but isn't sufficient to have a successful plugin.
The plugins are both awful and brilliant at the same time. Well, maybe not so much today. But back before I knew I what I was doing, back before Ruby On Rails really took off, it was pretty awesome to have a Wordpress blog, install a plugin, and suddenly you've got a fully fledged forum section on your site.
Of course the architecture and the mode of installation for those plugins used to be horrendous and fraught with so many problems.
You could look into making single purpose blocks. Then you can get listed in the block inserter upon search an site owners an install your block right from there. Some plugin developers made great inroads in active installs with this more friction less process. Once your block/plugin is installed you can provide links in the sidebar to more expansive plugins or premium versions.
>Plus the PHP market, and especially the Wordpress market, doesn't tend to do great in the compensation department
WordPress work certainly doesn't pay a lot, but for PHP in general there's a large cavern in the middle. You can get very, very high salaries/contract rates as someone experienced with PHP if you are extremely experienced with PHP - specifically because so few people are willing to stick with it to that point. There are just a lot of legacy systems in very large companies that run on it.
So if you already have the experience, it can be worth it. If you don't, then trying to get mid level or even "low senior" PHP jobs probably isn't worth it compared to another skillset.
Yeah, I know there exist high-paying PHP jobs, it's just that finding a PHP job that pays as much as Swift or C# or Java or Javascript or [insert almost anything else here] is usually relatively challenging.
I don't mean that there are zero people making good money in PHP, just that it requires flying a rather tricker and less-certain course to get there, than with other options.
I really might put PHP top-of-page—at least, in some contexts—if marketing myself as a high-priced contractor, for the reasons you mention... but, in hunting for ordinary jobs, I no longer even bother looking at PHP listings. Too much chaff, not enough wheat, and it's been like that for a decade or more. Just way easier to find an employer with compatible pay expectations, with other languages, if we're talking run-of-the-mill jobs. Shorter searches, more-consistent outcomes.
I'd happily put "completed a major Drupal version upgrade" on mine, if I'd ever successfully accomplished it. I think it was 6 --> 7; still gives me the willies to think about that attempt. Seeing that on a resume would be an immediate "wow, this person can handle a complex migration..."
I have spent a significant amount of time developing a product (developer tool) related to WordPress. I have put it on hold recently and I'm trying to evaluate if perhaps I should not do something else instead. I have had this feeling one year ago, that the WP development market may be shrinking and it was further amplified by ChatGPT release. Does anyone feel that way? Is the time still right to develop something, launch it in some 2 years and be sure that if the product has any potential, the market is still ripe in 5 -10 years from now?
I had a love-hate relationship with Wordpress from the beginning.
Yes, I too basically got my true start in dynamic web development by downloading Wordpress, running it under a WAMP/LAMP stack, toying with the code, and eventually writing some plugins. My coding skills back then were TERRIBLE, but even at that time I had a sense that Wordpress was actually quite a mess under the hood. The database design was pretty bizarre in particular. Fast forward almost 20 years later and I'm a senior web developer, and my opinion of Wordpress has not changed. That doesn't mean Wordpress is bad, because on the surface it does its job very well, but it was (and probably still isn't) the pinnacle of well-written software, and it's not a coincidence that there were vulnerability reports being issues all the time for it.
Wordpress was awesome in high school, the times before StackOverflow, MDN, YouTube, etc. It was a "framework" before frameworks were cool. One of the big selling points for Wordpress was that it was far more approachable than competing CMS softwares like Joomla and Drupal. I tried to figure both of those out back then, and I just utterly despised them. You could do a ton with Wordpress out of the box because, for the most part, you just wanted to have pages for things, a blog section, CSS, and a way to extend functionality. That said, I'm so glad I never have to use it again.
>these days most of which seem to be trying to upsell via ads in the admin.
This is my biggest issue with wordpress.
So much that should be in core is left to plugins, some of which are semi-official like jetpack, that it feels a lot more like "open core" than "open source".
We do need to figure out as a community how to deal with that upsell / aggressive plugin problem. I hope we can come up with some norms and standards for what's allowed in our plugin directory that is most customer-centric.
Wordpress is still great for downloading a theme from Themeforest to get brochure style sites (restaurant, simple small business, etc) up and running pretty fast. It is not great (possibly horrendous) for revisiting a few years later when all the plugins/theme/core needs to be updated and a bunch of different people have added custom JS/CSS all over in random places.
It's hard to reconcile "pro web designer" with no-code though. Having said that, my preferred stack for something that involves more than a simple site is Sveltekit, Tailwindcss, & Sanity. But everyone has their own preferences.
In my experience, I bought some pro/high sellers/high rated themes on Theme Forest for 3 sites, but all of them come with a bunch of pre-installed plugins, and was a mess.
Specially two who have a mandatory plugin to edit pages, called WPBakery, damn I hated it, is awful, the native WP editor is miles away (Gutenberg), but the design will brake if you use Gutenberg. Also, this and other plugins do not auto-update automatically, for each update you have to login to a site of the theme seller, download a zip, and update the plugin manually. And also on the admin you always gets upsells of the pre-installed plugins all the time, you can't disable it, sometimes you get a rack of 3 top banners simultaneously.
The end user sites looked really nice tho, but the editing experience was horrible.
Yeah some themes are way better than others, that's for sure. This is one of the cleanest and most flexible that I've used on dozens of sites, getting them up and running with a branded look in 2-3 hours:
The templates on this theme looks really nice and modern, will check it out, but it uses the native WordPress editor or a third party plugin? Also, the pre-installed plugins will update automatically?
Wouldn't say "pro" unless you get strictly mean design and not functionality. In which case I'd have recommended Photoshop which is what I used for design only 20 years ago, but I think the UX folks like Figma or something these days.
I might have misinterpreted your comment, but there are plenty of site builders for WordPress (WYSIWYG-ish editors). Granted, you can only do so much without knowing CSS.
Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about. Beginners tend to want a hard line with "coding" on one side and "not coding" on the other, but that's not a very useful way to model interactions with computers.
It's more of a spectrum of complexity, with WhatsApp on one side and full-blown software engineering on the other. In the middle is a vast gray area, much of which could very legitimately be referred to as programming, but which equally someone might consider to be simply using an application (like Excel).
Further, what tools you use is less significant for whether something should be considered coding than is how you're using them. I'm a professional web developer, and the way that I and my colleagues use CSS is unquestionably coding. On the other hand, someone who's just styling the fonts on their squarespace page might not consider what they're doing to be coding and that's also fine.
> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about. Beginners tend to want a hard line with "coding" on one side and "not coding" on the other, but that's not a very useful way to model interactions with computers.
I disagree. There's a meaningful distinction between what is code and what is formatting because the concerns are quite different. This distinction is more apparent on frontend applications where the code bits are actually dealing with the fact that there's a single process doing all these seemingly asynchronous things, the use of very infrastructure-like components (eg: pubsub implementations, stores, etc). Formatting and design doesn't need to deal with the how, it needs to deal with the why. The powerhouse of a developer is knowing both.
Trying to shoehorn peoples attitudes into discriminatory experience levels based on your perception of that rhetoric is an odd behavior unto itself. These topics merit talking about because ultimately they affect how we think, reason, and organize on different layers of projects.
You actually somewhat proved my point with your example of CSS. It more recently became capable of more "code like" qualities, but it can definitely be used for just styling and formatting. Without discussion someone may never know the difference or why you'd use some of CSSs computational capabilities. Another crossover is YAML; YAML can be very markup language oriented but it also supports aliases, pointers, etc.
I agree that the distinction you're drawing is valuable, but it's not a distinction between "code" and "not code": both aspects are defined with a language that the computer parses, interprets, and executes on. One happens to be a declarative language that deals with the what and why, and the other an imperative one that deals with the how.
> Trying to shoehorn peoples attitudes into discriminatory experience levels based on your perception of that rhetoric is an odd behavior unto itself.
I think this is a bit of an overreaction to my words. Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things. It's also okay (and desirable!) for those of us who do know better to help novices to learn the material and the culture better than they now do. And the fact is that "what counts as coding" is not a discussion that serious developers have between themselves.
> These topics merit talking about because ultimately they affect how we think, reason, and organize on different layers of projects.
I believe that "code" and "not code" aren't useful categories for dividing up CSS, HTML, YAML, JavaScript, Haskell, and C. We're capable of enough nuance to distinguish between them while still acknowledging that they're all languages which we use to tell a computer what to do. Let's talk about them in that nuanced way, not try to split the world into a code/everything-else binary.
> both aspects are defined with a language that the computer parses, interprets, and executes on.
Sure, but low order definitions of "code" being something that takes an input and produces a different output do not relate to the real world unless you believe modern word processors require programmers.
> Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things.
I think you're missing the point that the statement you made applies to a wide variety of discussion, not simply binary code|not_code discussions.
> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about
This statement would also imply anyone trying to sort out coding from formatting, from styling as a novice. There's a reason we separate these activities in programming that has to do with how you model applications not to mention empowering the people who have expertise in doing them.
While I agree that code|not_code is not helpful, trying to make the definition of code so low order that it's meaningless is also not helpful. There's a bar there that belongs in the middle and I think you both have missed it. I was merely calling out equally harmful wording that you were using to correct harmful wording.
It's not "code" and "not code", it's "software engineering", "programming", and "using a computer".
So many more people program computers than think they're programming. Anything that allows a computer to reproduce what would otherwise be a manual set of steps is programming. Made a bookmark in your browser? That's programming. Excel is definitely programming. And have you ever tried styling a web page using only the browser dev tools? CSS is hardcore programming, and people who claim otherwise are often snobs who find CSS too hard so they call it "not programming" in order to feel better about themselves.
Software Engineering is a whole different ball game. It's not so much what as how and actually the "programming" bit is almost always the easy part. That's why Software Engineers run away when someone asks them to look at "this really useful spreadsheet than $PERSON made" -- chances are that person doesn't think of themselves as a programmer, but that's what they've been doing and they're actually really good at it. But only in isolation, while Software Engineering involves working with whole systems and (more importantly) both the people who use them and the people who work on them.
This would be killer for static websites, make all your modifications on the /admin endpoint and then deploy to your static page host, using a plugin like staatic.
Hijacking the spirit of this link to just saying that I'm very sad about what Wordpress has become.
In my mind it was a very good website / blogging platform, with a clear and functional markup / raw code editor.
Building themes was easy, and so was the plugging ecosystem.
I installed the latest version ~6 months ago, and I found myself overly confused by the million of options, the poor functionality of the block system, and the overall bloating of the software. It just run slower than 10 years ago.
The templates and plugin available out there are extremely complex and a lot harder to read, code wise.
I assume is a 'dead by 1000 papercuts, or customer demands, in this case' but from a product standpoint, I'd really love to know who are the personas that this new interpretation of wordpress cater to.
This looks interesting, but a better option in my opinion is to use the Local app (on Mac) to install a lightweight VM running WordPress in seconds. Then you have all the tools, for example phpmyadmin and MySQL database management, all running locally on your Mac, and with Internet access. Open Source and free to use.
Just tried installing woocommerce and adding a product, but got a bug:
Warning: require(/wordpress/wp-includes/post.php): Failed to open stream: No such file or directory in /wordpress/wp-settings.php on line 2
Fatal error: Uncaught Error: Failed opening required '/wordpress/wp-includes/post.php' (include_path='.:') in /wordpress/wp-settings.php:2 Stack trace: #0 /wordpress/wp-config.php(11): require_once() #1 /wordpress/wp-load.php(2): require_once('/wordpress/wp-c...') #2 /wordpress/wp-admin/admin.php(2): require_once('/wordpress/wp-l...') #3 /wordpress/wp-admin/post.php(2): require_once('/wordpress/wp-a...') #4 {main} thrown in /wordpress/wp-settings.php on line 2
There has been a critical error on this website.
I wonder if this could be useful for penetration testing, considering the ease of setting up different plugin combinations on different PHP and Wordpress versions? Or stack used to run it is way more different from real one?
The question is — how does your WebAssembly in the browser run a server that can listen for incoming requests and serve the page? I don’t get that part at all.
WordPress is an utter crap in terms of DB design and code. Most plugins are even worse and the whole thing is a total mess.
Yet, if you have a client needing this and that you can have them started really quick with WordPress. Need an e-commerce? There are plugins for that. Need an event management? There are plugins. Need an obscure app for truck drivers to share their CVs and communicate with clients? There is probably a plugin for this. If there isn't, you can use one and modify it - it's all open source.
It's definitely wild and ugly and crap, and sometimes is totally pathetic but the ecosystem is huge and has everything for everyone.
The backend is a terrible mess. But most of the time WP sites are served as cached static assets to the end user so you can still get the load times pretty good (despite the dumpster of a backend/DB).
When they are content sites, yes. When there is ecommerce and other dynamic stuff - not so much. I'm often optimizing WP sites after the arsenal of the typical developer - caching, redis object caching, etc - has been wiped off. The db structure and poorly optimized queries are a real pain.
Its cool and I get it, but how is this useful other than good marketing? If an app's code is run on a device, any rooted device could just modify its memory and do whatever it wants. Just ask a game developer about the infinite anti-cheating war that they deal with.
What a bizarre attitude to have. You could also save tons of seconds by not using indents in Python or brackets in JS. But then you would also not have working code.
Php & WordPress were fun. With that ugly php tag you could get pretty much everything working on the web.
All you had to do was edit, save & refresh. No rebuild of code, server restart, compiling Just edit & save.
Did it have the tendency to get ugly? Sure. But it was easy, quick and fast. Not every blog and needs a git flow, united, e2e, type-safe double encrypted dev environment.
Both PHP & WordPress got shamed for their dirty nature so much that they are in identity crisis. PHP tries to mimmick Java as much as possible. WordPress plugin structure is a disaster. Having to run an entire npm project for every plugin, no easy data saving helpers, etc. Let alone the ux-disaster of the block Editor.
Feels like the php decade is truly over. And it was php that killed itself.
> All you had to do was edit, save & refresh. No rebuild of code, server restart, compiling Just edit & save.
The majority of webdev is either exactly like that, or effectively like that with very fast rebuilds/restarts. It's not really something unique to PHP.
In fact in your modern stack you'd probably have autosave, and most importantly "fast refresh", so you don't need to manually refresh and you don't lose state.
Yes! Ignorance absolutely explains its "market share". There's no reason for anyone to be running this trash in 2023. I'm surprised Shopify hasn't completely wiped out Wordpress for ecommerce yet. For all other kinds of websites, they don't even need a CMS. Blogs are dead so it's all niche sites that demand custom web dev by now.
Also imagine the software layers at play here. Whole PHP Interpreter plus whole thousands of lines from WordPress codebase plus SQLite.
Amazing when that's all so much totally useable.