In the form UI, where you build the form, there are TWO form elements you can use:
1. Post Date field type is probably NOT the one you want. It looks only at when the event was saved/created as a post in WordPress (when you wrote the event).
2. Post Meta field type is probably the one that you DO need. Drag this field on to the Search Form UI. In the settings there are THREE main tabs; Number, Choice and Date. You should use Date. In the Date settings panel, in the Input type select box, you will probably want to use Date Range. Doing this gives you a Start Meta Key. You must chose the name of the Custom Field that has the start of the event data in it. The next important choice is Use same for end key checkbox. This is ON by default. You use this option ONLY if your events are always on a single date. If your events are on a series of days/dates, uncheck this option. Now you can still have the same meta key as the start date, or choose a new meta key for the end of the event. Now you must choose the Compare Mode that suits your needs.
Next, the the Date Input Format, I usually find that the best option to select is YYYYMMDD (ACF). This requires that your event plugin (or ACF if you are using that) stores the dates in these meta keys in this date format.
I hope that I have explained this better for you. If this is not enough, we might need to use a Skype voice discussion, and for this you would need to speak in English.
As to which theme? We are reluctant to recommend themes, because this choice would be influenced by what you are trying to do, and your web design and coding skills. Some themes make it very difficult to integrate third party plugins, and some also have quite poor technical support to help you with this. Themes that most closely follow the WordPress Codex for coding standards are generally easier to work with, but are often not so flexible.
You will find these on the WordPress.org theme repository (but it is not easy to see which is built better to those standards) – clearly the ones written by WordPress themselves (such as the one we used for the demo) are relatively simple to work with (but often require coding skills).
Premium themes often look a lot prettier, but in fact are often much harder to work with. Price is often a good indicator. If the theme is sold on a marketplace, the real price is not what you pay, but maybe only half that, because that is what the author will be receiving. Some themes come with ‘lifetime’ updates and maybe 6-12 month’s support. That is not a financially viable model, so the author is likely to stop updates (or never do any) fairly quickly, and often very little useful support is given.
On the other hand, there will be themes that are very easy to work with in this regard, and that do have good support. If they offer lifetime deals, such are often priced into hundreds of dollars, and an annual license as much as $100 a year. You get what you pay for.
.
