Elmoonfire

I have seen it work for others with Visual Composer. I’d try putting the code in a RAW HTML element and see if your issues clear up.

Had the exact same thing happen to me with a different visual builder. I used the code block element and it worked perfectly fine after that even with 5 other device mockups on the same page. I believe VisualComposer has a RAW HTML element. I would try putting the code in there and see if it works for you.

Hi Mizuho,

You are awesome. Thank you so much for tackling this so quickly. As luck would have it FooGallery published an update that fixed exactly the same issue at almost exactly the same minute you posted this. I have no idea why when just one of the two plugins were active everything worked but not when both if they both suffered from the same problem but either way it is working now!

Do you accept Bitcoin donations? If not that is no problem I can do Paypal.

Thank you!
-Hayden

For me the NextGen Gallery plugin had CSS for the same styles and was overwriting the styles from this plugin because unfortunately they use !important. I could manually modify the nextgen styles which would fix it. It has to do with the z-index level. Nextgen was changing it to be higher than the modal.

That is exactly what has been happening to me. All it means is the posted date is being considered in the future. I will try testing on other installation with different timezones to find out whats wrong. You use the actual gmt_offset instead of the timezone_string in both of your installations right?

Yes it does because it uses the same code as 1.9. What happens to your dates when you use the code from above?

Just wondering if you are going to implement my fix for the timezone issue. It should be correct. I checked php.net and this description of gmdate() correlates to what I was seeing.

Identical to the date() function except that the time returned is Greenwich Mean Time (GMT).

I’m thinking that it takes the $posted_date (which is already UTC time) and outputs it to what it thinks UTC time would be for that given timestamp based on my offset from UTC. Which has the result of doubling my offset.

Ok I believe I have figured it out. You can revert that last change. The current_time() and time() functions were producing the same time.

The problem relied on the gmdate() function. It was actually adjusting the date based on the offset from the gmt time and then compounding it with the offset we just determined in the if statement right above it. In addition the $in_seconds variable was being set before the $posted_date was being adjusted by the offset.

The following lines need to be adjusted to the following but everything else was fine and doesn’t need changing:

$cur_time_gmt = current_time(‘timestamp’, true);
$posted_date = date(“Y-m-d H:i:s”, strtotime($posted_date) + ($gmt_offset * 3600));
$in_seconds = strtotime($posted_date);

This is working for me but probably needs testing for other timezones/environments.

Hmm, the front end relative dates are still not appearing properly for me. I’ve deleted all of the plugin files and uploaded with the contents of the zip file you linked and the relative dates still show “3 weeks, 6 days ago” for every action that occurs right now until 8 hours have passed then it shows the correct relative time based on UTC time. 8 hours just so happens to be my offset from UTC time.

Ahh I didn’t know that was the way to properly store dates in the database. I had seen before 1.9 that some dates were stored in my timezone.

As for the timezone setting I do know that my wordpress install is using ‘timezone_string’ instead of ‘gmt_offset’ because I had picked my actual timezone.

Thank you for your support!

I just noticed that failed logins appear to log the ip. Would still be nice to have it for logged in users. Thanks!