designerChad

SOLVED

Justin, following up on my hunch that your code doesn’t check custom post types, I simply changed this line in your code to my post type: _admin_menu.php line 330

‘$pages = get_posts(‘post_type=image_gallery&numberposts=-1&post_status=publish,private’);’

So, adding a nice little section to your admin page for a user to select which post types to check would be a very nice little addition to your plugin.

After changing that, the refetch did exactly as it was supposed to. Thank you!

In addition, another suggestion is to add a cron to automatically refetch galleries after a certain time period.

Is it possible that your refetch doesn’t test custom post types? My album pages are in a custom post type.

You are right, my mistake in assuming it was reporting incorrectly.

The plugin is correctly reporting those pages that do not have a gallery tag, but those who do have a gallery tag: All of the pages listed on this albums page are not refetched.

https://www.daytrippertours.com/the-daytripper-experience/photo-albums/

This one for example: https://www.daytrippertours.com/image-gallery/oregon-glories-2015/

Interestingly, if I were do delete all the code on that page and “redo” the gallery link process from scratch, then the “update” does fetch the updated gallery code. So there’s a disconnect somewhere with the refetch.

<!–FBGallery2 1117282491618864 –><!–/FBGallery2–>

Agree – the “super themes” load tons of unneeded scripts. I’m testing on Avada. <- Big on functionality, also big on bloat. I thought it would be the perfect candidate for this plugin.

Also agree – optimization is not a one-time set and forget. It requires constant testing with any new update before deploying to a production site.

This update made the script work as advertised. I got the css/script list on the page and checked all that were not needed. Reloaded front end. Script count was less and no js errors (after a little trial and error of course). Page tested went from 61 – > 47 requests with no errors.

Your plugin has promise–bravo!

I was getting the same issue. Your quick update seems to have fixed that issue for me. I’ll continue testing.

Two of my clients’ sites on GoDaddy have been hacked with a variant of this. So far, out of all my clients, ONLY sites on GoDaddy have been infected.

The reversed engineered files point to a backdoor / malware download and shell install from: v-fish-ka.ru

It doesn’t appear that the curl download and shell install executed. So I’m doubtful the backdoor was actually installed. However, it’s still unnerving that the hacker was able to edit the .htaccess and add the malware install script to the site’s root.

One of the infected sites is pretty buttoned up security-wise. I’m leaning towards believing this attack is systemic on GoDaddy’s servers rather than being a WordPress related vulnerability.

I know for a number of you @wishie’s script doesn’t entirely cover it. It doesn’t change 2 of the URLs I needed. This is how I fixed it:

1) First, change the URLs in the textbox under the advanced settings (just like has been suggest by a number of you).

2) Run this query on your database in phpMyAdmin (or your favorite db tool-I use Navicat)
SELECT * FROM wp_posts WHERE post_type=’lightbox_library’;

3) Copy the “post_content” from the recored you need to fix (I fixed photocrati-nextgen_pro_lightbox)

4) Go to a Base64 encoder / decoder like: https://www.base64encode.org/ and decode the string you just copied.

5) Correct the URLS and re-encode to base64.
6) Paste that new encoded data back to your post_content.

FIxed!

I had the same issue. It is most likely another plugin that is causing the problem. For me it was Event Espresso. I had “use SSL” enabled in Event Espresso. Turning it off fixed the redirect loop.

Event Espresso > General Settings -> The first option under Page Settings. I set to NO and now Cart66 works fine.

Dunno if you have the same issue, just thought I’d share what I found.

Good luck!