Trippetchz

For example:

Hi there,

Okay.

But just to comment, I don’t understand that problem, as described.

At least with Apache-compatible implementations, the .htaccess file resides with the WordPress root, right? So even if WordPress was installed in a directory, say for example, https://example.com/alice/, the .htaccess file would reside in something like /public_html/alice/.htaccess and hence rules from there would be relative, as with root directory installs?

I don’t know though as I haven’t tested that deployment.

In any case, it should be unwanated behaviour to redirect the replaced /wp-login.php or /wp-admin strings at the *end* of a URL.

Good luck and thanks!

Nice one. ??

Thank you for reply. Yes, undocumented breaking change with -1 was our issue as previous versions of the theme used -1 as “show all.”

Thank you for your help fixing.

That’s really disappointing.

This appears to be fixed in 2.0.8. Thank you!

That’s great news, thanks.

Well, if that’s how it’s supposed to work, it’s not happening. Here’s a screen recording to further illustrate:

https://archive.org/download/2022-03-15-21-30-15/2022-03-15%2021-30-15.mp4

The update time is always wrong.

• This reply was modified 2 years, 8 months ago by Trippetchz.

Hello there,

I see you have made some changes in 2.0.1 to begin ironing this out. Thanks!

Unfortunately, the bug isn’t completely squashed, although behaviour with ‘Date Recorded’ seems to be better.

Listing members in the admin “Date Recorded” times is now correct, but “Date Updated” isn’t, both on individual records, and in the list. Here are the screenshots to illustrate what I mean:

The “Date Updated” time should match the “Date Recorded” in above example as it was both created and saved at the same time.

And for an example of an edit, my local time (Australia/Melbourne) is 13 March 2022 7:03pm but the field shows 13 March 2022 8:03 am

• This reply was modified 2 years, 8 months ago by Trippetchz. Reason: typo
• This reply was modified 2 years, 8 months ago by Trippetchz. Reason: context

Thanks for getting back.

So just to clarify, does that mean this feature is being developed?

Thanks for the consideration ??

PS: Also, hopefully with something like wp_date() you won’t have to reinvent the wheel, as it looks like in participants-database\classes\PDb_List_Query.php and participants-database\classes\PDb_admin_list\query.php with all the hardcoded calculating a difference from UTC and Linux epoch—which is precisely the problem here: what happens if UTC is never used or FROM_UNIXTIME is wrong (because again, like above, these are hard low-level server settings that cannot be changed on a shared host)?

I hope I’ve made the case that using a WordPress function to write dates/times will be much easier for you in the long run, less buggy, less complex, and more flexible for other people’s timezones.

??

Fair enough.

But the problem outlined above is: since you say you’re using now() to write the times instead of something that goes through WordPress’s settings (like wp_date() for example) this bug will persist in setups like mine (and many other shared hosts) where the date settings vary between the webserver, mysql sever, and the default PHP settings—and these cannot be easily changed (if at all) on shared hosts (which is why I tested three different servers with different hosting companies and could replicate the result on each).

This is why I suggest using the settings that WordPress applies to PHP (i.e. the WordPress timezone setting) and a function like wp_date() to do writes that captures this setting. I can foresee this would solve the problem of mysql writing its now() time which may be different to the PHP timezone (as illustrated above), and may also solve any time shifting issues you may have had in the past with other setups also diverging from UTC—because the times PD will *always* be writing a time that is in sync with the WordPress timezone setting. This solves the problem of having to rely on the system defaults (which, as above, can vary wildly and have nothing to do with the WordPress settings).

Judging by your post mentioned in the OP, and the comments on that page, it seems like you’ve had a few other people mentioning timezone quirks in the past, so I think I’m surely not the only one. Perhaps the difference here is that I’ve provided a more comprehensive bug report than simply “it doesn’t work.”

Anyway, long story short, I hope you’d consider at least experimenting with a change, otherwise we might have to resort to getting the plugin hacked to fix this bug, which is unwanted cos it will wipe us out on every update…

I think this is a great plugin and want to help it succeed!

So, to help convince you, and allay your concern, I imagine the change would be transparent for those *not* facing issues with now() because the timezone setting would be unchanged in that use-case, and I also don’t think it’s a dangerous change to move from now() to something like wp_date() in any event—the WordPress time/date functions are well documented and something like wp_date() was specifically designed and deployed in 5.3 to solve many of the legacy issues with locale quirks like this.

TLDR; I hope you consider at least testing some changes!

If I can be of any help, please let me know. We’d love to use this plugin in our grassroots community group, but the record dates need to be correct for us for book keeping reasons.

Thanks!

• This reply was modified 2 years, 9 months ago by Trippetchz.

… or wp_date();

Thanks for getting back.

OK, I see that the plugin is inconsistent about how it applies the timezone.

Great, thanks.

If the db server timezone is not UTC, that might throw things off…I have never tested a setup like that.

Okay, to assist then, here is a rundown on the setups for the three different servers/hosting accounts I tested and had the inconsistencies:

First server, European host, web server timezone is IST, mysql database (mariaDB) using “SYSTEM” timezone and now(); matches; the default system/account setting for PHP appears to use UTC:

Second server, host was Greengeeks in United States, server in Amsterdam, web server timezone is CET, mariaDB using “SYSTEM”, host allowed changing PHP.ini setting to Melbourne:

Third server, host and datacentre is in our country (still cPanel shared host though), timezone AEDT, database also same, but host does not allow PHP.ini so PHP defaults to UTC:

So, how can we tackle this on shared hosts? The webserver timezone setting cannot be changed, maybe DB timezone could be (but I’m not sure, and would probably also vary host to host) and the PHP.ini settings sometimes can or cannot be changed for the whole account, also depending on the host.

I’m not a developer/not at all great at coding, but my first thought is, would it make more sense for Participants Database to use the WordPress current_datetime() (introduced in 5.3) instead of now() to do all the database writes? That way you avoid the potential differences between webserver/mysql time and PHP time, AND also capture WordPress timezone setting?