Caleb

core files stem from a program crashing and “dumping core”, which is a copy of the process’ memory at the time. Meant for someone to come find out which program died and debug what happened. The core file would have stack-traces and other debug info in it.

core.#### (some number) is simply the Linux system adding the process ID of the program to the name of the core file as it saves it. To make it unique.

The only program that would typically run inside and potentially die in your web-site structure is PHP itself, unless you manually run programs through SSH. So, if someone looked at the core files, they would likely find that it is core files from dying PHP processes.

As for WHY PHP (or some other process) might be core dumping, that is a whole debugging spectrum in itself. It is usually caused by some bug in one of the many add-on PHP modules a server typically have installed.

I recently had cron-jobs calling WP-Cron start dying/crashing after an automated background PHP “upgrade”.. Could not even call “PHP” from the command line without it crcashing immediately. Turns out the cronjobs were running the default (old) PHP 5.6 version.
I fixed it by forcing the cron-jobs to run PHP 7.1, which is what all sites are running anyway. Only because they were cron-jobs did the system find the older version in the path.

At any rate, there is nothing WordFence (or any other PHP program) can do to fix core dumps in the PHP interpreter (assuming that they are PHP dumps). PHP should not crash, no matter what PHP code it is interpreting. That is a problem in your installed PHP version or one of it’s added modules. Nothing a lowly PHP program can do to fix that.

Either figure out what is core-dumping and debug, try switching your site to a better/newer PHP version, OR simply delete the core files and wait for them to appear again (and they likely will if you do not change something).

So, just for future reference. What was the “old data” in reality?

Yes, the theory behind redirect_canonical was to automatically fix www/naked. But they took it much, much too far.

The correct way to handle www. versus naked domain and any movement between them is to simply add a fix to htaccess that points all visitors (including google) to the version you want (and prioritize the right version in Google’s Search Console) .
That way everything is kept clean, SERPs are maintained, …, …

Wordpress added all these many lines of gooble-ti-gook code with searches in database and seemingly randomized hidden redirects, just to save people from learning how to add 2 lines to their htaccess.. That’s just wrong.

Yes, Since your htaccess will now be killing off these ranges in Apache, they will never reach WordPress/Wordfence. To see the denials, you would now have to look at your web-server access logs. And it is MUCH faster than loading WordPress.. Like comparing nanoseconds to many milliseconds.

I assume you looked at that help page (I tried to make it at least a little informative) :-)..
As you can see on the simplistic illustration there, you could theoretically move blocking even further left. Block things in for example the mod_security module (Apache security module), even further “left” into firewalls or other blocking, before they are even seen by Apache (and hitting your denials in htaccess). Not necessary really in your case. Apache blocks fast without the huge overhead of loading up PHP and many times worse WordPress.

Now, I assume this is for your HSMRE site?
I looked at that site, and I would imagine that your site is very targeted. Your good (as in potential business) visitors would be local only, I imagine. (By local I mean mostly in the US, not Russia and China for example.).

That gives you at even better and faster option. Depending on what type of hosting you are buying at GoDaddy (if VPS or Dedicated server), I personally would install for example mod_maxminddb, which gives you GeoTargeting ability directly in Apache.
So you could then simply tell Apache to always block off certain countries or send them somewhere else. Without having to think of or block IP ranges individually.

That will not work for many sites that might have and want world-wide human visitors, but for a site that is very locally targeted, like yours, blocking off the rest of the world and only letting in for example the USA and Canada is fully valid.. You would still get some bad visitors (think bad hosting across in USA and Canada), but not a fraction of what you see now.
With geotargeting in Apache, it suddenly allows you to have htaccess contain things like

SetEnvIf MM_COUNTRY_CODE ^(RU|DE|FR) BlockCountry
Deny from env=BlockCountry

Or Allow only from US|CA type statements.

On the CDN topic.. You need to separate out topics of CDN functionality and CloudFlare’s security services, which has nothing to do with CDN really.
A Content Delivery Network, is merely a way to offload your static stuff like CSS, JS, and images to a global network of servers (for faster delivery to users) and save the bandwidth on your own server for just your content. A CDN does not typically require changes to your DNS.. You simply tell your caching plugin to change CSS, JS, and image links to point to the CSN instead of your server. Then, ALL DONE.. 🙂

A visitor in the UK will then get all the static stuff from his closest CDN owned server, and only have to transport your much smaller basic page text through the cables under the big oceans.
Using multiple servers also helps with browser functionality, because the browsers will only open a limited # of simultaneous connections to a single server at a time.
I for example do not use a direct, world-wide CDN (yet), but instead have configured the caching software to use mirrored server spaces, which means my CSS, JS, and image stuff load from 4 separate “unrelated” domains. Which makes the browsers allow themselves to open more simultaneous connections to load it all. As compared to all your “stuff” coming from only one server/domain domain.com.

When you are thinking about CloudFlare, you are NOT merely thinking CDN. You actually CAN run naked domains with CloudFlare, but the issues they have is not with the CDN part, It is with their security offerings. For example protection against DOS DNS type attacks. To do that, CloudFlare wants/needs to OWN/control your domain DNS. So any DNS attacks go to their servers, rather than your hosting provider. And that ownership is where the conflict lies. Not with the basic CDN functionality. And notice that even under CloudFlare, they are not a WordPress security provider. Your site would still be under attack from WordPress spammers and hackers. CloudFlare’s security services is at a totally different level. They run network level security only as far as I know.

