DBAR Productions

That text does not appear anywhere within my plugin. If fact I searched for that phrase in my entire dev WordPress install and could not find it in ANY file from WordPress or all the other plugins I have installed (all my extensions and some others). So, it’s not even something that WordPress itself would output if someone tried to create an account with an existing email.

I’m guessing you have some other plugin that you use for a custom registration form for user account? I didn’t see any registration pages on your site, so that must be a non-published link. I imagine that’s the type of error message that would be shown if someone tried to create a new account using an existing email. That text must be coming from another plugin, unless you used something like my Customizer extension to modify one of the messages to say that? But, my plugins have nothing to do with account registration.

I would strongly suggest that you have one of those users who report the problem do a screen grab video showing exactly what they did to get the message. Or, at the very least, describe step by step what they did.

Or is it possible that the message they are getting is the message when they try to sign up for the same task more than once and you have not allowed duplicated signups. The default message for that is “You are already signed up for this task”, but if you use my Customizer extension, you could have changed that text (or someone else may have). That’s the only other thing I can think of that would actually come from my plugin, and is not a bug if you are not allowing duplicate signups for tasks.

Also, if you are NOT using user accounts for your volunteers then you can turn off that message that my plugin generates that says “If you have an account, it is strongly recommended that you?login before you sign up?so that you can view and edit all your signups.” Check your settings, you can disable that message by checking the checkbox for the “Disable Login Notices?” setting.

Thanks for letting me know. I’m glad you figured it out.

Yes, you must have modified that file at some point to make “time_start” a required field, because in my code there are no required fields for tasks in the data.php file. In mine it’s just:

'required_fields' => array(),

The main required fields for tasks are handled separately when the form is submitted via code in the admin file. The above code in the data.php was an old data structure from the original plugin that I forked many years ago for our school’s PTA website and modified to fit our needs. Fields are allowed to be blank on the admin page since you may not use all 3 of the empty task fields that are shown initially. So, only tasks that have at least a title are actually processed and saved when you save the form. Others are ignored. Some of the required fields, such as task date, are handled differently depending on the type of sheet (single, recurring, multi-day).

The admin file: class-pta_sus_admin.php
does make a call to the data->validate_post method, if there were no errors up to that point, and there it will check the require fields defined in that required fields array at the beginning of that file. So, if you were intending to make ‘time_start’ a required field, then your code should work. However, your translation probably failed because you were using a much older text domain string. Originally, many years back, I used the ‘pta_volunteer_sus’ as my text domain, but then when they changed things to allow people to translate via the page on www.ads-software.com, it would say that my plugin was not prepared for translation because the text domain did not match the plugin directory name. So, I had to change the text domain to:
‘pta-volunteer-sign-up-sheets’
Which may be why your original code failed.
There are several text strings that only appear to admin that I never set up for translation in my plugin, including those required fields in that data.php file (you will see the ones for sheet are not set up for translation). You could try replacing the domain in your original array with the proper text domain and see if that fixes it for you. I would have to do some testing here as well to make sure those don’t get instantiated too early to mess up the translation, but I don’t think there would be a problem.

I did find and read that, along with a longer description somewhere, after your initial post. According to the posts I read, plugins & themes no longer need to use certain functions to load the textdomain/translations since version 6.5. However, in the longer article I read it did clearly state that plugins/themes can continue to use those functions for backward compatibility. I know plenty of people don’t keep their WordPress versions up to date, so I can’t afford to remove those functions yet. But, it clearly also states that they just removed some of the functionality of those functions, and now they only register the text domain and don’t actually load anything yet.

It does mention not to try to load the text domains too early, but I double-checked my code, and I’m not calling the load_plugin_textdomain function until the init hook, which is the proper place to do it (not before). So, I have not seen any of those warnings they mentioned about “doing it wrong”.

They do mention that their new approach is for WordPress to automatically load the translations “just in time” (so no need to use those functions anymore). But, obviously, something with that is not working right yet. If that’s a WordPress issue, there is nothing I can do. I can find nothing in those articles that say we need to change anything about our translations, other than not calling those functions (which don’t even need to be used anymore) too early to avoid warning notices (does NOT say it will break anything).

