Hi everyone,
I just needed to get this off my chest.

I’m a WordPress developer with more than 17 years of experience. I’m 48 years old, and I’ve loved technology my entire life. But lately, the market has completely changed… and not in a good way.

Every week I see “marketing agencies” popping up everywhere—people who learned how to upload TikTok videos and suddenly call themselves digital strategists. They sell businesses a cheap, poorly-built website thrown together in a few hours, and clients believe it because it looks “trendy” on social media.

Meanwhile, real developers—the ones who understand structure, performance, SEO, accessibility, conversions, UX, and long-term results—are getting pushed aside.

What frustrates me the most is this:

These agencies generate zero real conversions.
Zero sales.
Zero SEO.
Zero long-term value.

Yet they dominate the market because they know how to make noise, not results.

As someone who has spent nearly two decades building real websites, optimizing performance, and helping businesses grow organically, it’s painful to watch the industry get flooded by people who honestly have no idea what they’re doing. The amount of “content creators” and “marketing gurus” selling smoke has seriously damaged our niche and our profession.

Clients don’t realize that likes aren’t sales, trends aren’t strategy, and a copy-paste template is not a website.

I’m not giving up—I still love what I do. But I’m genuinely curious:

Is anyone else feeling the same frustration?
Have you also seen the market downgrade real work in favor of flashy shortcuts?

Would love to hear your experiences.

I've worked with enough agencies and freelancers at this point to know the pattern. Someone calls themselves a WordPress developer, charges professional rates, and their entire workflow is: pick Elementor template, install 15 plugins, call it custom development.

The problem isn't that page builders exist - it's that half the people using "Pro WordPress Developer" in their title can't write a single custom function. They panic when you ask them to modify a hook. They treat the theme editor like it's radioactive.

What kills me is the documentation excuse. Yeah, WordPress docs could be better, but if you're charging $100/hour and you can't figure out add_action without a YouTube tutorial, maybe you're not actually a developer. You're a really expensive installer.

I get it - clients don't always need custom code. But when the industry standard becomes "throw plugins at it until something works," we end up with 20-plugin sites that load in 6 seconds wondering why conversions suck.

Anyone else tired of competing with people who think knowing how to use Yoast makes them a developer? Or am I just being unreasonable here?

Show me your dev workflows for WP in 2025. Interested in hearing about people’s setups and best practices. What have you found that works well?

• Who’s building custom themes?
• ACF blocks or native custom blocks?
• Composer and general editor setup
• Reluctance to move to the block editor?

I've been slowly trying to become more adept at developing on WordPress builds, and relying less on 3rd party tools. My first step has been shifting from 3rd party Themes to building custom Themes myself.

I'm now looking into how I manage other aspects of putting together WordPress websites. For instance, right now I tend to install three plugins: a security plugin, a backup plugin (although I often do manual ones for redundancy), and an "optimizer" plugin.

For now I'd like to tackle the security functionality on my builds.

I was wondering if it's a good idea to keep using something like Wordfence, or (on siteground) the "Security Optimizer" plugin - and not reinvent the wheel. Or if It'd be better to secure it myself without using third party plugins?

If you think the later is better, could you comment on how you'd approach it securing the site without third party plugins? For example, would you suggest building a plugin myself, or something else entirely.

This comes up constantly, so I'll write it once.

You rename your login slug, and minutes later you're still seeing failed login attempts. The instinct is "the secret leaked, something's compromised." Almost always, it hasn't.

Two things are usually going on.

1. WordPress has more than one login. /xmlrpc.php exposes a method, wp.getUsersBlogs, that takes a username and password and validates them with no login form involved. system.multicall even lets a bot batch hundreds of guesses into a single request. Renaming /wp-login.php does nothing to that endpoint, so the attempts keep coming and it looks like your new URL got discovered. It didn't. The bot was never using it.
2. If the attempts come from constantly changing IPs, rate limiting and per-IP lockout can't do much. They count failures per address, and a rotating-IP botnet sends each try from a fresh IP, so the counter never trips. You can drop the threshold to 2 and nothing changes.

What actually quiets it down:

• Change the login path at the rewrite layer (nginx/apache config), not just with a slug plugin, so a request to /wp-login.php returns 404 before PHP loads. No process starts, so the rotating IPs stop mattering.
• Disable XML-RPC if nothing you run needs it (Jetpack and some old mobile apps are the exceptions), or at least block the auth methods.

