Hustle not working in Mapped Domain

Getting the following console error when trying to use Hustle, and Bloom plugin in the mapped domain:

Failed to load http://orginal-domain/wp-admin/admin-ajax.php: Redirect from 'http://original-domain/wp-admin/admin-ajax.php' to 'https://original-domain/wp-admin/admin-ajax.php' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.mappeddomain.com' is therefore not allowed access.

Issue is specific to the subsite, and not able to replicate in other network. However, it works fine with the original domain. Domain names are masked.

  • Ben

    I spent all day on it yesterday...here's what I found and did:

    Set up another mail chimp account on the broken site. Same issue
    Set up another mail chimp account on a different subblog mapped site with same theme..worked
    Set up her her mail chimp account on a different subblog mapped site with same themes...worked.
    Tested all plugins one by one and saw that spam shield had conflict on the new site.
    Used option to not protect with non recognized forms on different subblog mapped site, worked.
    Used option to not protect with non recognized forms on broken subblog mapped site, worked....still didn't work.
    Disabled spam shield on original broken site, still giving console errors.

    So even though both sites have identical set up...on same server..one works...one doesn't.

    Both are using divi theme. However original broken site used to use upfront theme and is older.

    Reviewing the database...there is a ton of upfront theme garbage and defender garbage in the database sub blog tables...bad.

    I have given up on finding whats going on and just spent the day recreating the site from scratch and things work.

    So who knows wtf is going on, but that's my solution.

    Take away...there needs to be a "clean up" button for customers to clear out wp-dender table garbage (there should be an active ticket) and then should be a button to clear out upfront table garbage.

    It is the responsibility to code safely, responsibly, and keep housekeeping clean behind the scenes...its not. There's your monday scolding, happy Monday!

    By the way...there was some controversy with spam shield and plugin organizer...that recently got spamshield kicked out of the repo..but its actually a pretty solid plugin in my opinion. Forces a non pure ngnix setup...but he's a security expert, not me and his ideas seem to make sense. Would be good if defender was on top of some of his ideas:

    Here's a direct link to the plugin

    https://www.redsandmarketing.com/plugins/wp-spamshield/

  • Oguz

    Hey Ben ,

    Hope you're well.

    Glad to hear that you solve the problem and thank you for the whole information about steps and solution. It's important to share these in case other members may experience the same issue.

    For the unused plugin tables; most of the plugin doing that because of data accessibility for future. Let's think that you are using Defender plugin for blocking some IP's. When you delete the plugin, it deletes the files but it keeps the IP's. So if you activate the plugin again you don't have to remember/rewrite the IP's again.

    Cheers,
    Oguz

  • Ben

    Oguz,

    In regards to Defender...Defender changed the the database tables...to be their own tables....and then there is a bug in the "cleanup" of all the data it left in the postmeta for ALL the sub-sites...and its ALOT of data....so just to be clear problem still exists...this is not a feature with the data being left on the database in the wrong areas...and still needs to be resolved please...

    Thanks.

  • Oguz

    Hey Ben,

    Hope you're well today!

    Can you try this SQL code to clean your database from Defender data completely;

    DELETE from wp_postmeta where post_id in(SELECT ID from wp_posts WHERE post_type = 'wd_ip_lockout');
    DELETE from wp_posts WHERE post_type = 'wd_ip_lockout';
    
    DELETE from wp_postmeta where post_id in(SELECT ID from wp_posts WHERE post_type = 'wd_iplockout_log');
    DELETE from wp_posts WHERE post_type = 'wd_iplockout_log';

    Please keep that in mind get a full backup before doing this and check the website after doing this. So if anything goes wrong you can revert back. But that SQL codes should clean only Defender tables and data at other tables.

    I hope that helps!

    Cheers,
    Oguz

  • Ben

    Oguzhan Selcuk Bulbul

    https://premium.wpmudev.org/forums/topic/defender-logs-populating-the-database

    Posted about this issue here...still waiting to hear back.

    I care about the community and can say there is probably a large portion of you audience that wont be able to perform this task...meaning the database will still be clogged...thinking we need a one button solution that can:
    1. Check database tables to see if they need to be cleaned.
    2. run the commands you suggest.
    3. Check if its a multisite
    4. go through all the subblog tables and perform the same operations

    I have a multisite(a few) so looking for a solution that can loop through all the tables safely.

    Thoughts?