Obviously they aren’t going to drastically change they way that developers need to set up translations, or else it will break just about every plugin and theme out there. Anything they do needs to be backward compatible to the “old” way, or else all the developers would need to add a ton of new code to check which version of WordPress is being used and load translations differently depending on the version. That’s not something WordPress typically does.

I will create a new foreign language WordPress install and do some testing of my own, but my guess is there is something still not working quite right with their new “just in time” automatic loading of translations files.

Also, you didn’t answer about what translation you are using and if it is working on earlier versions of WordPress on you site? Have you enabled debug logs and checked for errors/warnings, if any? If you are testing pre-release versions, then you can submit your findings via an official WordPress bug reporting ticket:

https://make.www.ads-software.com/core/handbook/testing/reporting-bugs/

If it’s something I need to change in my own plugin, I will happily do it. But, from all the documentation I’ve read so far, plugins/themes do not need to make any changes, other than making sure they aren’t calling certain translation functions too early.

Also, as a side note, if your site is in one specific language, with no language switching for users, you can also use my Customizer extension to personally modify every public side text string that appears to exactly what you want it to be:
https://stephensherrardplugins.com/plugins/pta-volunteer-sign-up-sheets-customizer/

WordPress 6.7 has not been officially released yet, so you must be using a pre-release version. It clearly states in the development/version log that these versions should not be used on live sites.

I have not changed anything having to do with translations for a long time, and I don’t see anything in the development log about WordPress making changes to how translations are loaded… it would be stupid if they did because they would break just about every plugin and theme out there that have been made ready for translation.

I would wait until version 6.7 is officially released, as there is most likely some bug in it that is breaking translations in the pre-release version you must be using.

In addition, all of the existing translation files in my plugin are most likely out of date, as they were all submitted by various users and are all at least several years old. So, there are most likely some newer text strings added in my plugin that are not included in some of those translation files.

Otherwise, you’ll need to be much more specific about what’s not working. Which translation? Was it working previously? etc.
As I said, I have made absolutely no changes, especially not since the last release version of WordPress. So, if it was working previously, and now is not, then it’s simply because of some bug in the pre-release 6.7 version you are now using.

This question has been asked, and answered, multiple times, although probably buried deep in the old threads by now. You can also clearly figure it out by reading the documentation and going over the general settings. Documentation is here:

https://stephensherrardplugins.com/docs/pta-volunteer-sign-up-sheets-documentation/

These are the copied and pasted descriptions (from the above documentation page) of the two settings you need to look at:

• Show Expired Tasks??— If you want to view signup info even after the dates have expired, check this box. This ONLY affects the signup lists on the ADMIN side. The public sign up sheets will never show tasks/signups that have expired. Make sure the next option is NOT checked, or else old signups will be purged from the database and not viewable.
• Automatically clear expired signups??— Enables the hourly CRON function that checks for and deletes expired signups from the database. If you want to save your signup data after a task date has passed be sure to uncheck this and then check the above option to be able to view the expired tasks/signups on the admin side. If later on you want to manually delete all your expired signups, use the button on the CRON Functions page. For example, it is useful to clear all signups so that you can alter the dates on a sheet and reuse it for the following school year.

If you had that second one checked (should be unchecked by default), then it’s too late and your old expired signups will have been deleted from the database and you would only be able to retrieve them through a database backup file on your server (assuming your server backs up daily).

Note that you can now automatically send thank you emails to all volunteers any # of days after the end of an event using the new Automated and Conditional Emails extension:

https://stephensherrardplugins.com/plugins/volunteer-sign-up-sheets-automated-and-conditional-emails/

There is nothing that’s incompatible. I don’t update my plugin with a new tested value every time WordPress releases a new version, but it’s still working just fine.

I’m not familiar with Brevo and whatever plugin you use to connect to it. But, it’s possible they made an update recently that is rejecting emails from my plugin for some reason.

If reminders are being sent, but the clear and reminder emails are not, then my best guess is that you maybe have a “CC email” set in my plugin in the Email settings, which is used to send a CC copy for reminders and clear emails. If so, then it’s possible that Brevo, or your SMTP plugin that connects to Brevo, suddenly doesn’t like the CC email format my plugin uses. There is another setting at the bottom of the emails settings page in my plugin that you can check “Separate CC/BCC to individual TO emails?”. If you check that option, instead of using CC or BCC to send to the additional recipients in one email, my plugin will send a separate email to each of the addresses. Try that to see if it fixes the issue. If it does, then maybe notify whoever makes your SMTP plugin that their plugin is now rejecting CC/BCC emails that are formatted according to the original specs of WordPress outline for their own wp_mail function, since that is how I format my email headers and info.

