Caleb

500 is not a “denial” of post edit. It is an actual failure of your Apache/PHP system.

Which PHP version are you running?
WordFence will run with all versions up to at least PHP 7.1 (I am using it), but is does require that your PHP has the right modules and configuration. Something that on all hosting setups is specific to the PHP version.

Some “feature”, yet unknown, is likely used in WordFence that requires you to make sure your PHP is set up correctly. There is another open incident right now on WordFence causing 500 errors if using PHP7 in some configurations.

Can’t say what, since no one has yet reported back with any actual error traces explaining what the 500 error is failing on. “500 – Internal error” in itself says nothing about what failed.

No one can answer the question without knowing the errors logged.
Error 500 is a generic “Internal error” thing that just means that PHP could not execute something.

When you switch from PHP5 to PHP 7, it sounds simple, but since PHP comes with many individual modules that on the server are added or enabled separately for each PHP version, you could simply be missing a module that needs to be enabled.

I run PHP 7.1 on everything these days, but when I originally flipped over from PHP5.6 some WP plugin(s) died miserably because PHP7 reads “phar” type code archives differently. (Not your issue, since WordFence does not use phar archives).

But without the error detail, one is merely guessing out in thin air.

Have you tried this:

1. On the Options page, down bottom, click Export WordFence settings.
That will save your configuration to the WordFence server(s). and give you a token-ID. (Save that Token)

2. On Options page, make sure to select “Delete Wordfence tables and data on deactivation” and then save the options.

3. Deactivate the WordFence plugin on the plugins page.. It should now delete all current WF tables from the database.

4. Re-enable WordFence on the plugin page. It should on activation detect the missing tables and re-create them.

5. If you want, then go on the options page and “Import” your configuration using the Token-ID you saved earlier.

I would assume that their site on the new server is running WordFence as well?
Also that they ported over the database and WordFence configuration from the old server?

So… Could it be as simple as their configuration of “Where to email alerts” still lists your email address as the destination to “talk to”? 🙂

Yeah. I too am waiting on Pods 3.0. 🙂

The short version.. Linux (your server) has a very different idea of time/timezone from PHP/WordPress. Both must be synchronized, if you want “outside” timestamps (like file modification times ) to show VISUALLY same in WordPress.

The long version:

Apples and Oranges. (Mixed with some Watermelon and a big squirt of Lemon).

Apples: Linux systems internally count “Seconds since the Unix Epoch” (Jan 1 1970) IN UTC. Always UTC.
A simple Integer clicking along. That simple integer is what the php call “filemtime” correctly returns to WordFence, an “ls -l” on the SSH command-line. filemtime() is a simple PHP hook to Linux’ own filesystem call.

Oranges: The date shown in Linux (if you ask or set with the “date” Linux command), or look at file modification times is is done by converting the Unix Epoch counter returned from the kernel and calculating current date/time from there. By how many times we have counted “one second” since 1970. ALWAYS in UTC time. 🙂 The exact date/time SHOWN then further depends on the Server’s TZ (Timezone) settings. Done by simply adding/subtracting from UTC using the Timezone setting. That is what the local hosting admins are talking about when they talk about their system’s timezone.
Most admins think think they are setting a date/time, but in reality when setting time, the system calculates backwards to get a new “Epoch time” from the date/time you give it, That “Epoch time” is then set in the kernel.

The server (the Linux kernel running the system) does not care one-iota about timezones.. It knows seconds (actually microseconds) since Jan 1, 1970 UTC. TZ is a local conceptual thing added on top of it all, used to satisfy us human beings who do not count microseconds that well.. 🙂

A BIG FAT Watermelon: PHP has it’s own idea of what timezone should be assumed. It is typically set in your global php.ini file with the “date.timezone” config, or set with date_default_timezone_set() within a script. Like anywhere in WordPress. That makes PHP totally ignorant of what the Servers notion of timezone is.. PHP does not care.
What PHP and Linux have in common, though, is “seconds since Unix Epoch” or “Epoch time”.
But unless their TZ settings are synched up, they then convert it differently when displaying it to us humans. 🙂 Just to make our lives more interesting. 🙂 PHP asks for the “Epoch” time, just like Linux itself does, and then converts that into PHP’s own notion of what timezone it is in. And the “file modification time” WordFence get’s from Linux is an “Epoch time” time-stamp. 🙂
PHP’s notion of TZ affects the output from all the standard PHP Date and time type functions, which makes it very possible that a PHP date() function can return a date/time string quite different from the Unix system’s date command. Linux and PHP running with different timezone configs, but they BOTH calculate their idea of a date from the “Unix Epoch” returned by the Linux kernel. 🙂

Now for the Lemon part, or the EXTRA fly in the ointment. WordPress.. WordPress by default ignores your Server AND PHP settings for timezone.
It calls “date_default_timezone_set( ‘UTC’ );” directly in the wp-settings file, which makes all WordPress sites all over the world default run in UTC time, unless a site-specific change (a call to date_default_timezone_set) is hit.
JUST LIKE LINUX DEFAULT. 🙂

