fryrpc

This is the process I am following.
Add Podcast – Enter Episode Title – Enter Episode Text – Put in URL to MP3 that is hosted on my Amazon S3 space – Save Draft

As far as I know this is the same process I have used each time and have always just used URL’s in all my podcasts to the same area on my Amazon S3 storage – i.e. not browsed and uploaded.

This is what I got on the browser console:
load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,plupload&ver=4.7.4:9 JQMIGRATE: Migrate is installed, version 1.4.1
[Violation] Forced reflow while executing JavaScript took 31ms
load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,plupload&ver=4.7.4:2 [Violation] ‘DOMContentLoaded’ handler took 370ms
[Violation] Forced reflow while executing JavaScript took 76ms
onloadwff.js:35 [Violation] ‘setTimeout’ handler took 90ms
onloadwff.js:41 [Violation] ‘setTimeout’ handler took 829ms
onloadwff.js:41 [Violation] ‘setTimeout’ handler took 513ms

Regards

I changed the settings in my wp-config.php file as per below

define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, true);

I added a new podcast and this field was not calculated – no errors were displayed on screen and nothing was put in the debug.log file.

I am not sure about whether the Seriously Simple Podcasting plugin had been updated as I update all plugins on a weekly basis.

Yes I am referring to the …/feed/podcast link

If I set the specific attribute filesize_raw to the size of the file then it does appear in the …/feed/podcast link.

So the issue seems to be when the podcast is created – it used to auto populate both the filesize=24.90M and filesize_raw=26134697 based on the URL to the MP3 file but since the 2nd April neither of these have been auto populated for any new podcast and hence why the feed page lists the file size at 0.0MB.

So I guess the question is why and what populates these fields when creating a new podcast? This might help identify the component that is failing to operate as it has done so in the past.

Regards

Brilliant – Thank You.

I am using WP Fastest Cache and it does implement caching vi .htaccess – as does the All In One WP Security plugin. So these must be active before the Ninja Firewall plugin then?

Does the flow look like this?

http –> .htaccess –> php –> .user.ini (Ninja Firewall WAF) –> WordPress PHP

I have checked the console and there are no errors. I have found adding /index.php on to the end of the url does result in a log entry.

It looks like the caching plugin, which effectively creates an index.html that is a static representation of the index.php, and serves that to visitors is somehow affecting the live log. I thought the firewall would see the initial request from the client before the cache plugin serves the static file.

Does this sound like normal operation – hopefully it just means I can’t actually see visitors in the live log?