saintron

Unable to share logs. The warnings are coming from the sanitize_files_array function in api.key. No other errors, warnings, etc. in the log and the slider saves fine. Happens on every save though. The main array key warnings are coming from post_excerpt and new_window. Sometimes get the warnings on inherit_image_title and inherit_image_alt.

Not sure if a check is needed in sanitize_files_array or before it is called, but only noticed this behavior in recent releases.

3.19.1

Hello. Came back to check on the status of this request/issue. Read the developer log, but not sure if it has been addressed. If so, please let me know as our community is eager to use your plugin. Thanks.

Thanks. In 4.6.19, the files changed section mentions a file called
wp-includes/class-wp-query.php yet I cannot find it in any of the 4.6 releases. Was it deleted? I do see the file in more recent releases?

Just tried the new version today and it is still doing the same thing. The title saves, but the display title over the meta slider isn’t updated without refreshing the page. WP version is 4.9.12.

Hi @kbatdorf,

We are still on an older version, but looking forward to the new version. We’ll continue testing knowing a point release is coming to fix the title issue. Any idea when it will be released?

We also noticed the following behavior though it could be our system, which by the way is multi-site:

When we hit the Meta Slider Save button, the following Notice shows up in the logs:
PHP Notice: Array to string conversion in …\wp-includes\class-wp.php on line 307

We migrated to Meta Slider from another slider plugin as it was over-complicated for our user base. Yours is simple, easy to use and the update has a more modern feel to it. We continue testing this release and let you know if we find anything else.

Thanks.

Saving the Permalinks worked on an existing site. For folks with multi-site instances, this would require saving the permalinks for each existing site. During testing we also noticed Saving the Permalinks is required for newly created sites, not just per-existing ones. Please let us know when the new version is released so we can test it. Thanks.

Greetings, has this issue been completely fixed? There are three ways to preview a popup. Via the page, post or inside the popup editor. The behavior now is the Preview Changes button doesn’t work inside the popup editor. Clicking on it generates a “Post or Page Not Found” error. The post and page previews appear to work now. As before, the fix is to comment out the code highlighted below in Filters.php.

public function editPopupPreviewLink($previewLink, $post)
{
if (get_option(‘theme_switched’) === false) {
if (!empty($post) && $post->post_type == SG_POPUP_POST_TYPE) {
return home_url().”?popup_preview_id=”.$post->ID;
}
}
return $previewLink;
}

This behavior has been observed on newly created pop ups vs. those that already existed before the update.

Thanks for the reply. We run a multisite instance of WordPress. We also use git to track plugin updates. Periodically, this files shows up as changed when we haven’t done anything to it. What other things can make this file change? Thanks.

First, let me say we love your plugins. Well written and very useful for our community that frequently schedules recurring meetings.

We are also seeing the OP’s issue with the free version of WP Events Manager and WP Full Calendar. The behavior is as follows on our localhost and server.

1) localhost (PHP version 5.3.13)
Set up a recurring event spanning a year every Tuesday starting with today’s date for a year.
Use the fullcalendar shortcode on a page.
View calendar (Months looks good and then the calendar is off beginning in November).

2) server (PHP version 5.3.3)
Set up a recurring event spanning a year every Tuesday starting with today’s date for a year.
Use the fullcalendar shortcode on a page.
View calendar (First month looks good and then the rest of the calendar dates are off OR missing in varying months).

It appears issue #2 is related to the following link
https://php.net/manual/en/datetime.modify.php

We made a change in em-wpfc.php in the way $scope_end is created using $scope_start as a guide and it appears to have fixed issue #2, but we are still getting the OP’s issue in both of our environments.

$end_DateTime = new EM_DateTime(substr($_REQUEST[‘end’],0,10));
$scope_end = $end_DateTime->getTimestamp();

Note: There may be other issues or more instances of the fix that need to be implemented to completely correct the issue, but it appears something with the date calculations might be off for those with older versions of PHP.

Update, marking this ticket as resolved. The issue was on our end, not yours. Thanks.