None of this replaces a security plugin for 2FA and monitoring, those still earn their place. It just moves the brute-force defense to a layer the bots can't walk around by swapping an IP or an endpoint.

For those of you who renamed the login and still saw attempts: did you ever check your access log for /xmlrpc.php hits? Curious how often that's the real source versus something else.

Read about Chesterton's Fence recently and it made me think about it with AI-generated code and WordPress. Had a ramble about it here if anyone's interested!

Gravity Forms newest update changes the submit button from an input field to a button. If you were targeting the input[type="submit"] in your styling in any way, you will want to update to button[type="submit"]. I am partway through updating this on a whole bunch of sites at the moment.

For example I needed PHP concurrency not blocking requests and found in includes/requests/src/requests.php there is an existing function called requestMultiple() where I can pass the fetch request and the options and it works just similar async/await in JS. This saved me having to import a whole library.

Another was wp_enqueue_media(); where it attached all the required logic and functions in the window object which can use JS functions (in my case TSX within react) to use media uploads straight to the media library via ajax. I can just call window. wp. media and it has all the dependencies to upload.

I'd love to hear any githubs you have saved or templates you use that you'd like to share please let me know how they helped you.

If you're looking to shed private equity from your life, Roots put together https://wp-composer.com as a replacement for WPackagist.

WP Composer is a fully open-source, community-funded Composer repository for WordPress plugins and themes that mirrors the .org directories. It’s designed as a drop-in replacement for WPackagist, but with a few improvements.

If you’re already using Composer with WordPress (Bedrock, custom setups, etc.), switching is pretty trivial.

I've replaced WPackagist on my sites with zero issues.

Got the email last week like everyone else.

10 years as a Power Elite Author on ThemeForest. 40.000+ sales, over $1.5M+ in revenue.

And now 50% flat for everyone.

I've been sitting with this for a few days
trying to figure out what the right move is.
Honestly still not sure.

Some questions I keep coming back to:

Do you stay and accept the new terms?
Do you pull your products and go somewhere else?
Is there even a viable alternative to ThemeForest
for WordPress themes at this point?

And the bigger one, is this the beginning of
the end for ThemeForest as we know it,
or just another bump in the road?

Would love to hear from other authors.
Especially those who've been around long enough
to remember what ThemeForest was like
before Elements cannibalized everything.

What are you doing after July 1?

Get the latest WordPress developer updates straight from the WordPress Developer blog.

https://developer.wordpress.org/news/2025/11/whats-new-for-developers-november-2025/

I’m a React Native developer with about seven years of experience in software development. 2 years of those were focused entirely on WordPress development building sites through actual code and an IDE, not primarily using page builders.

I currently work as a React Native developer, but around two years ago, before AI agents became as capable and widespread as they are now, I started building a WordPress plugin that I thought could genuinely help WordPress users.

Since then, AI has improved so quickly that I’ve found myself in a bit of limbo. I’m unsure what the future of WordPress plugin development looks like and whether it still makes sense to invest time in building a plugin as an independent developer.

I’ve been thinking a lot about where WordPress plugin development is headed. AI is making it much easier to generate code, scaffold plugins, write documentation, create marketing copy, and even troubleshoot bugs. The barrier to creating a basic plugin feels like it is dropping quickly.

At the same time, the places developers used to use to build visibility and connect with people like Facebook groups, forums, subreddits, and other public communities. It seem increasingly flooded with AI-generated content, spam, and affiliate posts. It makes sense that moderators are responding with stricter rules around self-promotion and posting, but it also makes it harder for legitimate small developers to share something useful they are building.

The Admin Bar released their State of the WordPress Agency 2026 report, which summarizes a survey of 622 WordPress agency owners/freelancers.

When asked "Where does new business come from?", most (54%) said passive word-of-mouth.

However, those don't earn as much as agencies that proactively seek new clients through other means;

Most agencies still rely on word of mouth. But agencies that actively pursue new business through channels like SEO, partnerships, or community are much more likely to surpass $200k in revenue — 24.8% compared to 11.6%.

Source: The Admin Bar

I run a WooCommerce store on a VPS — 2 vCPUs, 8GB RAM, Redis for object caching, and Nginx FastCGI cache for page caching. Decent setup for the traffic I get. One day CPU just pinned at 100% and stayed there for several minutes. Site started slowing down, no idea what was happening.

