davidbourguignon

Thanks caimin_nwl for the feedback.

Unfortunately, I use no custom RSS template, and no RSS plugin. (Regarding plugins, could Jetpack, the official Automattic plugin, considered as an RSS plugin? I don’t think so.)

Here are two very interesting additional observations that points to a feed format issue, in my humble opinion… A recent event scheduled on the previously mentioned website on November 3rd at 17:30CET is displayed as:

• 16:30CET on Apple Calendar 8.0 (2026)
• 17:30CET on Thunderbird 31.2.0 with Lightning 3.3.1 (under MS Win 8.0)

Therefore, the bug is RSS-reader implementation-dependent, and there is a high probability this is caused by some format issue. What do you think?

Hi caimin_nwl,

Thanks a lot for your feedback. First check: my Timezone settings are correct (UTC+1) and WordPress backend displays the correct time.

My web server is located in the UTC+1 zone (I looked at raw logs) and switched to French Winter Time last Sunday at 03:00, as expected.

IMHO, the problem runs deeper: when we are under Summer Time, all future (under Winter Time) events are displayed as 1h too early, and after we switch to Winter Time, all past (under Summer Time) events are displayed as 1h too late!

Caveat: what’s really puzzling is that this bug occurs only in RSS and iCal feeds! The web pages display the correct times. My guess: there is some encoding trick in the RSS/iCal formats that the plugin is not taking correctly into account.

You can easily check this on my RSS feed, as explained in my previous post. And apparently, I am not the only one to experience this.

Thanks in advance for your help!

Best regards,

David.

Thanks a lot Alexander for the detailed feedback! We will definitely adopt your first suggestion and install the full version of your theme.

My teammate and I are great fans of your web designs. If we can contribute to improvements over GitHub in the coming months, we will let you know.

All the best!

Hi Gilles, Hi caimin_nwl,

I am currently experiencing the same issue, I think. We are based in France, currently living under Summer Time (UTC+2), and the Winter Time (UTC+1) will arrive on Sunday 26 October at 03:00.

Events Manager v5.5.3.1 is correctly configured (France is the default country for events) and all event locations are correctly configured (located in FR).

Here is the issue:

• An event created in September and scheduled for Thursday 2 October at 18:30 is currently showing its correct time (18:30), both on the website and in RSS and iCal feeds.
• An event created in October and scheduled for Monday 3 November at 17:30 is currently showing a correct time (17:30) on the website but a wrong time (16:30 as if UTC+1) in RSS and iCal feeds.

See the RSS feed on https://repaircafemarseille.fr/ateliers/feed/ for a demonstration. It is as if the Events Manager was considering that the time settings should be made under the current Summer/Winter Time reference, and not as an absolute value. Very strange.

Does anyone also experience this? Thanks in advance for your insights!

Best regards,

David.

Thanks a lot Alexander for the feedback! As far as I understand:

• The theme on WP.org was modified because some post formats are not standard-compliant, ie., data could be lost when switching to another theme.
• Your own version of the theme (2.1.9), aside of the version of the WP.org branch (1.4.5), is fully functional but not standard-compliant, and will not be updated soon.

A few questions popping in my head:

• Does this mean that the current situation (non standard-compliance of some formats) will become permanent?
• How much work could be required to make the theme standard-compliant, using for example Justin’s framework? (Nota bene: I am a PHP newbie.)
• What is your advice to Hueman users? Should we be faking the video and audio formats (the most useful of the non-compliant bunch IMHO) with an image theme, and embed the audio/video material using an existing WP plugin or HTML integration code directly in the page?

Thanks in advance for your help!

Thanks rdellconsulting for the feedback!

My second screenshot was made using Google Chrome with an approximate equivalent of a smartphone screen size… However, before writing my post, I also tried on an iPhone 5, and the bug was showing up there too.

Regarding the size of my “feature images”, they are exactly 270×250 pixels, as required. This is puzzling.

It “works”, in fact, since the buttons are functional, but as you can notice on the second screenshot, the nice CSS effect (an animation of a second circle growing around the first) does not work! It seems to be partially hidden, somehow.

What do you think? Thanks in advance.

Hi swap002, just a few lines to let you know that you are not the only one bumping into this issue!

It is unfortunate that the Co-Authors Plus plugin, which is apparently an official WordPress.com plugin, is not supported by Hueman by default.

Could you post code snippets of your integration work so far? This would help immensely. Thanks in advance!

Dear Alexander, you mentioned on your website that the version of Hueman available on www.remarpro.com “does not include sharing buttons, tracking code field, basic shortcodes and some other things as it is seen as plugin territory.”

But relying on this “lite” version is still very convenient for many people because it allows for auto-updates, etc. What about including your extra (very cool) features in a plugin?

If you think this is not a good idea, what would you recommend for the switch to your version, when we are currently using one from www.remarpro.com? Simply removing everything from the Hueman theme directory and unpacking your latest ZIP into it? Could this cause issues when it will conflict with www.remarpro.com auto-updates?

Thanks in advance for your help!