ASAP update is advised to patch this WP core vulnerability:

Affected versions 6.9 (patched with 6.9.5 update) and 7.0 (patched with 7.0.2 update)

Article on the topic:
https://thehackernews.com/2026/07/new-wp2shell-wordpress-core-flaw-lets.html

Elementor 4 is out, but it's got the ancient Extras for Elementor plugin that it's heavily reliant on (and hasn't been updated since 2024).

Does anyone know if it works with Elementor 4? I don't really want to try since it's already known EoL.

This guide installs a tuned WordPress stack on a minimised Debian 13 VPS, picking up from the end of the https://lowendspirit.com/discussion/10684/debian-13-minimum-ram-and-disk-38mb-guide-part-1-running-nothing#latest guide. Every command has been run on a real instance and the results recorded.

AI USE Declaration: md formatting, spelling, grammar done with Claude, the work and methods are my own.

The stack is Nginx with FastCGI caching, MariaDB 10.11 LTS, and PHP 8.4-FPM. The target is the lowest practical idle RAM footprint on a 256MB VPS without sacrificing WordPress compatibility.

Before

End state of the Debian 13 minimisation guide.

               total        used        free      shared  buff/cache   available
Mem:             213          38         141           0          41         174
Swap:              0           0           0

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       2.8G  275M  2.4G  11% /

Even if you did not follow that guide, this should give you some ideas on reducing the footprint for your small WordPress setup.

Stage 1: Install MariaDB 10.11 LTS

Debian 13 (trixie) ships MariaDB 11.8. This guide uses MariaDB 10.11 LTS from the MariaDB Foundation repository. On this configuration, 10.11 uses 57MB RSS at idle versus 68MB for 11.8.

Installing 10.11 on Debian 13 requires three steps before the main package install: a compatibility shim for libaio1 (renamed in Debian 13's library transition), the MariaDB Foundation repository, and an apt preference to pin the packages.

libaio1 compatibility shim. Debian 13 renamed libaio1 to libaio1t64. The MariaDB 10.11 bookworm packages declare a dependency on the old name. Create a symlink so the library is found at runtime, then build a dummy package to satisfy the dependency declaration:

apt-get update
apt-get install -y gnupg equivs libaio1t64

ln -s /usr/lib/x86_64-linux-gnu/libaio.so.1t64 /usr/lib/x86_64-linux-gnu/libaio.so.1
ldconfig

cat > /tmp/libaio1-compat << 'EOF'
Section: libs
Priority: optional
Standards-Version: 3.9.2
Package: libaio1
Version: 0.3.113-8+b1
Provides: libaio1
Depends: libaio1t64
Architecture: amd64
Description: libaio1 compatibility shim for Debian 13
EOF

cd /tmp && equivs-build libaio1-compat
dpkg -i /tmp/libaio1_0.3.113-8+b1_amd64.deb

MariaDB Foundation repository and apt pin:

curl -LsS https://mariadb.org/mariadb_release_signing_key.asc \
    | gpg --dearmor > /etc/apt/trusted.gpg.d/mariadb.gpg

cat > /etc/apt/sources.list.d/mariadb.list << 'EOF'
deb [arch=amd64,arm64] https://dlm.mariadb.com/repo/mariadb-server/10.11/repo/debian bookworm main
EOF

cat > /etc/apt/preferences.d/mariadb << 'EOF'
Package: mariadb-* libmariadb*
Pin: release n=trixie
Pin-Priority: -1
EOF

apt-get update

The pin sets the priority of Debian's trixie mariadb packages to -1, which prevents apt from ever selecting them, including during apt full-upgrade.

Remove build tools. equivs pulls in the full compiler and build toolchain as dependencies. gnupg is no longer needed once the signing key is imported. Remove them now before the main install to keep the disk footprint clean:

apt-get purge -y equivs gnupg dpkg-dev build-essential && apt-get autoremove -y --purge

Install the stack:

DEBIAN_FRONTEND=noninteractive apt-get install -y \
    nginx mariadb-server-core mariadb-client-core \
    php8.4-fpm php8.4-mysql php8.4-curl php8.4-gd \
    php8.4-mbstring php8.4-xml php8.4-zip \
    curl

mariadb-server-core is the server binary package. mariadb-server is a meta-package that additionally depends on galera-4, perl, rsync, and socat, which are Galera cluster tools that a single-site server does not need. Installing mariadb-server-core directly avoids all of them.

The php8.4-opcache and php8.4-readline packages are pulled in as dependencies. Both are disabled from the FPM process in Stage 3.

Post-install cleanup. Nginx's post-install script attempts to start the service, which fails because IPv6 is disabled at the kernel and the default configuration includes listen [::]:80. Fix the default configuration and complete the package setup, then remove man-db which the install brought back as a trigger dependency:

sed -i "s/listen \[::\]:80 default_server;//" /etc/nginx/sites-available/default
dpkg --configure -a

apt-get purge -y man-db && apt-get autoremove -y --purge && apt-get clean

Stage 2: Configure MariaDB 10.11

The default MariaDB configuration reserves memory as if the server has gigabytes available. Three settings must be addressed:

• innodb_buffer_pool_size defaults to 128MB. For a single low-traffic WordPress site this can be set to the minimum: 6MB, which is the smallest value the InnoDB engine accepts for the default 16KB page size.
• aria_pagecache_buffer_size defaults to 128MB. The Aria engine is used only by MariaDB's internal mysql schema tables. 4MB is sufficient.
• key_buffer_size defaults to 128MB. This is the MyISAM key cache. WordPress has zero MyISAM tables. It can be set to zero.

cat > /etc/mysql/mariadb.conf.d/99-minvps.cnf << 'EOF'
[mysqld]
# Disable performance schema
performance_schema             = OFF

# InnoDB -- default is 128MB, 6M is minimum for 16KB page size
innodb_buffer_pool_size        = 6M
innodb_log_buffer_size         = 2M
innodb_flush_log_at_trx_commit = 2
innodb_buffer_pool_dump_at_shutdown = OFF
innodb_buffer_pool_load_at_startup  = OFF

# InnoDB threads -- write minimum is 2, read and purge can be 1
innodb_read_io_threads         = 1
innodb_write_io_threads        = 2
innodb_purge_threads           = 1

# InnoDB open files -- we have 16 WordPress tables
innodb_open_files              = 32

# Aria -- used by mysql schema internally; all WordPress tables are InnoDB
# Default 128MB; mysql schema Aria data totals ~3MB
aria_pagecache_buffer_size     = 4M

# MyISAM key cache -- zero MyISAM tables in WordPress
key_buffer_size                = 0

# Per-session sort/join buffers -- only allocated during queries, not at idle
sort_buffer_size               = 256K
join_buffer_size               = 128K
read_rnd_buffer_size           = 128K

# No DNS lookups -- DB only accepts localhost connections
skip_name_resolve              = ON
host_cache_size                = 0

# Connection and table limits
max_connections                = 10
max_allowed_packet             = 16M
table_open_cache               = 64
table_definition_cache         = 400
thread_cache_size              = 2

# Temp tables
tmp_table_size                 = 8M
max_heap_table_size            = 8M

# No binary logging on a single server
skip_log_bin

# Unix socket only
bind-address                   = 127.0.0.1

[client]
default-character-set = utf8mb4
EOF

• innodb_buffer_pool_dump_at_shutdown = OFF and innodb_buffer_pool_load_at_startup = OFF disable the buffer pool state file. With a 6MB pool, saving and reloading it on every restart is pointless I/O. innodb_write_io_threads has a hard minimum of 2 in MariaDB 10.11. Read and purge threads can be reduced to 1.
• skip_log_bin disables binary logging. Binary logs are used for replication and point-in-time recovery. A single-server WordPress instance has no replicas, and recovery is handled by scheduled backups.
• performance_schema = OFF disables the performance monitoring tables. They serve no purpose on a production single-site server.

mariadb-server-core does not include a systemd service file, nor does it create the mysql system user or the data directory. Do all three before starting the service:

groupadd -r mysql
useradd -r -g mysql -d /var/lib/mysql -s /usr/sbin/nologin mysql
mkdir -p /var/lib/mysql
chown mysql:mysql /var/lib/mysql
mariadb-install-db --user=mysql --datadir=/var/lib/mysql

cat > /etc/systemd/system/mariadb.service << 'EOF'
[Unit]
Description=MariaDB 10.11 LTS Database Server
After=network.target

[Service]
Type=notify
User=mysql
Group=mysql
ExecStart=/usr/sbin/mariadbd --defaults-file=/etc/mysql/mariadb.conf.d/99-minvps.cnf
Restart=on-failure
RuntimeDirectory=mysqld
RuntimeDirectoryMode=0755
TimeoutSec=300

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable mariadb

Start MariaDB and create the WordPress database:

systemctl restart mariadb

DB_PASS=$(openssl rand -base64 18)
echo "DB password: $DB_PASS"

mysql -e "CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -e "CREATE USER 'wordpress'@'localhost' IDENTIFIED BY '$DB_PASS';"
mysql -e "GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost';"
mysql -e "FLUSH PRIVILEGES;"

Save the generated password. It is needed in Stage 5.

Stage 3: Configure PHP-FPM

Pool configuration. The default FPM pool uses pm = dynamic, which pre-forks worker processes at startup. For a low-traffic site, pm = ondemand is better: it spawns a worker only when a request arrives and kills it after 10 seconds of inactivity. At idle, only the master process remains.

Edit /etc/php/8.4/fpm/pool.d/www.conf and set:

pm = ondemand
pm.max_children = 1
pm.process_idle_timeout = 10s
pm.max_requests = 500

Timezone. PHP 8.4 rejects the bare string UTC as a timezone identifier. Use the canonical name:

sed -i "s|;date.timezone =|date.timezone = Etc/UTC|" \
    /etc/php/8.4/fpm/php.ini \
    /etc/php/8.4/cli/php.ini

Disable unused extensions from FPM. The default PHP install loads 32 extensions in the FPM process. WordPress needs 18 of them. The -s fpm flag disables extensions only in FPM, leaving the CLI unaffected:

phpdismod -s fpm \
    ffi shmop sysvmsg sysvsem sysvshm \
    sockets calendar xsl gettext readline \
    phar ftp tokenizer

Opcache is a Zend extension and is not handled by phpdismod. Remove its FPM configuration file directly:

rm /etc/php/8.4/fpm/conf.d/10-opcache.ini

The 18 extensions remaining in FPM: ctype, curl, dom, exif, fileinfo, gd, iconv, mbstring, mysqli, mysqlnd, pdo, pdo_mysql, posix, simplexml, xml, xmlreader, xmlwriter, zip. This is the minimum set for a fully functional WordPress install including image uploads and resize.

Restart PHP-FPM:

systemctl restart php8.4-fpm

Stage 4: Configure Nginx

Debian 13's default Nginx configuration tries to listen on [::]:80. IPv6 was disabled at the kernel in the minimisation guide. Replace the configuration entirely:

cat > /etc/nginx/nginx.conf << 'EOF'
user www-data;
worker_processes 1;
pid /run/nginx.pid;

events {
    worker_connections 512;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    sendfile on; tcp_nopush on; tcp_nodelay on;
    keepalive_timeout 15;
    server_tokens off;
    access_log off;
    error_log /var/log/nginx/error.log warn;
    gzip on;
    gzip_types text/plain text/css application/javascript application/json text/xml application/xml application/rss+xml;
    gzip_min_length 1000;
    fastcgi_cache_path /tmp/nginx-cache levels=1:2 keys_zone=WORDPRESS:10m inactive=60m max_size=50m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    include /etc/nginx/conf.d/*.conf;
}
EOF

The FastCGI cache lives in /tmp/nginx-cache on tmpfs. This directory disappears at reboot. Create a tmpfiles rule to recreate it on boot:

echo "d /tmp/nginx-cache 0755 www-data www-data -" > /etc/tmpfiles.d/nginx-cache.conf
mkdir -p /tmp/nginx-cache
chown www-data:www-data /tmp/nginx-cache

Create the site configuration. Replace YOUR_DOMAIN with your domain name and YOUR_IP with the IP address you will administer wp-admin from:

cat > /etc/nginx/conf.d/YOUR_DOMAIN.conf << 'EOF'
set_real_ip_from 10.X.X.X/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

server {
    listen 80;
    server_name YOUR_DOMAIN;
    root /var/www/YOUR_DOMAIN;
    index index.php;

    location = /xmlrpc.php { deny all; }

    location ~ ^/(wp-admin|wp-login\.php) {
        allow YOUR_IP_HERE;
        deny all;
        try_files $uri $uri/ /index.php?$args;
        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.4-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_cache_bypass 1;
            fastcgi_no_cache 1;
        }
    }

    set $skip_cache 0;
    if ($request_method = POST)        { set $skip_cache 1; }
    if ($query_string != "")           { set $skip_cache 1; }
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $skip_cache 1; }

    location / { try_files $uri $uri/ /index.php?$args; }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        fastcgi_cache_use_stale error timeout updating http_500 http_503;
        add_header X-Cache $upstream_cache_status;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
        log_not_found off;
    }
}
EOF

The set_real_ip_from and real_ip_header directives are for TierHive instances where all external traffic arrives through HAProxy from the 10.0.0.0/8 range. They replace the HAProxy-internal source IP with the real client IP before the allow/deny rules are evaluated. On a server with a direct public IP, remove those three lines.

The wp-admin and wp-login.php location block restricts access to a single IP before any PHP executes. The X-Cache header exposes cache status to the client (HIT or MISS). Remove it if you do not want this visible in response headers.

Remove the default Nginx site configuration and test:

rm -f /etc/nginx/sites-enabled/default /etc/nginx/conf.d/default.conf
nginx -t && systemctl reload nginx

Stage 5: Install WordPress

Create the web root:

mkdir -p /var/www/YOUR_DOMAIN
chown www-data:www-data /var/www/YOUR_DOMAIN

Install WP-CLI. WP-CLI is the WordPress command-line management tool. Dropbear does not support SFTP, so download directly to the VPS:

curl -sL https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar \
    -o /usr/local/bin/wp && chmod +x /usr/local/bin/wp

Download WordPress and create wp-config.php. Run as www-data so that all files are owned by the web server user. This causes WordPress to detect FS_METHOD = direct, meaning it can update itself and install plugins without FTP credentials. sudo was removed so either add it back or stick with su; use su to switch user from root:

su -s /bin/bash -c "wp core download --path=/var/www/YOUR_DOMAIN" www-data

su -s /bin/bash -c "wp config create --path=/var/www/YOUR_DOMAIN --dbname=wordpress --dbuser=wordpress --dbpass=YOUR_DB_PASSWORD --dbhost=localhost --extra-php" www-data << 'PHPEOF'
define( 'DISABLE_WP_CRON', true );
define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_POST_REVISIONS', 3 );

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}
PHPEOF

• DISABLE_WP_CRON stops WordPress from triggering cron jobs on page load. A system cron job replaces it below.
• DISALLOW_FILE_EDIT removes the theme and plugin editor from wp-admin, reducing the attack surface if credentials are compromised.
• WP_POST_REVISIONS = 3 caps the revision history stored per post, keeping the database smaller.
• The HTTP_X_FORWARDED_PROTO block tells WordPress it is being served over HTTPS even though Nginx receives plain HTTP from the upstream proxy. Without it, WordPress generates http:// URLs and the browser enters an infinite redirect loop. This applies when SSL terminates upstream: HAProxy, Cloudflare, or a load balancer. Remove it if Nginx handles TLS directly.

Install WordPress:

su -s /bin/bash -c 'wp core install --path=/var/www/YOUR_DOMAIN --url=https://YOUR_DOMAIN --title="YOUR_SITE_TITLE" --admin_user=YOUR_ADMIN_USER --admin_password=YOUR_ADMIN_PASSWORD --admin_email=YOUR_EMAIL --skip-email' www-data

Replace WP-Cron with a system cron job. WordPress's built-in cron fires on page load, which adds latency and fails entirely if the site has no traffic. A system job runs on a fixed schedule regardless:

cat > /etc/cron.d/wordpress << 'EOF'
*/5 * * * * www-data php /usr/local/bin/wp cron event run --due-now --path=/var/www/YOUR_DOMAIN --quiet 2>/dev/null
EOF

Reboot

reboot

After

               total        used        free      shared  buff/cache   available
Mem:             213          84          32           0         104         128
Swap:              0           0           0

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1       2.8G  800M  1.9G  31% /

RAM up from 38MB to 84MB. Disk up from 275MB to 800MB.

What Is Still Running

At idle with no active requests, the FPM pool has no workers. Workers spawn on demand and exit after 10 seconds of inactivity.

RSS is the process's resident set. PSS (proportional set size) credits each process only its share of shared library mappings and is the more accurate measure of unique memory use.

Under load with one active PHP worker, total used RAM is approximately 112MB. Cached requests are served by Nginx without spawning a worker.

MariaDB's 57MB RSS is close to the practical minimum for 10.11 with InnoDB. innodb_buffer_pool_size = 6M is the smallest value the engine accepts for the default 16KB page size.

What the tuning saves

The three MariaDB buffer defaults (innodb_buffer_pool_size, aria_pagecache_buffer_size, and key_buffer_size) reserve 384MB of buffer space in a default install. None of it is used by a single WordPress site. The full set of changes applied:

I did run this on 128mb ram for a few days, it ran ok, but if you build aritifical load it soon starts to fall over, so on that basis I recommend 256mb.

I am also aware you can run this on sqlite and then probably 128mb is fine, i decided against that, apart from the concurrency issues with sqlite, there are also lots of reported plugin issues, so its not technically supported as a "standard full WordPress install" but you can probably save about 40 - 45mb ram if you decide to use SQLite instead then 128mb is fine.

Example site running this: https://pop2.me

Thats the end of the guides for a while, might do some micro howto's but these full fat ones take to long for me right now and I tend to get obsessed with trying ot shave KB's of ram off.

Preview:https://guaqi.com/

What do you think of this new concept product?

Three reliable plugins worth checking out:

FS Poster

Blog2Social

Social Auto Poster

Most of them support X, Facebook, LinkedIn, Instagram and Telegram through API keys or tokens.

Basic setup workflow:

Install your preferred auto-poster plugin.

Connect each social network using the required API keys.

Choose which post types should be shared automatically.

Customize the message template (title, excerpt, featured image).

Enable auto-publishing so every new WordPress post is sent to your social channels.

We personally use Blog2Social because it’s stable, flexible with scheduling and works well with multiple platforms.

If anyone has tested other tools with better reliability, I’d like to hear your experience too.

For those who have tried it:

How stable is the uptime and speed for WordPress websites?

Do these plans actually provide quality support in the long run?

Are there any hidden limitations or challenges compared to traditional hosting?

I’d love to hear from people who’ve tested Lifetime Hosting for their WordPress projects — is it worth considering for serious long-term use?

@vyas @bikegremlin

Surely, with a bit of coding and patience (read: "Black Friday sales") the costs can be significantly reduced, but I wanted to make a "pessimistic/realistic" overview, 'cause we all know that only pigeon pictures are really free:

How much does a WordPress website cost?

We observed that many of my customers' wprdpress sites had security vulnerabilities, and as a result of downloading infected files, the attacker tried to access the servers and thanks to cloudlinux, he could not access other sites.

I felt the need to open this topic so that my friends who use wordpress should be careful. I think my customer encountered this problem because he used an unlicensed plugin. When we completely deleted the site and re-installed it including the plugins, the virus was cleaned.

The problem with the free Polylang is that you can't set language versions for widgets (apart from the "legacy widgets").

This is how I've managed to solve it, with a minimum amount of custom code that can easily be implemented:

https://io.bikegremlin.com/35014/widget-translation-with-free-polylang/

If anyone has a more elegant solution, I'm eager to hear it and improve this.

https://www.bikegremlin.net/threads/wordpress-com-owner-matt-bashes-on-wp-engine-and-silver-lake-capital.352/

Please keep in mind that, due to the nature of the course, there's likely gonna be the option to introduce either 5 plugins a bit more "in-depth", or about 10 plugins very superficially. The plugins should ideally not only be free(-mium), but also be easy to use and (if possible) require little config (less options means less walls the pupils can hit).
For example, WP Super Cache (while not necessarily my caching plugin of choice), has an "Easy" and "Advanced" configuration mode, where in the course probably the "Easy" mode would be addressed.

I am still waiting for more information and if this actually comes to pass, however, I already wanted to do some brainstorming so I thought, why not ask you guys

Last week I tested out the Playground site on WordPress (run WP right from your browser, customize, add content, theme, plugins, scripts... download and delete

Posting just one picture below, leaving links to the rest so as not to take up too much screen real estate.

More images

Change PHP version
https://im.ge/i/WP-Playground.ZmZTrS

Change WordPress version
https://im.ge/i/WP-version.ZmZMVy

Browser-Storage
https://im.ge/i/Playground-Browser-Storage.ZmW4vx

Add a new theme
https://im.ge/i/playground-themes.ZmZo0z

Add Plugin and export
https://im.ge/i/wp-playground-plugins-export.ZmWe6J

Nb: it is not perfect there might be some errors still.

https://im.ge/i/IMG-6109.ZmWhwy

P.d perfmatters and flyingpress are doing unused css as well

Thank you.

It wasn't a DDoS, it wasn't a real bot attack either.

Never experienced something like that (you live and learn).

I wrote it all down as a sort of a pulp-fiction detective story - just for some fun while documenting it:

Website Attacked By Ghosts

Thought it would be cool to not put any spoilers here.

I am looking for ways to speed up my wordpress site

Currently I am using LiteSpeed and WP Smush, and my load times are pretty good.

I am also minifying all CSS and JS using CloudFlare.

Does anyone have any other recommendations.
My sites load times are 619ms

What is your usual workflow in such situations? Anyway, perhaps you were running in a similar issue and this new plugin helps you get the job done Just wanted to share the new information here, and discuss this topic in general.

Edit: I love the AddFromServer description on GitHub though: https://github.com/dd32/add-from-server

"Add From Server - An outdated 11 year old plugin that over 100k people still insist on using"

Or does this already exist and me and my Google Search Recommendations are stupid?

https://www.bikegremlin.net/threads/bikegremlin-i-o-news.10/#post-220

Also, WordPress 6.4.2 update has been released, addressing a potential vulnerability.

https://wordpress.org/news/2023/12/wordpress-6-4-2-maintenance-security-release/

I see OceanWP and GeneratePress giving discounts, even for the lifetime offers ( @Ympker )

My BF offer list (some hosting, some WP - will try to keep it up-to-date):

https://www.bikegremlin.net/threads/black-friday-2023-deals-it-related.54/

https://robertdevore.com/all-in-one-wp-migration-plugin-ddos-attack/

TL/DR
It requires another exploit to exist already in order for this exploit to work.
What it does is it creates backups non-stop (until your storage is filled up).
If you use the plugin to migrate sites, and then remove it, you should be fine.

Just for the heads up, in case anyone set the plugin to do regular backups (always better solved at the server level, not via a plugin IMO).

Just a friend of a friend.... so can't really put my fingers into it! (neither code nor friend of course)
If anyone has any lead....

However, WordPress COM corporation has made a marketing stunt to harness this line of thinking (or fear?) to a whole new level. They've introduced a 100-year hosting and domain registration plan. The link:

https://wordpress.com/blog/2023/08/25/introducing-the-100-year-plan/

So, for about $40,000 you can do a one-time payment and forget about it. The pricing page link:
https://wordpress.com/100-year/#start

According to my calculations, this is exactly 20 times more optimistic than the Soviet 5-year plans.

I suppose there are companies who could use something like this. People forget to renew domains, and WordPress COM hosting has been very reliable over the years.

Being less than thrilled with Google reCAPTCHA, I decided to try doing the same using Cloudflare, for as long as it's free.

It boils down to creating a WAF rule:
Field: URI Path
Operator: contains
Value: wp-comments-post.php
Action: JS Challenge

So far so good.

All the details (how to configure and test it) are in the article:
Stopping WordPress comment spam with CloudFlare

It's a constant cat-and-mouse game, but so far so good (says a man falling from a 10-storey building ).

This morning, I was checking out some new prompts for ChatGPT, I thought of asking some Wp related queries, and asked questions for the following theme:

Merging different wordpress sites- Multisite, or merge with URL forward?

For brevity, I have collapsed the answers, and you will have to click on each response individually. This conversation (with inputs from WP users /tinkerers/ experts on LES) could become a handy resource for the community. Or so is the thought.

Questions for LES community:
a. Have you tried to maintain separate domains for blog and main site (or say, portfolio site and main site) ? What method(s) and CMS have you used?
Note: Atlesat one CMS shold be WordPress - to keep the topic in context.
b. Have you tried WordPress multisite? Was it a subfolder or subdomain? What pros and cons do you see for either?
c. Have you merged different domains and brought content under a single roof? Do you see any pros or cons to this approach?

First Prompt
Q. I have two websites, both use wordpress. One is the main site with the domain mysite.in. The second site is a blog, on a subdomain blog.mysite.in. I need to merge the two sites. What are my options to merge the blog with the main site? What will be impact on the URLs?

The response from ChatGPT was: (click details to read)

Second Prompt

Q. From the above options, if I want to choose the first option- Using WordPress multisite, what are the steps to follow?

Third Prompt

Q. Is the above option equivalent to creating a wordpress multisite with a subdomain option?

Fourth Prompt

Q. In the above example of moving my blog to wordpress multisite, will I have to change the DNS entries with my domain registrar?

Fifth Prompt

Q. I use cloudflare currently with two sets of DNS entries, one for blog.mydomain.in, other for mydomain.in. This is, because both sites are hosted on different servers which have different ip addresses. Once I opt for wordpress multisite, will my cloudflare entries change?

Sixth Prompt

Q. From the three options of merging my blog, let us say I want to opt for option 2: Merge the blog into the main site manually. What will be the steps I will need to follow?

Seventh Prompt

Q.From a seo and site maintenance perspective: Which option is preferred? Having a blog as a subdomain, or merge the blog into the main site?

Eighth Prompt

Q.My main site mydomain.in is on WordPress. However, I want to use a different content management system for my blog, which is on a subdomain. I want to host both mydomain.in and blog.mydomain.in on the same server. What should my setup look like?

https://theseoframework.com/pricing/

Basically, you get a very good SEO plugin + a great spam-protection extension included. I love it. For (a lot ) more details: my The SEO Framework Pro review.

It's a known bug in the reporting, doesn't mean there's anything wrong with caching:

https://wordpress.org/support/topic/page-caching-not-detected/

Preferably (ideally), it would also enable visually impaired people to navigate the site:

• Navigating the site using the keyboard only (not everyone can see the mouse pointer).
• Making any changes that help auto-readers work properly.
• Increasing font size (I know there's an in-browser option to "zoom," so this would be a nice extra).

Google is full of "top X plugins" that are obviously written without any testing with a blind person. So rubbish.

PS:
It's now called "A11y," short for "Accessibility" (11 letters between the "A" and "y"). Lol.

Apparently, WordPress does not really shine when it comes to optimizing its DB table searches. This plugin supposedly helps add some keys to make the indexing of the often-used stuff faster.

Looks good for now (tested on staging and one website).

Of course, I wrote an article about WordPress database optimization, with a bit more details and a brief tutorial on how the above-noted plugin is used, in addition to LiteSpeed Cache and Advanced Database Cleaner Pro plugin for cleaning and improving the DP performance.

https://wptavern.com/webp-by-default-merged-into-core-for-wordpress-6-1

Looks like Shortpixel or similar image conversion tools (that convert to webp) may not be needed. Personally, I optimize and convert image before uploading. Others prefer the tools to do the honours.

What do you guys think? Excited? Disappointed? No opinion???

Chime in.