Forum Replies Created
-
Posts
-
If you want to view this content, you need to buy any product.
Sorry, yes, I updated that field to the 300 size after you original post, and did not see the follow up post you had where you had changed it to 500 before I released the update.
I guess that could potentially be an option, something that is recalculated and updated during the automatic clean up. Right now, the start and end dates are saved in the sheet table after dates have been set, and are mainly used to filter and sort sheets. Also, even though the start date has passed, some users still want to see the original start date. So, if I add that as a feature at some point in the future, it would need to be an option that could be turned on/off.
This can already by done, although in a bit of an indirect way. Many people are already using the item details field for things like this. When setting up tasks, check the “Details Needed?” checkbox, leave the “Details Required?” box un-checked if you don’t want to force them to enter something, and then change the “Details Text” to whatever you want, such as “Comments” in your case.
The last update also increased the size of the database table field that stores that field from the signup forms since other people have been using it to collect more than just simple item details.
I am now maintaining the code for most of my plugins on GitHub, as a means of online backup, as well as an easy way for myself to checkout to different systems and installs for testing.
If you would like to be a collaborator/contributor for code, let me know and I can add you to the project. All my projects are “private” right now, but collaborators can be added. Still also trying to figure out the Github workflow, but it integrates very well with my PhpStorm IDE.
Bumped up to Varchar(300) in version 2.0.3
Posted form fields will also have slashes stripped when redisplayed after error.Fixed in version 2.0.3
If you want to view this content, you need to buy any product.
Thanks for reporting the issues.
Regarding #1, the database tables are set up during activation, using the WordPress dbDelta command, so it will only modify the tables if it detects a change from what is in my code versus the existing table format. Not sure if it will downgrade back to a smaller varchar size or not without testing. I know that I have increased the size of some fields in the past, and it has detected that change and updated the tables accordingly, but I haven’t tried going back the other way (making fields smaller).
Those fields were never intended for storing large amounts of text when I first programmed it, since they were mostly used for school staff lunches to indicate a specific dish the volunteer was providing. I could probably bump up the size to what you have it set to in the next release without negatively affecting any current installs.
#2 is easy enough to fix with stripslashes. Thanks for the heads up on that.
My form doesn’t use trim on those POST values when displayed, but it does use the proper WordPress sanitizing function of esc_attr for POSTed input values, which does several santization functions which must also trim extra white space as well.
However, your idea of trimming before validating that’s it’s a valid email is a good one. Should probably trim all posted values before validating, just to avoid some additional frustration.
If you want to view this content, you need to buy any product.
If you want to view this content, you need to buy any product.
If you want to view this content, you need to buy any product.
Adding optional template for reminder 2 subject and reminder 2 message in version 2.0.1 (releasing soon). Leave blank to use the same subject and/or message for both reminders. Subject and message are independent, so you could change the subject for reminder 2, but leave the reminder 2 message blank to use the same message template from the first reminder.