If all you want is CDN (distributed network for your static files), then other services are much more practical and cheap. Such as MaxCDN and others.
But again, your site is special.. People typically get CDN to get a world-wide distribution of static files. To speed up their site for international or at least wide-area visitors. World-Wideis not really relevant for your site, if you main visitors are “local” only. Or maybe I am guessing your targeted visitors wrong.

If you want to merely speed up browsers by spreading out your data, you can do that simply with mirrored subdomains to trick browsers into loading faster; using more connections. You could even put those domains on separate servers/hosting to further speed things up.

Have you tried placing a ‘.user.ini’ file in the root of your installation with this content:

auto_prepend_file = '/storage/pbj-design.dk/www/wordfence-waf.php'

There is a significant difference between the earlier case you found, and your case. The earlier caller had a (separate) WordPress installation on all domains. His AddOn domains was also running WordPress. He could have done exactly what I suggested in my first response. Run all domains as a Multi-Site install.. One WordPress copy, one WordFence copy.

In your case that will not work, because you say your add-on domains are not WordPress installations, but something else.

You are however impacted by one part of WordFence, because of Cpanel’s way of installing things inside each other.

WordFence comes with two parts.

Part one is wordFence-waf.php, actually calling the base boot-strap firewall piece. Testing for intrusions, it hooks itself into PHP through PHP’s “auto_append_file” option (set in php.ini). It is essentially WordPress ignorant. It does not need a WordPress environment. It just scans the initial access information.
By “Auto Prepending” the firewall part through PHP, that piece of code runs BEFORE Wordress starts up.. And in the add-on domains cases, WITHOUT an actual WordPress EVER starting up.
The PHP “auto_append_file” config option can be set in .htaccess, in php.ini or in VirtualHost (apache) settings. Since this part is independent of WordPress (pure PHP), it can run without WordPress for those initial checks.

Part two of WordFence is the whole WordFence plugin itself. This is a WordPress plugin, which does all the other work and blocking and presents you with the control interfaces you see in WordPress’s admin screens. You obviously CANNOT install the WordPress plugin on a non-WordPress type of site. That plugin needs WordPress to run.

So, in your case, what seems to be happening is a side-effect of Cpanel’s idiotic notion of installing add-on domains (really addon Apache VirtualHosts) inside the main domain’s space, instead of keeping all VirtualHost installations separate and parallel, like others do it.

Because you are running all these domains sort of inside each other (add-ons as sub-directories of the root domain), the php.ini or .user.ini sitting in your root-domain’s directory is affecting all your installations.. Just like a global PHP.ini file (global to all PHP installations on the server) would. BUT.. That is where WordFence hooked in it’s initial firewall file.. Ooooopss..

Suddenly you have half of WordFence running, without WordFence really wanting to. The base wordfence-waf.php file is apparently being “prepended” to your supposedly unrelated add-on domains via PHP’s common auto_prepend_file option on the root-domain). Because they all share that directory in their path.

That is why you suddenly see a WordFence warning like the one you show in your picture when you “touch” or try to upgrade on your add-on.. The WAF file is running when you run PHP operations on your add-ons, and it is thinking unsafe things are going on. (Some firewall rule-pattern kicked in.)

You need to separate the PHP “auto_prepend_file” option on your root-domain from affecting your other domains.. You can do this in multiple ways, since that option can be placed in 3 different types of config files. Touching your VirtualHost configs for each is one way, but more tricky.

I would suggest you try to use the .htaccess file in each add-on domain to tell PHP to STOP auto-prepending the unrelated WAF file, since the full WordFence cannot actually be install there.

Put this option in their individual .htaccess file

php_value auto_prepend_file none

Not in the root-domain’s htaccess file, since it IS actually running WordPress and a full WordFence plugin install. Only in the add-on’s private htaccess file.

The “none” tells PHP that you do not want an “auto_prepend_file” here.

Welllllll… Transients is a WordPress functionality and used by every plugin, themes, and other functionality.

If there should be a clean-up functionality, it should be in the core WordPress not allowing old junk to be sitting around. Once an expired transient is dead, WordPress’ own API would not be returning that data anymore. So it is dead data.

The whole idea of many “transients” (temporary cached stuff) is to set it and forget it kinda thing. WordPress provides APIs to ‘set’ and ‘get’ transients, but NO cleanup actions are part of the API.

It should logically be “unknown” to plugin developers where WordPress hide those transients at any time. (Depending on your installation they could be in the database option tables, in APC(u) memory based cache, or others caching options.

Wordpress does not really have a nice “cleanup” functionality, which means you would need every plugin developer to on their own be rooting around with manual MySQL code in the options tables, or whereever the transients are hiding at any time. Something they should NOT be doing, as the implementations could change in future versions of WordPress. And you really do not want every plugin author to add their own personal kick on running odd WP-cron jobs or other main clean-up junk just because of transients.

So no.. Not a WordFence functionality, I think. Until WordPress learns to provide database maintenance and clean-up as a core functionality, I’d still suggest the “WP-Optimize” plugin, which is a work-around for the missing WordPress functionality.