mardala

If I see an issue that might be related to a url (which guessing from your issue might be?), go to the Settings -> Permalinks and save (don’t change anything just resave) .. it should refresh the permalinks. Without knowing if this plugin does any kind of url rewriting.

Its simple and free to fire up a basic server instance on AWS. We get this a lot. We also use AWS for hosting everything for our company.

If I feel up to it I also report the IP and send a sample log to AWS. They respond pretty fast and turn it off.

https://aws.amazon.com/forms/report-abuse

sometimes just emailing [email protected] will go to the right place ..

This also doesn’t take into account sending from the server where the site is hosted is not always going to match the FROM field in the email of the site that hosts the contact form.

Also on a multisite where forms are purely for contact leads, sending (in our case) is managed using an SMTP server thru AWS with hundreds of sites and will never match the domain in the FROM field (as that matches the smtp server so emails are not bounced). Use the Reply-To for the sender.

Not sure if this is the same issue we encountered – but I was noticing on our multisite the subdomain (where we restrict logins to) showed the correct url to the plugins, but when on the live site domain it was like this: https://www.somesite.coms?ver=asdfsdf .. after tracing thru I found the issue in this plugin.

One thing we do differently is we define the plugin, themes, upload paths in wp-config for our setup.

The fix — in the domain_mappings_plugin_uri function there is this line:

get_option( 'siteurl' ) . substr( $full_url, stripos( $full_url, WP_PLUGIN_URL ) - 1 );

Removing the “-1” fixed it. Or better yet, we detect if its calling the plugin path from an absolute url or not.

$_pos = stripos( $full_url, '://' );
        if( false === $_pos ){
                $dm_plugin_uri = get_option( 'siteurl' ) . substr( $full_url, stripos( $full_url, WP_PLUGIN_URL ) );
        }else{
                $dm_plugin_uri = get_option( 'siteurl' ) . substr( $full_url, stripos( $full_url, WP_PLUGIN_URL ) - 1 );
        }
        return $dm_plugin_uri;

Again .. not sure if thats your same issue but it sounded similar enough.

Thanks! Great find. I updated this morning and just random sampling sites that had issues previously seem to be corrected.

And one more update: https://github.com/Yoast/wordpress-seo/issues/1780 .. apparently this is not a bug, but something that will hopefully be implemented in a future update?

If it helps I have a script that I run to check which sites have sitemaps that are incorrect. I haven’t spent much time on the issue but another xml sitemap plugin had run into this issue and fixed it – commercial one though and the fix was never posted on their support channel.

The script – run at your own risk but I’ve never had an issues with it. https://www.dropbox.com/s/t38odjjcx0f2ijw/checksitemaps.txt?dl=0

Experiencing the same issue and put in a question a few weeks back that never got answered.

Did you quote the string password?

I was looking up another topic and came across this. Having debugged issues with Facebook off and on – have you tried putting the url to the page in this tools? https://developers.facebook.com/tools/debug/ You get all the info about the post, including what image its pulling. This url also allows you to uncache posts to facebook.

If the images smallest dimension is less than 200 px then you get random images from other posts – the one in og:image.

Are these in multiple categories?

Permissions? If the file / folder permissions are not correct then it will be the same as if the app cannot find the file.

I don’t think is totally answers your question, but something we did for having a wordpress driven site on 4 servers. 3 delivery servers are managed behind a proxy, so the 3 servers all think they are the same domain.

We created an admin subdomain. The admin subdomain is where all writing, uploading, editing etc is done.

By simply hard coding in wp-config.php we set the admin server to ingore the site url and home url in the database.

e.g.
// ADMIN:
// define(‘WP_HOME’, ‘https://admin.site.com’);
// define(‘WP_SITEURL’, ‘https://admin.site.com’);

// DELIVERY:
// define(‘UPLOADS’, ‘https://cdn.site.com/uploads’);

Note – We also have a cdn. The CDN is on the same physical server as the admin, so its just a simple symlink from the uploads directory to the cdn root.

As far as having a staging – live environment that would be a little more tricky and can’t think of a solution off the top of my head, but brings up an interesting point.

Just to clarify the above, I used this to get pagination working on pages that were categories. So the url above would be like: site.com/nightlife/page/2/, site.com/nightlife/page/3/ etc …

This was in conjunction with the WP-Pagination plugin https://www.ads-software.com/extend/plugins/wp-paginate/

I had a similar experience and this is what I ended up doing.

Example has 10 posts per page and is very similar to the above where you have a $paged var @ the top, then build a query.

Note – I added a check to see if there were less than 10 posts for the page because the posts flowed in varying div blocks and needed to make sure the divs were closed properly.

@ the top: $paged = (get_query_var(‘paged’)) ? get_query_var(‘paged’) : 1;

before the loop:

$offset = ($paged*10)-10;
$offset = ($offset <= 0) ? 0 : $offset;
$args = array('category_name'=>'nightlife','posts_per_page'=>10,'paged'=>$paged,'offset'=>$offset);
query_posts($args);
$posts_remaining = $wp_query->found_posts-$offset;

Then just loop thru the posts normally, ie. while have_posts(); the_post(); etc…