If that’s not the issue, then check to see if your SMTP plugin has a log file you can check, and maybe it will give a reason why the email wasn’t sent. Or, if there’s nothing in your SMTP plugin, or its log file, you can see if there is any kind of log for your Brevo account that can shed some light on what’s going on.

OK.. Let me know if you need any help. As a customer of the paid extensions, you can contact me directly through the contact form on my site if you need help with anything. Thanks for your support!

The only option right now to give you more detailed control over emails (and also allows HTML emails) is the relatively new extension Automated And Conditional Emails:

https://stephensherrardplugins.com/plugins/volunteer-sign-up-sheets-automated-and-conditional-emails/

This is a very complex extension that I did as a subsidized project for one specific client, and it’s a bit hard to understand what it does, how to set it up, and what you can do with it, so there have only been a few purchases so far. However, one of the things I have done since its release is to set it up so that you can pretty much replace all the regular emails with this system using various triggers. You would then just disable all the emails in the main/free plugin that you want to replace with this extension.

This extension gives you much more control over the emails as you can set email triggers for only specific sheets (as opposed to globally), and you can set up various lists for who those emails will be sent to (which can be specific emails, or can be a generated list of people signed up for that sheet or task, etc).

It’s very flexible and powerful, but you need to have a bit of a technical mind to set it up correctly. Don’t need to be a programmer, but a basic understanding of logic helps. Otherwise, you are correct that the settings in the main/free plugin are global and can’t be set for individual sheets.

Thanks for letting me know. Glad you got it working!

If I’m not mistaken, I believe Siteground has its own plugin that it installs on WordPress sites automatically for various purposes, and I think one of them might be to enable the Redis server side caching. That caches common database calls to greatly speed up sites. So, you may want to check to see if they have that enabled. However, it’s more likely that you have some other caching plugin on your site that may be caching full pages to speed up the site, and those are usually the culprit in these situations. If that turns on to be the case, you’ll need to see if you can exclude certain pages from caching.

Other than the Visible/Hidden toggle, there isn’t a way to prevent individual sheets from showing to just certain users unless you are also using the Groups extension. Are you using any of the paid extensions?

My guess is that the pages the new sheets are not showing on are being cached by either a caching plugin or server side caching, or possibly even browser caching. Try holding the shift button and reload the page a couple of times to clear any browser caching. Then, check to see if you have a caching plugin installed and turn it off on the pages that shouldn’t be cached (where you want to see changes right away). This would make sense that it’s a caching issue since it’s not showing on existing pages, but when you add a new page you can see it (the new page hasn’t been cached before you created the new sheet).

Yes, the last reminder check should update any time that function is run.

If it works when you run it manually, then it’s something with the CRON function not triggering the corresponding action in my plugin. The CRON action in my plugin calls the same functions that are used when you manually trigger the functions (reminders, deleting expired signups, reschedule emails).

So, from your tests, we know that there are no errors and the function that sends the reminders is working when you trigger it manually (also without errors). That just leaves an issue with the “real cron” call of wp-cron.php somehow not triggering the action in my plugin that runs the same functions.

If you keep testing on your end, I will see if I can set up a test site on a real server (not my local dev environment) where I can use a real CRON function to trigger wp-cron.php, and see if I can replicate the issue. If so, I can try to figure out a way to make sure my action gets registered and triggered when wp-cron.php is called that way. That could take me some time also.

This is a tough one for me to help you without access to your site/server. I haven’t changed anything with the CRON functions for a very long time, and I have not had any reports from others about similar issues, so I don’t believe it’s a code issue. This is most likely something specific to your server and install.

Have you checked with anyone to see if the reminders are actually getting sent or not? Or create a test event and sign up yourself to see if you get any reminders yourself?

My guess is that somehow the way you have set things up, the CRON job/function is not getting triggered properly, especially if in addition to no reminders being sent you also are not getting expired signups cleared. Reminder emails, Reschedule emails, and the purging of expired signups, are all triggered off of one function that should get called anytime that CRON hook is triggered.

