Vimpelli

So I submitted the issue to the plugin developer and they were going to dequeue Themify’s time picker in the plugins javascript. But in the meantime, it seems like the latest calendar update beat them to the punch and may have fixed the conflict.

Hi @barryhughes-1,

Thanks for your reply. It appears that one of my plugins is causing the issue. It is called Themify. It is a drag and drop page builder. I am not exactly sure where to go from here. This plugin plays a major part in our website development for our clients, so I can’t just stop using it. Any suggestions?

Hi There,
I lost track of this post. My apologies. I have ensured the time format is set to g: i a

I am not sure if I am being misunderstood though. The time displays correctly on the front end. My issue is in the way the time picker functions. It uses military time. Is there any way to change this?

View 1

View 2

As you can see, my timezone is set correctly as well.

Is there any way to just hide the end time only? The end time for our sign up slots vary and we’d rather just show the start time.

Thanks

I had the exact same issue; product broke dependency after 30 variations. The above code fixed it. Website in question was running WP v4.6.1 and Woocommerce v2.6.4. Thanks!!

The number of stores it needs to convert doesn’t change at all, even after setting it to 100000?
If you check the ‘All Stores’ page there is nothing there?

> Correct, the number of store locations that need to be converted never changes. It’s been at 74994 since I started trying.
> Correct, the ‘All Stores’ page shows nothing.

Do you happen to have all the stores locations in a csv file?

> Yes! I do have all the stores in a csv file. It’s an 11MB file.

Can you run this sql query in phpmyadmin, and see how long it takes to complete? Do replace the ‘name_of_your_db’ with the name of the actual wpsl table, it looks like this dbname_wpsl_stores

> I was not able to successfully run this query in phpmyadmin. When I tried to run it the first time, it ran for exactly 5 minutes before giving a 500 internal server error. I tried running it a few more times, just changing the number of rows queried, and it worked with anything under 5,000 rows. Then I went and looked in the /usr/local/cpanel/logs/error_log file, and it showed this: PHP Fatal error: Maximum execution time of 300 seconds exceeded in /usr/local/cpanel/base/3rdparty/phpMyAdmin/libraries/DisplayResults.class.php on line 2959
Which makes sense because it was erroring out at exactly 5 minutes.
So I tried running the query from a remote mysql client – Sequel Pro – and it worked perfectly. It was able to return all 74994 rows in 1.19s. I ran it a few times and every time it worked perfectly.

Thanks for the reply!

Changed the interval to 30000
> still get the timeout message
> nothing in the debug.log.

Changed the interval to 100000
> runs for a lot longer, but eventually I still get the timeout message
> nothing in the debug.log.

Just for kicks, I tried it in a different browser, all the to same effect. For the record, this is a pretty clean install too. Turning on wp_debug doesn’t generate any warnings or errors, and only one notice.