404 and play button not working on NGINX even with rewrite rules

Also, there is no caching plugin installed and it is not enabled in Hestia for this domain.

Hi @tamerax,

Sorry to hear you encountered this issue.

Did you place the rules at the top of the location block?
Did you restart your NGINX after making the changes?

Additionally, it looks like your site utilizes Cloudflare. Did you try temporarily disabling it to see if that resolves the issue?

Best regards,
Serhiy.

Hi @zahardoc

I did indeed have them at the top of the block and yes I restarted NGINX.

I also just tested it by putting cloudflare into development mode and removing the A record from the proxie but still no change.

@tamerax

If you don’t need stats (or you use Castos stats), you can provide the real file URL instead. Just add the following code to your functions.php file. This will give you time to investigate the issue while ensuring users can still listen to the podcast:

add_filter( 'ssp_episode_download_link', function ( $link, $episode_id, $file ) {
	return $file;
}, 10, 3 );

Hope this helps,
Serhiy.

I’m having a similar issue. Except I’m using wordpress.com hosting. I previously changed the “Handling requests for nonexistent assets” setting to “Default”, which if I understand the instructions correctly is what I’m supposed to do. That fixed the issue for several months, but today I started getting the 404 errors again. Everything was working as of yesterday, but something happened and it all quit working again. The site is https://stripwalking.com/striptalking/

I’ve used your modification to the functions.php file so the podcasts will play, but I’d like to have stats. Also, the feed still is generating a 404. What else can I try?

• This reply was modified 8 months, 2 weeks ago by rohdem.

I ended up restoring a backup and that fixed the problem

@zahardoc

Thank you for that. That does indeed work. I’ll check to see if my client needs stats and we can go from there. Still odd that it’s not working the other way even without cloudflare and confirmed that the rewrite rules are in place.

Thanks again!

@tamerax

Glad to hear it worked for you!

If you find our plugin helpful, we would really appreciate it if you could leave a review to help others discover it.

@rohdem
Glad you managed to fix it.

• This reply was modified 8 months, 2 weeks ago by Serhiy Zakharchenko.

@zahardoc

It’s more a bandaid solution than a fix but it does allow my client to work.

Here is my full location block. Can you tell if there is something in there that would be potentially effecting it?

    location / {
            rewrite podcast-download/([^/]+)/([^/]*)/? /index.php?podcast_episode=$1 break;
            rewrite podcast-player/([^/]+)/([^/]*)/? /index.php?podcast_episode=$1&podcast_ref=player break;


            try_files $uri $uri/ /index.php?$args;

            location ~* ^.+\.(ogg|ogv|svg|svgz|swf|eot|otf|woff|woff2|mov|mp3|mp4|webm|flv|ttf|rss|atom|jpg|jpeg|gif|png|webp|ico|bmp|mid|midi|wav|rtf|css|js|jar)$ {
                    expires 30d;
                    fastcgi_hide_header "Set-Cookie";
            }

            location ~* /(?:uploads|files)/.*.php$ {
                    deny all;
                    return 404;
            }

            location ~ [^/]\.php(/|$) {
                    try_files $uri =404;

                    include /etc/nginx/fastcgi_params;

                    fastcgi_index index.php;
                    fastcgi_param HTTP_EARLY_DATA $rfc_early_data if_not_empty;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

                    fastcgi_pass %backend_lsnr%;

                    include %home%/%user%/conf/web/%domain%/nginx.fastcgi_cache.conf*;

                    if ($request_uri ~* "/wp-admin/|/wp-json/|wp-.*.php|xmlrpc.php|index.php|/store.*|/cart.*|/my-account.*|/checkout.*") {
                            set $no_cache 1;
                    }

                    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_items_in_cart|woocommerce_cart_hash|PHPSESSID") {
                            set $no_cache 1;
                    }
            }
    }

Any insight would be appreciated as my client DOES need stats.

Hi @tamerax,

Based on the settings you provided, it should work, but there might be a bug causing the issue. Sorry, I’m not a server administrator and won’t be able to advice you here. I recommend reaching out to your hosting support for further assistance or hiring a specialist who can resolve this for you.

Best regards,
Serhiy.

@zahardoc Using the ssp_episode_download_link filter will break the seriously-simple-stats plugin?

@marekmaurizio
It depends on how you use this filter. If you return the direct file path, the Stats won’t be able to track listens because it won’t even register that they’re happening. But if you remove .mp3 extension from the virtual path, both your player and stats will work. The only downside of this approach is that some platforms don’t allow file paths that are not ending with .mp3 or .mp4.
Also you can consider using Castos, in this case your files will be stored there, and you’ll have much better statistics.

• This reply was modified 5 months, 3 weeks ago by Serhiy Zakharchenko.