WordFence as far a I know uses only the a simple PHP date() call to convert each file’s Epoch value into a human readable. That will always make it show a local “PHP time”, dependent on PHP’s timezone idea. That might have been changed by WordPress along the way, but it is totally and completely independent on whatever conversions the Linux system has done based on ITS OWN TZ config. Unrelated to what “modification time” Linux shows when you do an “ls -l” on the command line. Unless configured to run in the same exact timezone, Linux and PHP will each convert “seconds since Unix Epoch” differently. 🙂
And “Epoch time” is what all file modification timestamp are.

WordFence can be affected by both PHP timezone (and by WordPress) because wordpress uses the “date_default_timezone_set()” to set their own idea of Timezone. Default always UTC.

Some plugins, like Yoast SEO, ALSO calls date_default_timezone_set() and will RESET your PHP timezone to UTC directly in PHP if your PHP is NOT configured in PHP.ini. They look for it. 🙂 But when random plugins call date_default_timezone_set() at odd times, they are changing the PHP system. Which affects others, including WordPress. 🙂

Here is the rub.. It normal cases in WordPress, the choice is simple.. You want posts and comments to show “site-time”, as in the time set in your site’s timezone config.

But for plugins like WordFence, where these filelistings really represent a SYSTEM or SERVER time that has nothing to do with PHP, WordPress, or Site-time, the issues get’s trickier. This is unusual, because it is a time-stamp from outside PHP and WordPress, but displayed in PHP and wordpress. 🙂

Because WordFence is affected by the separate settings in both PHP and WordPress, both of which are completely unaffected by the Servers (Linux’s) ideas of its timezone. 🙂

So one need to pick one’s poison here, since there is no clean and easy way to “bypass” both WordPress and PHP’s notions of time/timezone. They do not mean it to be bypassed 🙂

The only sure way to always show the same file-time, is to have server, PHP, and WordPress/site timezones synch’ed up. But that is rarely possible for anyone, since you might buy hosting in Austin, Texas (like hostgator running all their servers in their timzezone), but you are using it for a site that is “pretending” to be running in a California or New York timezone.

To show “Server time”, WordFence would have to acquire the local Server timezone (from outside PHP), and then either (temporarily) set the PHP timezone using date_default_timezone_set (No please, Ugly,. don’t do it, bad 🙂 ).
Or the better way: Figure out the SERVER’s notion of timezone, and then use the DateTime PHP class to set a DateTime variable in that timezone. The DateTime class can then be used to convert the filemtime() results you find into human Server timestamps.
Bypassing the standard “date() call, which is too dumb to know anything but PHP time.

Another complexity is, that even if implemented. Linux and PHP have slightly different syntax for Timezone strings. Meaning that in some timezones, you will get support calls because trying to set the Unix formal timezone in PHP will produce errors. 🙂

Dates/Times are so much fun, Eeh?
Something that conceptually simple, yet so tricky to handle.

I assume that when you changed your (remote) site to https, you also went into websiteremote and changed the access URL in the configuration from http:// to https:// ? As I hinted at in my first reply.

If websiteremote was actually trying to access the “remote” site using an https:// type URL, that 3 lines would have no impact at all, since there will be no redirect if the caller is already calling in on https. That there IS an impact indicates to me, that you did NOT tell your websiteremote configuration to change it’s access method.

Websiteremote is NOT a browser.. Mostly that type of software do not react by actually continuing to jump to new places when a 301 redirect message is sent back to them.

All those first 3 lines

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://my-domain.com/$1 [R,L]

do is to redirect all accesses on http (port 80) to https (port 443).
A standard thing to do when you have moved your site to https. It simply assures that people and GOOGLEBOT does not find duplicate content, since you now essentially have two versions of your web-site. One on http, and one on https. Anyone trying to access your site on http, will be redirected to https. You really MUST have those lines, if you are putting your site on https.

The remaining lines are standard WordPress.

The 3 redirect lines have nothing to do with WordFence, nor do they make your site more or less vulnerable to any attacks. But if you remove them (without doing something equivalent elsewhere), Google bot will find your content on two sites (https and http) and you will get dropped because of “Duplicate Content” issues.

If websiteremote stops working, it is likely because they are not following the redirect to the new site-location.. When they try to access their admin BACKDOOR into your system on http, your site’s reaction is now to respond with a Redirect.
Hard to say, since you are not showing the error messages.
Have you updated the link in your websiteremote config to be an https:// type link to the site, rather than the old http:// link?

Websiteremote itself is very goofy “product”, from what I can see.
Any product that installs “stealth” plugins to hide from the WP site’s owner, and creates backdoors into a site to ensure constant access on “any available admin account“, even if the site’s real owner (as in a client) locks you out by deleting your admin login, is not a good product in my book.
Serious bull**** feature there, that should cause their plugin to be removed from WordPress.org.

But.. That’s just my personal opinion..