PhiLho

Hello
I think I have another case for this case.
As described in a WP-Members blog article, I have two contact forms, one for logged in users, another for visitors.
The one for users doesn’t ask for user name and e-mail. But I still need the e-mail, at least for the Reply-To field. So I tried to make a hidden field, as explained in the Contact Form tutorials (well made):
[hidden user-email default:user_email]
Except that Reply-To is marked as error, because it wants a email* (mandatory, and specifically e-mail) field.
That could be solved by allowing a hidden attribute, like
[email* user-email hidden default:user_email]
but currently it doesn’t work, I see the field. Minor issue as it is pre-filled, but still not what I want, plus it allows for errors…
I solved it with:
[email* user-email hidden default:user_email class:hidden-field]
with the hidden-field class having display: none, but it is a rather ugly hack… (I left the useless hidden attribute, as a kind of documentation…)

This specific problem can be solved two ways:
– accept the first syntax, when the default is user_email (thus the plugin is sure the e-mail is valid);
– implement the Krzystof solution, which would make two happy persons (at least!). ??

Perhaps something along the lines of allowing any field in the Reply-To field. Displaying a warning, as it is done currently. And allowing to check a “ignore this warning” checkbox beside the textarea… (equivalent to “I know what I am doing”…)

This might need to do an e-mail check at time of sending the form, as said, with warning at the user that their e-mail is invalid.
Mmm, this is a bit convoluted, admittedly. but we don’t want support of the site to receive contact mail without proper way to contact back the user, which will complaint to have no answer! ??

OK.
Meanwhile, I took the “easy” path: I downloaded the previous versions of WP FullCalendar and EventManager, available on the respective WordPress Plugin pages (developer tab), and dropped them with FTP over the current versions.
Works as before… ??
Will upgrade when the official versions will be out.
Thanks again.

OK, I investigated before seeing this issue. Indeed, we cannot see old events (roughly one month before the current date) nor “far” future dates (one month after) with WP Event Manager plugin.

It is indeed the WP FullCalendar the culprit, because adding the shortcode for WP Event Manager, I can see the full range of dates.

The problem appeared some days ago, probably when we upgraded to WP FullCalendar 1.2, which uses “FullCalendar 2.6.1 library”.
The latter added a restrict date range feature, which I suppose is on by default…

So I suppose your plugin should added some setting to define this date range, including an “infinite” one, as before.

Somehow, I feel I repeat, more or less, what you wrote above… It is just what I found out by myself, as said.

So, I see the issue is marked as resolved, but WordPress shows no new version yet. Do we really have to install a beta version? (I haven’t seen if it is hard / problematic, yet…) Do you plan to release a new fix version soon?

I might sound critical, but I really thank you for making and maintaining this nice plugin, for free (we use it in a non-profit association to help homeless people, with very little budget — see https://entraides-citoyennes.org/events/ if you want to see it in action, with little CSS adjustments). Thanks again. You make great software.

For the record, I see in the log of v.1.2 the line:

* fixed double loading of calendars (FC library doesn’t support it anyway atm),

So it looks like the change is intentional, and comes from the JS library itself.

Don’t hesitate to copy (and modify if needed) my text directly in your documentation, it is better (simpler, faster to reach) than linking to here.
Consider this as my small contribution to the project.
Thanks again for your useful project.