Matthieu-P. Schapranow

Hi Rogier,

Thanks for creating the brach so quickly. It works partially wide a minor side effect. Once you click on the save button in the backend, the shortcode will be evaluated and gots replaced by the actual content also in the form and stored as html code in the database. The do_shortcode function should only be executed for content to be displaying in the frontend

Thus, I would remove it from load function of models/Recipe.php. I discovered there is the filter zrdn_field_value called for all values loaded from the database, would be great to have approach for values to be displayed in the frontend. For example, applying a filter on the ready-to-render content after getting the content from calling Util::view(‘recipe’, $viewParams) at the end of function zrdn_format_recipe in class.ziprecipes.php.

Cheers,

Matthieu

Thanks for fast response. In the meantime, I found a solution by following your hint. After unprotecting the lyte meta data, I was able to delete the _lyte_* metadata for the specific page, published the page and voilà the uploadDate itemprop is displayed properly. Curious, because I deleted the complete cache via the button in the plugin settings, which did not make the job, hmm.

What do you think about deleting all _lyte_* metadata on all pages when deploying a new release of the plugin?

Cheers,

Matthieu

Hi all,

I encounter the same issue like @stephaniesash after the latest update. My theme uses the bx slider. The first two images are loaded, but all others are only loaded when interacting with the page, e.g. a click on the slider.

Thanks for your help!

Matthieu

Dear Waseem,

Works like intended. Thanks for the prompt action.

Cheers,

Matthieu

Hi Jordy,

first of all thank you very much for all your efforts. I encounter some issues with German umlaut in filenames.

? => Ae
? => ae
? => Oe
? => oe
ü => Ue
ü => ue
? => ss

Thanks in advance,

Matthieu

Dear @mikeypengelly,

I use also W3C and do not encounter the issue described by you. Try to check the following.

• Login to your WordPress backend and select the W3C menu “Performance” on the left
• Select “Page Cache”
• Scroll down to “Advanced” and check the option “Never cache the following pages:” — default setting are

  wp-.*\.php
  index\.php

@rainbowgeek: Thanks for the great plugin. With regards to caching in the plugin, you use set_transient and get_transient. Is there a reason, why you prefer to store the raw openweather API response instead of the processed result. Currently, caching saves the API call but still requires subsequent parsing of the result for every weather call. Wouldn’t it be great when the processing of the API response also needs to be performed once per cache interval?

Cheers,

Matthieu

Hi Rob,

excellent job! W3 Validator responds now “Document checking completed. No errors or warnings to show.”

Thank you so much for your great work!

Matthieu

I added the link to the current API doc for further investigation (see section Parameters of API respond for 5 day / 3 hour forecast): https://openweathermap.org/weather-data

Hi Ben,

I encounter a similar issue while using the five day forecast for Faro, Portugal (ID=2268339). The forecast for high and low temperatures appears to show always the same values instead of low/high temperature values. The issue appears to be a change of the API JSON response from https://openweathermap.org/.

The corresponding API call is
https://api.openweathermap.org/data/2.5/forecast?id=2268339&units=metric&APPID=<YOUROPENWEATHERMAPID>

The returned JSON consists of a list of forecast values every three hours, i.e. eight list entries per day. Each of the forecast entries contains a temp, temp_min, and a temp_max value, which are typically the same. To get the proper low / high temp values, the API requires to iterate through all 8 entries per day storing min/max values instead.

Thanks in advance,

Matthieu

Re-using the featured image of a inserted page would be great, e.g. to re-use the description of a speaker with her/his image (speakers have one page) within the details of a session (another page). Looking forward to see this feature in one of the upcoming releases.

Stephen,

thanks for pointing me to the right direction by outlining that the plugin is not enforcing access rights. I am using the plugin “user role editor” to define a specific user role that has access to private events. The issue was that the role lists the following rights:

– read ( )
– read_private_events (X)
– read_private_pages (X)

The latter two I had enabled, while read was disabled. You have to hold both access right to read your own private events: read + read_private_events

Thanks again for your quick help!

Matthieu

Dear Stephen,

Perfect, works like charm.

PS.: I do not want to hide past events as the plugin is used to organize group meetings and older events contain presented materials, e.g. slide decks or notes.

Cheers,

Matthieu

Hi Stephen,

excellent response time, thanks for immediate support.

Cheers,

Matthieu