jadeburn

Disappointing further update on problem reported by @royzband

After a few days, we noticed that the problem was still there, but this time with a twist that may be noteworthy or not.

Dates within the next 90 days are still shown correctly, but dates more than 90 days in the future are showing with the 1-day offset (-1) on the public view.

One additional observation that may help is that the problem is even noticeable within the admin pages:

• The admin “upcoming performances” list view also shows the -1-day offset.
• The admin “add/edit” view must be set +1-day in order to counteract the -1-day offset in the other views.

I’m not sure what could explain this. Perhaps the plugin author has some thoughts.

Update on problem reported by @royzband

Dates were still showing as -1 day.

After reading through this thread, I tried changing the timezone in WP settings.

Previous settings were UTC-05, and I changed it to use “New York” and that solved the problem. The dates are now showing correctly.

I didn’t dig deeper than that, so I don’t know whether the change worked because WP treats a name-based timezone differently, or if all that was required was a resetting of the timezone.

But either way, it worked.

I’d love to know the answer to this too.

FYI, I solved the problem by purchasing the pro version so I could create additional ads with different behavior and only have the automatic corner roll down on the homepage.

<?php
if ( is_front_page() ) {
    // This is the front page (homepage)
    echo do_shortcode( '[corner-ad id="1"]' );
} else {
    // This is not the front page
    echo do_shortcode( '[corner-ad id="2"]' );
}
?>

But if there’s an ability to control more finely using cookies, that would be fantastic.

I’m seeing exactly the same result. The “Global Search and Replace” is only searching in the users table.

I love this plugin and have used it on all my sites, so I hope this gets corrected soon.

Thanks.

Thanks Kimberly,

Your suggestions helped me to figure out the cause.

Somehow, I don’t know how, the site had been hacked and malicious php code had been inserted into multiple files.

This must have happened around the same time as a series of updates we were performing and I must have carelessly approved the alert I received.

But somehow, File Monitor Plus kept track of those changed files and kept alerting me to them. Everything it showed me was the seemingly unchanged, as in the example above, so I never actually looked at the files, but those same files were the ones that had been hacked.

So, I started looking into the files as you suggested and discovered the hacks. Now I’ve cleaned all the files and I’m no longer getting those alert emails.

Thank you for your suggestions. You helped me solve it. I’m still not clear how File Monitor Plus kept alerting me to those files even after the alerts were cleared, but I’m glad I did, or this might have gone unnoticed a long time.

Cheers,
Jade

FYI, I would like to request the same feature.

We have on average, 3 administrator users and 1 author per client’s WP installation.

The author xml sitemap function of this plugin treats administrators as authors (unless the username is admin) and sadly, does not automatically omit authors with 0 (zero) posts, which it logically should.

So, to enable the author xml sitemap, we have to be willing to have our administrator accounts exposed in unnecessary and empty xml sitemaps.

This should be a simple if(posts = 0) statement in the plugin and I would hope that the Yoast team would add this functionality on the next update.

Thanks in advance for your consideration.

Excellent, thanks. That worked for me.

For the developers, here’s a list of sociable’s identified errors:

incorrect use of a leading slash following the "SOCIABLE_HTTP_PATH" variable in the file plugins/sociable/sociable.php.

incorrectly stated root paths to images, such as: src="/wp-content/plugins/sociable/images/skyphoto.png" in the file plugins/sociable/includes/class-sociable_Admin_Options.php

missing "http" in the src URL for the Facebook iframe in the file plugins/sociable/sociable.php

incorrect redirect URL for function sociable_2_remove() in the file plugins/sociable/sociable.php

incorrectly stated root paths to images in sociable/css/sociable.css

FYI, some of the problems I’ve experienced (definitely not all) result from the fact that many of my installations are not in the root, so the URLs are domain/blog and the errors are being caused by sociable incorrectly assuming the installation is in the root.

As a result, I’m seeing errors like domain/wp-content because the path should actually be domain/blog/wp-content.

See my original post above for some of the instances of errors in the code. There are other posts in this forum about the same problem in sociable.css

I’ve completely disabled sociable until it’s fixed. My error logs were getting too full. So, my URLs don’t matter.

This has been an increasingly frequent issue that I’ve written to the developers about at least twice in the past couple of months.

There are a number of problems which I’ve identified and I have fixed them on some of my sites. Each subsequent revision I’ve hoped they would fix the problem, but instead there’s simply been more of the problems.

For instance, the issue DebNCgal wrote about initially is caused by the incorrect use of a leading slash following the “SOCIABLE_HTTP_PATH” variable in the file plugins/sociable/sociable.php.

But there are numerous new instances of incorrectly stated root paths to images, such as: src="/wp-content/plugins/sociable/images/skyphoto.png" in the file plugins/sociable/includes/class-sociable_Admin_Options.php.

Other issues include a missing “http” in the src URL for the Facebook iframe in the file plugins/sociable/sociable.php.

I love this plugin and hope the developers are able to find and fix all these problems. I’m not PHP expert and I’m able to find many of them, so they should be able to as well.

Hope this helps a few people.