4
To be on the safe side, I'd check for numerical values only, like 201308. Something like this:
{if {event_dates:start_date format="%Y%m"} == {event_dates:end_date format="%Y%m"}}
same month
{if:else}
not same month
{/if}
When debugging the advanced conditionals, try to remove them and add them one at a time to see which actual one is causing the ...
4
Try using the :first modifier to generate those headings.
3
Robson is right: Low Events doesn't support recurring events.
Low Events uses this definition to determine what an 'event' is: an event is a single entry with a single start date/time and optional end date/time. According to that definition, you're actually looking at 3 events (with the same title).
There are 2 ways to get what you're describing. The ...
2
Simply ordering by the Low Events channel field would do the trick, so try:
orderby="my_low_events_field" sort="asc"
2
It's probably caused by having PHP on Output, rather than Input, but you can avoid using PHP altogether. The way Low Events is set up, and the way Low Seg2Cat works, will allow you to set both parameters regardless of their format:
{exp:low_events:entries date="{segment_2}" category="{segment_2_category_id}"}
...
{/exp:low_events:entries}
If segment 2 ...
2
For the first URL, you won't get a valid category ID, as {last_segment_category_id} points to the last segment: the date. You'd need to get creative with simple conditionals and preload replace vars. Something like this:
{if segment_4 != ''}
{preload_replace:pre_category="{segment_3_category_id}"}
{/if}
{preload_replace:pre_category="{...
2
I took a quick look, and Channel Form's dynamic_title feature is somewhat limited. It simply takes the raw entry data and does a find/replace in the title based on that data. No processing, no support for modifiers or parameters, nor some sort of rule or API to allow for that sort of thing.
That means the Low Events vars, which all use modifiers (like {...
2
Using an early parsed var (or a Snippet for that matter) like that doesn't work. To illustrate, using the var you geva as an example, and using it like this:
{exp:low_events:entries entry_id="not {lv_exclude_id}"}
...
{/exp:low_events:entries}
...will result in this code when we come to the stage where tags are parsed:
{exp:low_events:entries entry_id=...
2
If you are developing the website in EE5 and you've very easy functionality then you should go with Calendar Tag which is built in tag of EE.
And if you are developing the website in EE2 or you have some complex functionality in EE5 with Calendar then you should go for Solspace Calendar.
Both are very useful but all things is depends on your requirement.
2
Remove the low_events:date parameter from the Results tag, as that will override any parameters given in the query.
2
Wow! This looks so complex...
Please, try using this first party add-on:
{exp:channel:entries channel="Pages" disable="member_data|pagination|categories|category_fields"}
{exp:playa:children var="page_sidebar_items" parse="inward"}
{exp:allow_eecode}
{code_snippet}
{/exp:allow_eecode}
{/exp:playa:children}
{/exp:channel:entries}
I ...
1
It looks like I need a tag loop to do this. e.g., this doesn't work:
{event:contact:first_name}
This works:
{event}{event:contact:first_name}{/event}
1
Try using the :one_day modifier.
{if '{event_date:one_day}' != 'y'} Show stuff for multiple days {/if}
1
The URL has the date in {segment_2} and you're using date="{segment_3}".
Also, if the entry/event spans multiple days, the start_date will display the event's start date, not the current date given.
Edit: Note that using date="..." is specifically designed to display events according to a date range. Using date="2016-01-13" will display all events that are ...
1
jrothafer, you're thinking of Low Events, not Low Calendar (which doesn't exist). Should be no reason to bring Low Nice Date into things.
The {if passed} conditional is not supported in the low_events:calendar tag. But you might be able to compose a conditional using the {day_url} and {current_date} variables.
1
No, the URL variables in Low Events return a format according to the ISO 8601 standard, as this is always unambiguous.
1
Low Events expects the format of the both start date and end date to be YYYY-MM-DD. They both must be submitted. Also, the end date must be equal to or greater than the start date. The native JS (and styling) automatically changes the end date when the start date is modified. If you remove the class names, this check won't fire, so you'd have to do that ...
1
I don't know if this will be helpful to anyone else, but I solved my problem. Basically, I went back to thinking of this as something best handled by relationships rather than categories. I realized that if I use Playa instead of EE's native relationships my client could just check off all of the classes that an event is related to. That makes listing ...
1
The value of the option is the {year} val, so use year instead of date_url in your conditional.
1
Check your fieldtype settings. If "Overwrite entry date" is set to Yes, you should also add show_future_entries="yes" to the Entries tag.
1
If that's a Stash build, you could simply use this method for ordering entries by month and then by year (or any variation). Used it on a recent build. Works flawlessly.
1
Try adding parse="inward" to the exp:low_events:entries tag. That should allow you to use a plugin as a parameter.
Only top voted, non community-wiki answers of a minimum length are eligible