The first place I would check is your server’s PHP error log to see if something is throwing errors when the WordPress CRON function is triggered. It’s possible some other plugin’s CRON functions are causing a fatal error, thus preventing further execution of any other CRON functions from other plugins. If you don’t see anything there, you may want to temporarily configure the WordPress debug function and set it to debug to a log file (NOT to the screen), and see if you see any errors or warnings in there when the CRON function gets triggered.

Also, the Action Scheduler is not part of WordPress core, and is usually installed by other plugins (such as WooCommerce). Action Scheduler is set up in a way that it should use the newest version if there are multiple versions of it installed (via different plugins). Unless you absolutely need it installed as a stand alone plugin, I would uninstall that plugin and let WooCommerce or the other plugins keep it updated. Sometimes a job fails due to errors in the code for the job or because a function took too much time and it timed out before it could finish. That doesn’t mean that there is something wrong with Action Scheduler and that you should install it separately. Note that I do NOT use the Action Scheduler in any of my plugins. But, if something that uses Action Scheduler is causing fatal errors or timeout errors, that could possibly affect the CRON jobs since I believe it works off the same CRON hooks.

The CRON hook for my plugin is set up during activation. So, you could try to deactivate the plugin and then reactivate it, and that should check if the hook is registered, and, if not, it will set it up again. You say that you see it in the CRON hook list, but it’s worth a try to see if that helps at all. As far as database entries, things like the last reminders sent data are stored in the default wordpress options table. Just search for entries that start with ‘pta_sus_’ for the option key, and you’ll find a few. The reminders sent option is only updated when any reminders are sent, and they are only counted as being sent if the email function returns a true value. If you have replaced the WordPress mail function with a SMTP plugin, then that plugin also needs to return a true value when an email is sent, or else my plugin will think it wasn’t sent and it won’t update the sent count. I don’t think that’s your issue, though.

Doing some quick searching, I see that in the past some people have had issues with CRON jobs from various plugins not working correctly when they disable the WordPress CRON and then use a “real cron’ server setup to trigger wp-cron.php. Even though everything looks fine when you see the scheduled CRON jobs, it seems that calling wp-cron.php directly that way may not ensure that all plugins are initialized properly in time for their CRON hooks to be registered and to fire properly. I would suggest that you re-enable the WordPress CRON function and remove the server side real CRON call to wp-cron, and see if that fixes that issue. If your site gets enough traffic (even if it’s search engines or bots crawling your site), the CRON jobs will get checked every time WordPress is loaded, so there would be no need for a “real cron” job if your site is getting hits at least once every 15 minutes.

You could certainly add it as a feature request, if you want, although I haven’t been adding too many new features recently. If it’s something that many people think would be helpful, I could consider it.

If you do add it as a feature request, please add more details as to how you think it should work. For example, are you manually picking other tasks to sign them up for after they sign up for the first one? Or are you trying to link several tasks so that when they sign up for one, they automatically get signed up for the others? If it’s the later, I would suggest just combining those into one task so they only have to sign up once, and add a task description that lets them know everything that task involves, or add more details about it in the sheet description? If it’s just that you want to select other sheets/tasks to copy the signup info to, and you want to save some typing by not having to enter the info manually, and you’re not forcing them to have user accounts, then let me know how you think that should work from the user interface standpoint. For example, what happens if there are details needed for each task and those need to be different for each task? Or, what happens if you are using the custom fields extension and there are different custom fields for each task that need to be entered? In order for me to consider adding new features, it has to be useful for people using other features as well.

Sorry, but there is no automated way of doing that now. However, as an admin user, you can sign up people from the admin side. If you use the “View Signups” text link from the list table of sheets on the admin side, you can see everyone who signed up, and there will be an “Actions” column with icons for actins you can take as admin. On any blank slots there will be a “+” icon to allow you to add a signup yourself. If you force your users to have WordPress user accounts, it’s super easy because then on the admin signup page you’ll see a dropdown select list of users and you can select a user to then automatically fill all the standard info for that user. Otherwise, you would have to enter each field manually (copy and paste from another signup that you can have open in another tab to make it faster).