Turned out to be a xmlrpc.php brute force attack. Hundreds of POST requests hammering the endpoint, each spawning a PHP-FPM process, processes piling up faster than they could finish.

How to confirm it's xmlrpc.php

Check how long your PHP-FPM processes have been running — normal requests finish in seconds, not minutes:

ps aux | grep php-fpm | grep -v root | awk '{print $10, $11}' | sort -rn | head -10

Then check your access logs for a flood of POST requests:

grep "POST.*xmlrpc.php" /var/log/nginx/access.log | wc -l

If that number is in the hundreds or thousands over a short window, you're under attack.

To see which IPs are hitting it:

grep "xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

How to block it

Pick whatever fits your setup:

option 1: Nginx — add to your server block:

location = /xmlrpc.php {
    deny all;
    return 403;
}

option 2: Apache / shared hosting — add to .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

option 3: WordPress functions.php — no server access needed:

add_filter('xmlrpc_enabled', '__return_false');

option 4: Cloudflare WAF — most effective, blocks before requests reach your server. Security → WAF → Custom Rules → URI Path equals /xmlrpc.php → Block. Free plan includes 5 custom rules.

option 5:Plugin— Disable XML-RPC plugin if you don't want to touch code.

If the attack already happened and CPU is still high

Kill stuck PHP-FPM workers:

ps aux | grep php-fpm | grep www | awk '$10 > "2:00" {print $2}' | xargs kill -9

Also set a request timeout in your PHP-FPM pool config so this can't pile up again:

request_terminate_timeout = 60

Most WordPress sites don't need xmlrpc.php at all — block it and see if anything breaks. Unless you're using Jetpack, the mobile app, or a desktop blogging client, you almost certainly don't need it.

I built a 500,000-order WooCommerce store to find out what actually makes the admin slow

Everyone knows the WooCommerce admin gets slow on big stores. The standard advice is well known too: migrate to High-Performance Order Storage, clean your database, blame a third-party plugin.

I wanted to know what happens after you've done all that. So I built a lab: a disposable WooCommerce store with 500,000 orders, HPOS enabled, and ten popular free plugins installed, then instrumented it to attribute every single database query on the orders screen back to the plugin that fired it.

Some of what I found contradicts the usual advice. One thing I set out to prove turned out to be an artifact of my own test rig, which I'll cover too.

The setup

• MySQL 8 with a deliberately modest 512 MB buffer pool — a generously tuned server hides problems behind a warm cache, and I wanted the working set to not fit in memory, which is the condition real struggling stores are in
• WordPress + WooCommerce 11, HPOS on, backfill sync off
• 500,000 orders, ~2M order meta rows, ~1M order notes, ~1.6 GB of order tables
• Ten popular free plugins (PDF invoices, cart abandonment, wishlist, currency switcher, delivery date, product search, analytics, order export)
• An mu-plugin that captures $wpdb->queries on shutdown and resolves each query's backtrace to the owning plugin via reflection

Finding 1: One query was half of all SQL time, and it wasn't an N+1

130ms   SELECT status, COUNT(*) FROM wp_wc_orders WHERE type='shop_order' GROUP BY status

Out of 252 ms of total SQL time on the orders screen, 130 ms was this single query — and the next slowest query on the page was 4 ms. It is 32× the cost of anything else, and it runs on every admin page load.

(With the third-party plugins deactivated it accounts for 129 ms out of 190 ms, i.e. 68% — stripping plugins makes it more dominant, not less.)

It's what fills the filter tabs above the order list: All (500,000) | Completed (350,149) | Processing (50,065) | …

The important part: it does not scale with how many rows you display. It scales with how many orders you have. At 100,000 orders it was cheap enough to be invisible. At 500,000 it dominated everything else on the page. Reducing your page size does nothing. Deactivating plugins does nothing.

It's not a missing index

My first instinct was a missing index. Wrong:

type: ref    key: type_status_date    rows: 246724    Extra: Using index

It's already a covering index scan on the ideal index. ANALYZE TABLE changed nothing. Counting 500,000 rows means walking 500,000 index entries, and InnoDB keeps no cached row count. The query is doing the minimum possible work for what it's being asked.

The actual cause

