Manuel Schmalstieg

In the wiki there are some instructions for customizing this.

Let’s say you want “month-day-year” as in 11/06/2017.

Here’s how to this can be expressed using the shortcodes of the PHP “date” function, documented at php.net

m = Numeric representation of a month, with leading zeros
d = Day of the month, 2 digits with leading zeros
Y = A full numeric representation of a year, 4 digits

So this would get the expected result:

function my_custom_filter_example( $mem_date, $mem_event_list ) {
    
    return date_i18n('m/d/Y', $mem_event_list["start-unix"]);
    
}
add_filter( 'mem_event_date_display', 'my_custom_filter_example', 10, 2 );

Caveats:
This code is only considering the start date, not the end date.

How to add this custom PHP code to your site?
Here’s a tutorial that may help.

Not sure if related:

Since the update to Polylang 2.2, I am encountering a somewhat similar issue: English and French posts are mixed.

I installed the most recent version from Github (version of Aug 28, 2017, commit c05ae17), but it did’t fix the problem.

I am using a special template with custom queries that make use of the “lang” parameter. This was working fine, and was necessary, as without the “lang” parameter the query wouldn’t get the language context.

The behavior now seems to be the opposite: when the “lang” parameter is present, whatever the value, it always returns a mixture of languages.

What works: when I remove the “lang” parameter, the query returns the expected result. It is aware of the language context and shows only the relevant posts.

Hi Adrian,

Thanks for reporting this.

Indeed, the German translation files weren’t up to date, which was causing the issue with the date formatting.

In update version 1.1.1 this is fixed. Also, I adjusted the plugin’s textdomain, so hopefully translations will soon be moved into https://translate.www.ads-software.com/projects/wp-plugins/minimalistic-event-manager

The plugin is translation ready, and translations can be added here: https://translate.www.ads-software.com/projects/wp-plugins/wp-user-groups

Hi @uebe,

When you say “disappear”, I assume you mean “disappear from the widget”?

Indeed, the widget is only testing the “_mem_start_date” field, so it ignores the ending date. This was done for simplicity. I could make it take care of end dates as well.

Here’s an explanation of the logic that the widget currently applies. Hopefully this will help us understand why your results are incomplete.

1. It checks for all posts with an event date within the last six months (an arbitrary limit I defined).
2. It builds an array for all the events, including their repeating events.
3. It filters out the old events, using the “Age of posts (in days)” defined by the user.
4. It compares the resulting number of events with the “Numbers of posts to display” defined by the user.
5. If the result is within that number, it goes ahead and generates the output.
6. If we have too many events, the plugin will trim the number of events to show, giving priority to upcoming events.

The code under (6) makes the assumption that future events are defined, it doesn’t take into consideration all edge cases. That’s probably the cause of your issue.

What setting do you use under “Age of posts” and “Numbers of posts to display”? You should be able to work around the issue by increasing those numbers.

Regards,
Manuel

Hi @irokob, thanks for the feedback.

I’m glad that you found the information that solved your issue.

That’s a great question, I’m wondering the same.

The Github repo has no updates since May 2015, and there are 28 open pull requests.

The author Artem Polikarpov has some activity on Github as recent as September 2016, though. Probably the best is to ask him directly!

Thanks for looking into this!

It was my fault, I forgot to check for the mu-plugins folder… and gotcha, there was that old custom plugin I created in 2013, based on your awesome code example – still working fine ??

Needless to say, after disabling the custom code all modules are showing up as expected.

Jetpack was network activated. To see if it makes a difference, I network-disactivated, then re-enabled Jetpack on the main site – same result, same modules missing.

I had also some plugins that customized the Jetpack experience: “Manual Control for Jetpack” and “Menu Humility”. I disabled and deleted both, but it didn’t make any difference.

Also, no trace of anything going wrong in the debug.log.

@swissspidy Thanks for looking into this!

I just tested the updated code you posted here, but still the line with load_textdomain is causing PHP errors (“Allowed memory size exhausted” or “Maximum function nesting level”, depending on the server).

As described in the other thread, I found a workaround using load_textdomain_mofile, which works great for my needs.

I found a workaround, not using override_load_textdomain, but using load_textdomain_mofile instead. The source is this code sample by @mikejolley.

Here’s a slightly modified version:

add_filter( 'load_textdomain_mofile', 'load_custom_plugin_translation_file', 10, 2 );

function load_custom_plugin_translation_file( $mofile, $domain ) {
  $my_textdomain = 'my-plugin-textdomain';
  if ( $my_textdomain === $domain ) {
    $mofile = WP_PLUGIN_DIR .'/'.$my_textdomain.'/languages/'.$my_textdomain.'-' . get_locale() . '.mo';
  }
  return $mofile;
}

You are expected to change my-plugin-textdomain to your actual text domain, and the po/mo files are expected to be inside a “languages” folder inside the plugin folder.

Still, I’m looking forward to see a solution that uses override_load_textdomain, and I’m wondering what are the differences between the two methods.

Thanks @icaleb for that link!

Indeed, the code sample under “Making your translation upgrade safe” is still a great working solution in WP 4.6.

FWIW I can’t get that code sample to work either. In my case, it causes this:

PHP Fatal error: Maximum function nesting level of ‘256’ reached, aborting!

What I’m attempting to do: allow the Formidable Pro plugin to load the complete translations bundled with the Pro version, rather than the locale for the “light” version downloaded from WP.org.

Thanks for your feedback!

You will find an example of what you want to achieve in the wiki: https://github.com/ms-studio/minimalistic-event-manager/wiki/How-to-display-the-dates

Your code is almost fine, the thing that prevents it from working is that when you define $mem_date, via the mem_date_processing() function, you get an array full of information. So even if the fields are empty, you still get an array.

So you could either test:

a) If get_post_meta returns content.
b) If a specific entry of the $mem_date array has content – for example $mem_date[“start-iso”] which holds exactly the same content as the ‘_mem_start_date’ field.

An example for (a) would be:

$mem_start_date = get_post_meta($post->ID, '_mem_start_date', true);
if ($mem_start_date !== "" ) {
  echo '<p>start date: '.$mem_start_date.'</p>';
} else {
  // nothing to show
}

An example for (b) would be:

// First, check if date fields are present.
// This will return an array with formatted dates.
$mem_date = mem_date_processing( 
    get_post_meta($post->ID, '_mem_start_date', true) , 
    get_post_meta($post->ID, '_mem_end_date', true)
);

// Second step: display the date
if ($mem_date["start-iso"] !=="") { // show the event date
    echo '<div class="event-date">';
    echo $mem_date["date"];
    echo '</div>';
} else { // no event date? - show the publication date
    ?>
    <div class="pub-date">Posted on <?php the_time('j F'); ?></div>
    <?php
}

I hope this helps ??

• This reply was modified 8 years, 6 months ago by Manuel Schmalstieg.
• This reply was modified 8 years, 6 months ago by Manuel Schmalstieg.

After looking at the Action Reference, it’s quite easy to find a working solution.

What doesn’t work:

– Using ‘acf/init’
– Using the ‘init’ action with the default priority (10).

What works:

– Using ‘init’ with a lower priority (anything higher than 10), such as: add_action('init', 'my_custom_function', 20);
– Using ‘wp_loaded’: add_action('wp_loaded', 'my_custom_function');
– Using ‘admin_init’: add_action('admin_init', 'my_custom_function');

So it appears that WP User Groups are being defined at the ‘init’ step, “typically used by plugins to initialize”.

• This reply was modified 8 years, 6 months ago by Manuel Schmalstieg.
• This reply was modified 8 years, 6 months ago by Manuel Schmalstieg.