How to Change the Same Year Date Format for Events in Same year (v3.2)

[soukhainternational]

Hi there,
I’m posting this for my client as I’m the developer for their site ([email protected])

I need to change the same year date format for events and I’ve read the discussion in this thread:
https://tri.be/support/forums/topic/changing-date-format-in-v3/
and I’ve searched for details in the docs and elsewhere but, I couldn’t find the actual details I need.

In the tribe_events_event_schedule_details() function of public/general.php, the $settings array sets a ‘same_year_format’ variable to a hard coded value of ‘F j’ which is then assigned to $format when an event is in the current year. That’s a bad idea on many levels (both hard coding the value AND assuming that displaying the year in a same year event is unnecessary), especially for non English sites as the hard coded value uses the English formatting but, more on that below. For now, I modified the general.php file and changed that variable’s value directly but I would like to override that variable value or that array in my theme’s functions.php to be able to update TEC and TECP without loosing that change. I just have no idea what code should go in the filter to just override that variable. I have created a filter and tried a bunch of things in it but in didn’t work.

I did not find any indication in the docs of how that filter should be written to override that ‘same_year_format’ variable so, any pointers would be much appreciated.

On principle, whether the year is displayed for current year events or not should be an option in the plugin’s settings. Assuming it’s not needed or useful is wrong IMO. In terms of UX, removing context like this is never a good idea to begin with and hard coding values this directly tied to localized data is even worse IMO. So I really believe this logic should be revised.

Thank you!

Stéphane Bergeron
Webfocus Design
@pixelyzed / @webfocusdesign

[Barry]

Hi Stéphane,

I’m not sure ‘hard coded’ is an appropriate description because the settings array – which simply contains some defaults that we felt would be helpful and appropriate for the majority of our customers – is filterable and can readily be changed without hacking core plugin code.

Here is an example of basically forcing it to use the same format consistently, regardless of whether the start and end times are in the same year or not, which you could test out and adjust to better fit your own needs: http://pastebin.com/FRG558N0

On principle, whether the year is displayed for current year events or not should be an option in the plugin’s settings. Assuming it’s not needed or useful is wrong IMO.

I completely understand, but we also need to strike a balance between a complex user interface for settings (it’s not realistic and would be confusing for most of our users to have every conceivable area that can be customized presented as an option within the Events → Settings screens).

We’re open to ideas though about making changes as the plugin develops and if you wish to post an idea on our UserVoice page that will also allow others to show support for any change that you propose.

Thanks!

[soukhainternational]

Hello Barry,

Thank you very much for your prompt reply on a holiday weekend. It is much appreciated. You are right, hard coded was probably the wrong way to say it but I never found an indication of the syntax you provided to override that variable. Tried many things but not that. Thank you!

I also understand your point about too many settings in the UI. In this specific case though, it might be a good idea to add one as most users who are not coders would struggle even more than I did to change that date display. Now that I see your code I kick myself for not trying that specific syntax but a regular user will not even attempt a filter in their theme’s functions.php. Such specific localized data should get some settings based way to modify it IMO. It’s the UX guy in me talking 😉

A suggestion about your docs if you don’t mind. It might be a good idea to add examples like this in there. Reading them it was clear to me I could filter that value somehow but what I tried didn’t work. I find your docs have little in terms of usable or directly applicable details, at least in the areas I looked at.

In any case, thank you very much again for your help! Twice I called on your support in the last few weeks, twice you have impressed me!

Have a great weekend!

Stéphane

[Barry]

Thanks, Stéphane.

In this specific case though, it might be a good idea to add one as most users who are not coders would struggle even more than I did to change that date display.

That’s a fair point and I will log this for consideration – I can’t make any guarantees but we’ll certainly review this in light of your comments.

A suggestion about your docs if you don’t mind. It might be a good idea to add examples like this in there … I find your docs have little in terms of usable or directly applicable details, at least in the areas I looked at.

We agree: as it stands, it certainly has its shortcomings and do wish to keep building and improving this side of the project. Bear with us though and overtime I do hope you will see further improvements in the depth, quality and range of our documentation and also supporting resources such as our tutorials.

Thanks again and good luck with your site 🙂

[Author]

Posts