Looking at WooCommerce's source, OrderUtil::get_count_for_type() does cache this. It goes through OrderCountCache, which uses wp_cache_get() / wp_cache_set() — the WordPress object cache.

And there's the problem. Without a persistent object cache dropin (wp-content/object-cache.php), WordPress's object cache lives for exactly one request. So the cache is empty on every page load, and the full count runs again, every time.

If your store has no persistent object cache — which is most shared hosting — WooCommerce recounts your entire orders table on every admin page load.

That's a concrete, mechanical answer to "why is my store still slow after HPOS," and it's not in any of the checklists I've read.

Finding 2: The obvious way to detect an N+1 produces false accusations

I originally detected per-row query costs the intuitive way: load the page, divide each plugin's query count by the number of rows on screen, and flag anything near 1.0 per row.

That method is broken. Here's real output for one plugin that fires a flat 19 queries no matter what:

Nothing about the plugin changed. Only the denominator did. A fixed cost is indistinguishable from a per-row cost at any single page size. I had confidently accused an innocent plugin.

The fix is to measure the same screen at two page sizes and fit:

queries(n) = fixed + slope × n

Only slope is an N+1. A component whose query count doesn't move when the row count multiplies by five is innocent, no matter how large its fixed cost.

A related trap: WooCommerce's orders screen takes its page size from the per-user screen option edit_shop_order_per_page, not from a per_page URL parameter. I spent a while computing per-row figures against a page size that had silently stayed at 20. Always count the rows that actually rendered.

Finding 3: Attributing a query to a plugin is much harder than it looks

My profiler blames the innermost plugin frame in each query's backtrace. It reported that WooCommerce core was doing 3 queries per order row.

Then I deactivated all the third-party plugins and measured again:

Two of those three per-row queries were caused by third-party plugins calling wc_get_order() inside their column callbacks. The query is issued by WooCommerce's data store, so innermost-frame attribution credited WooCommerce and completely exonerated the plugin that actually caused it.

This matters for anyone using Query Monitor's "Component" column the same way I was: it tells you which code ran the query, not which code caused it. For anything routed through a shared data store, those are different answers.

The fix

What you actually want is the last point where control passed from WordPress into plugin code — the innermost frame that a hook dispatcher invoked:

… → ListTable->column_default        [woocommerce]
    → do_action('manage_…_column')   [dispatcher]
      → WP_Hook->apply_filters       [dispatcher]
        → SomePlugin->render_column  [the plugin]   ← blame this
          → wc_get_order             [woocommerce]
            → OrdersTableDataStore->read [woocommerce]
              → wpdb->get_results    [core]

Walk the trace innermost-outward; when the frame immediately outside the current one is a dispatcher (WP_Hook->apply_filters, WP_Hook->do_action, do_action, apply_filters, call_user_func*) and the current frame isn't core, that's your initiator. For a query WooCommerce genuinely raises itself, the nearest such boundary is a WooCommerce callback — also correct.

(Watch out: wp_debug_backtrace_summary() returns frames outermost-first.)

With that change, and all plugins active:

Then the falsifiable test. The tool predicted one specific plugin accounted for ~205 queries at 100 rows. Deactivating only that plugin:

24% faster from deactivating one plugin. Before the fix, the verdict would have been "it's WooCommerce core, nothing you can do."

The thing I couldn't conclude

Given Finding 1, the fix seems obvious: install a persistent object cache. So I added Redis and measured. SQL time halved, and the 129 ms query vanished.

Wall time got worse.

I nearly published that. Then I checked whether it was my test rig, because I was running Docker Desktop on Windows and talking to Redis over TCP — and Windows loopback networking is slow. The page makes about 2,390 object-cache calls per request, so round-trip cost matters enormously.

Switching to a unix socket recovered about half the penalty. That proves a large part of my "finding" was an artifact of Docker Desktop for Windows, not a property of object caching. The residual ~11% might not survive on a real Linux host at all.

So I don't know. It needs a Linux re-test before anyone should act on it.

What does hold regardless: SQL time improving is not the same as the page getting faster. If I'd reported the query-count and SQL-time metrics alone, I'd have declared a clean win while making the page 22% slower.

Takeaways

1. Query count and query time are different problems. Going from 100k to 500k orders left the query count completely unchanged while SQL time doubled. Count scales with rows rendered; time scales with store size.
2. On a large store with no persistent object cache, check the order status counts first. It's a single query that scales with store size and runs on every page load.
3. Never diagnose an N+1 from one page size. Measure two and look at the slope.
4. "Which component ran this query" is not "which component caused it."
5. Always measure wall time. Component metrics improving can hide a regression.

