kindred

I apologize…. I thought I had posted an update.
There is no problem with the module — I was using it incorrectly.

The correct syntax to use the shortcode with a variable is this… and now it works
(Suggestion, make this easier to find in your FAQ)

[preorderbook bookid="1234567890"]

Thank you!

Turns out, it was not the WP-Optimize that caused the problem, but Admin and Site Enhancements (ASE) which turns the REST API off “for security”. I thought that had been running prior and only the Optimize plugin was new – but it seems that one of the other admins may have changed the setting. I appreciate the quick response!

Never mind…. this problem appears to be with the Divi theme code…. the ACF code is never being called within Divi

Hi Bayejid,

I see the update and have applied it.
I found the timezone setting and applied UTC-4 (I am currently in the Eastern Daylight Time — GMT-4)

However, the time displays incorrectly.
it is currently 12:30 PM May 24 here
UTC is 4:30 PM May 24
If I leave the setting as “Select a timezone”, the module displays, the module displays 4:26 PM May 24
If I set the setting to UTC-4, the module displays 4:26 PM May 24
If I set the setting to UTC+0, the module displays as 8:26 PM May 24.
If I set the setting to UTC+4, the module displays as 12:26 AM May 25.

Now, I can “workaround” this, by applying UTC-8 as the timezone, but that is not the actual zone.

It looks like the module is somehow assuming UTC as 4 hours ahead of actual UTC to start…

I do confirm that the override location is now working correctly!

• This reply was modified 2 years, 10 months ago by kindred.

Sorry for the delay. Confirmed, this issue is now resolved!

Sorry for the delay. Confirmed, this issue is now resolved!

Hello, and thanks for the response.

I have read the guide and applied the logic described there-in.
I turned OFF “Unique String after the Filename” in case that was being rejected by server security rules (no effect)

I have talked to the host, and they attempted to debug the issue without any resolution. (This is a good host who has helped me in many cases where other hosts would have said “not our problem, talk to the developer of the script”.)
Looking at the server logs, there was no useful information from the failures. The Server did not generate any error, but the SCRIPT returned “file not found”.

Failed file: 1.3GB ZIP
Successful file: 200KB ZIP

So, the question I have (and my host confirms) is — Why would the script generate a “file not found” message with the large file? The file is definitely present. WordPress itself can see the file (present in the media manager)
The large file is in a separate directory, so as to keep the commercial stuff separate from the rest.

Is there a limitation on where the file can be located?
(e.g. does it have to be in the woocommerce_uploads/yyyy/mm/dd directory structure that woocommerce defaults to?)

Update:

2 things changed…
1- I uploaded the file to be used directly through the WordPress interface, therefor using the woocommerce directory from the settings.
2- the test files this time were MUCH smaller.

Is the problem related to the directory or the size of the files?

If it’s a file size issue, this means that woocommerce can not work for my implementation. ??

• This reply was modified 3 years, 1 month ago by kindred.

Odd and interesting. Thank you for finding the issue. I look forward to seeing the update!

email sent.

personal hosting on ICDSoft. I never use auto-installers.

hmmmm, I have no plugin to do that — I get it on all of my sites (which have different set of plugins) so I assumed that the choices were wordpress standard functionality

Sorry to take so long to respond, again.

I have updated to 3.2.1 — and the issue seems to be fixed.

You marked it as Resolved — but it has not been resolved. The issue still exists. Time still shows GMT instead of EST. Since I am up-to-date with the most recent version, although you added the fix into the PLAN, I do not believe that it has been IMPLEMENTED yet — and so the issue remains UNRESOLVED.

Additionally, the second issue (Override Location Name does not override) also remains UNRESOLVED.

Thanks for the response.

The firt failure definitely had to do with the ampersand in the title.
After I changed the title of the NextGEN gallery to “Cars and Canines” instead of “Cars & Canines”, the import succeeded without issue.

The second failure definitely had to do with server resources — the files were huge and the images were 9000pixels wide. I stopped trying after the system created 4 duplicate (empty) FooGalleries, used GIMP on my local computer to reduce the image size (which reduced the file size as well) and uploaded directly to the FooGallery rather than trying the import again.