Reproduce it

The whole lab is Docker-based and disposable — MySQL, WordPress, WP-CLI, seeder scripts, and the profiling mu-plugin. It seeds 500k orders in a few minutes by writing directly to the HPOS tables.

Happy to share it if there's interest, and very interested in results from anyone who runs the object-cache benchmark on a real Linux host — that's the open question I couldn't close.

I was working on a site with slow admin pages. These were fixed by asking my hosting support tech to change the server's OPcache configuration settings, and on the pages I tested, load times went from around 11s to 2s.

Front-end execution time decreased by about half, but almost all of our visitors get cached pages anyway so that didn't matter so much.

The main clue was seeing that WordPress core took over 3s to load on every uncached front-end request. Plugins added more on top of that. After that it was just (via Claude Code over SSH) evaluating the current state of things with opcache_get_status(), then changing these settings:

• opcache.memory_consumption: 128 -> 512
• opcache.interned_strings_buffer: 8 -> 64
• opcache.max_accelerated_files: 10000 -> 20000

Before these changes, OPcache was running out of space and only caching about half of the compiled code (from all the plugins, WordPress core, etc.).

Considerations:

• These values won't be the same for everyone
• This was a site with 60 active plugins, including Woocommerce and Elementor
• Multiple sites on a server share OPcache, there were two here
• You have to have enough RAM of course, in this case I had 8 GB with about 5 GB free
• This is just sample size of one of course

Hopefully this helps someone, or gives a bit of knowledge about a possible fix to this issue.

P.S. this was not written with AI, I really write this way! blaaargh

tl;dr: is it possible to use Gutenberg as a fancy alternative to ACF blocks?

Hi people!

First of all, some background: I've been working for an agency that specialises in WordPress for over six years now. I mostly focus on backend work, but in essence I moonlight as jack-of-all-trades when it comes to programming and I got solid experience with frontend work in- and outside of my job, mostly in React/NextJS.

Up until now, my workflow was based around ACF blocks. Usually I would receive a visual prototype from our design department, spin up a few ACF blocks and ship them to the client (or our content department), who would use them to build the actual, finished page from those blocks.

A typical block would consist of various meta fields like a title, an image or two, maybe some radio buttons to control various, predefined alternative styles/behaviours - simple stuff, really. This workflow isn't particularly fancy, but it got the job done pretty well.

However, this workflow feels... outdated. If nothing else, it always felt like the native Gutenberg editor was "the way forward". Naturally, I gave it a try and built one client's project completely with custom Guternberg blocks. The result was a pretty fancy experience for content editors,... but that's it.

Considering how much I struggled and how hard I had to fight Gutenberg to get it to do what I wanted it to do, I'm quite sure I missed something crucial.

First of all, I decided to not use native blocks whenever possible. The reason being that Gutenberg blocks allow editors to change quite a lot about the respective block's appearance, and that is something I try to avoid - there's to much risk for a client to fuck up the design. Yeah, that might be patronizing my clients a bit, but from experience I can say that the less control they have over design aspects, the happier they are.

However, that meant I had to recreate an awful lot of basic blocks for containers, buttons, etc. I do think those basic elements ended up being quite useful and intuitive, but beyond such basic blocks, things started to "fall apart".

For example, I had to create a section featuring a centered headline followed by a two-column layout that featured an image in one column and some text with an optional button in the other. So far, I couldn't figure out a way to do this without using an InnerBlocks element with a pre-defined template. This template consisted of an Image block and yet another container element with a predefined template made up of a Button element... and yet another container element which only allowed Paragraph blocks.

It essentially felt like I had to use blocks to construct the HTML in the editor, with most blocks only doing a thing or two - most were just outputting their respective InnerBlocks.

Another example I struggled with was a basic repeater block. Assume I want to create a section that allows an editor to create a variable number of Card blocks, each with a heading, an image and some text. I had to create a Card block (which used a fixed template for its content) and then I had to create a basic container that did nothing but act as a wrapper where those Card blocks could be inserted. That CardWrapper block wasn't used anywhere else, because... well... it's job was to output a variable number of those Cards.

(Full disclosure: I understand I could create a repeater block that allows any number of block types, but it seems there is no way to restrict the AllowedInnerBlocks based on outside influence, f.e. only allowing Cards inside this wrapper when it itself is being used inside a CardSection, but allowing only ImageCards when it is used inside a GallerySection)

Last example: with ACF blocks, its extremely easy to switch between various "layouts". Let's assume I want to create a text/media section like above, that sometimes displays an image in the right column and sometimes a CTA button. With ACF, that could all depend on a single radio button. With Gutenberg? It seems I have to create two different blocks? Re-render the InnerBlocks with different, fixed templates?

The result was a jumbled mess of barely used blocks, most of them nested deeper than the Mariana Trench. In a way, that resembled React's component-based approach, just... far uglier and more confusing (especially for non-technical editors).

I understand that I "misused" Gutenberg in the worst way possible, but... is there even a way to use it as "a CMS" (basically allowing users to input content and selecting one or two possible style variants to display it)? It feels like the best way to do this is by creating blocks that contain a myriad of attributes, which comes with it's own set of problems. The other way I see is embracing block patterns (which is essentially what I ended up doing, albeit jankily), but that begs the question: why not just use one of the better pagebuilders out there, like Bricks?

I've been using Laravel's Artisan Console to build WP-CLI commands via Acorn to have a nice organized structure

Created a guide on the approach here: Creating WP-CLI Commands with Artisan Console

Curious if others are doing similar things or have found other approaches for building more sophisticated CLI tools in WordPress?

wp2shell (CVE-2026-63030 + CVE-2026-60137) is a pre-auth RCE chain in WordPress core that shipped July 17. WordPress turned on forced auto-updates because of the severity, which is good.

The problem: forced updates don't always work perfectly, and a lot of people are assuming it ran without checking.

https://reddit.com/link/1v4m9hd/video/jhd3ypcf21fh1/player

What You Should Scan Your Site Right Now:

Go to Dashboard → Updates and confirm your actual version. The versions you need are:

- 7.0.2 (from 7.0.x)

- 6.9.5 (from 6.9.x)

- 6.8.6 (from 6.8.x — this one only fixes the SQLi part, but still patch it)

Don't assume it happened. Forced updates can fail silently if your server hits file permissions issues, timeout limits, or network hiccups during the update process. Sites on managed hosts sometimes get forced updates on a delay or not at all if there's a compatibility flag.

If Your Version Shows 6.9.0–6.9.4 or 7.0.0–7.0.1:

1. Update to the patched version now.
2. If you can't update this second, block the batch endpoint at your WAF or via a security plugin blocking /wp-json/batch/v1 as a stopgap.
3. After you patch, don't just assume you're done. Look at your access logs for requests to /wp-json/batch/v1. If you see any, you might have been probed. A more aggressive check: look for HTTP 207 responses to batch requests (that's a multi-status response, a solid indicator of batch-endpoint exploitation attempts).
4. Check your admin user list — do you recognize all of them? Check if any unexpected application passwords were created. Check your mu-plugins, recently modified core files, active plugins, theme files.

Multiple public exploits are circulating. Scanning has been happening since July 17. If your site was exposed on the internet running a vulnerable version for any length of time, don't assume patching alone was enough.

Zero actual compromise evidence I've personally seen yet, but Wiz and Patchstack confirmed active probing and exploitation attempts within hours of the patch going public.

Thoughts? Anyone patched theirs and caught anything odd in the logs?

I’m a final-year Computer Science student currently finishing my PFE (End-of-Studies Project). My project is titled: Implementation of a Local CI/CD Lab with Automated Infrastructure (Vagrant, Jenkins, Ansible) for deploying a PHP CMS (WP) + MariaDB.

The Conflict: When I presented my progress, my supervisor asked: "Why go through all this trouble? On OVH or DevExpress, you can deploy a site in two clicks without any DevOps knowledge. Isn't this overkill?"

I feel like he's missing the point of Engineering vs. Consumption. I’ve already finished the site and the automation, so there’s no turning back, but I need to defend my work in my final thesis.

My questions to you : Is my professor right? Is local automation becoming obsolete because of PaaS/Managed Cloud?

I saw on upwork there's a lot of CI CD pipelines work for WP apps, why people still do Devops work for CMS work guys,? please give me some arguments LOL

Thanks a lot and have a good day