dr_blue

I have encountered the same issue and I believe this is “by design” since when a new, non-existing wordpress user logs on through SSO the plugin creates the user. Also (apparently) it checks the users groups each time and updates the WordPress role to match these.

Make sure you check “Allow SSO Bypass” on the General tab of the plugin settings. Then you can still authenticate directly against WordPress and bypass the SAML authentication by using the /wp-login.php?use_sso=false.

This is just my own two cents about why new users aren’t allowed but when a user tries to login the request is immediately sent out to your IdP for verification. You never get the WordPress login dialog since you don’t want WordPress to even have knowledge of your the password the user uses at your IdP. Perhaps you could get a pre-login screen where you could choose to authenticate through either WordPress or your IdP for SSO.

Hiya, having the same resulting E_WARNING but probably when no tweets could be loaded (API temporarily unavailable), the array $tweet_date_array will be empty and can’t be iterated with foreach, resulting in a E_WARNING.

This should fix it though:

--- twitget_orig.php    2014-01-02 08:33:54.182842200 +0100
+++ twitget_mod.php     2014-01-02 08:33:46.322842200 +0100
@@ -480,7 +480,7 @@
                                <?php
                                        }
                                ?>
-                               <?php foreach($tweet_date_array as $c => $val) { ?>
+                               <?php if (!empty($tweet_date_array)) { foreach($tweet_date_array as $c => $val) { ?>
                                var date_val_<?php echo $c; ?> = <?php echo $val; ?>;
                                <?php if($options["show_relative_time"]) { ?>
                                var date_<?php echo $c; ?> = moment.unix(date_val_<?php echo $c; ?>).fromNow();
@@ -488,7 +488,7 @@
                                var date_<?php echo $c; ?> = moment.unix(date_val_<?php echo $c; ?>).format("<?php echo $moment_js_time; ?>");
                                <?php } ?>
                                jQuery(".<?php echo $c; ?>_tweet_date").html(date_<?php echo $c; ?>);
-                               <?php } ?>
+                               <?php } } ?>
                        });
                </script>

Couldn’t find the project on github so I was unable to submit this patch as a proposed bug-fix.

Ah of course. The cloning in commit e2e50c0 works perfectly.

Thanks Stephen!

Hi Stephen,

thank you for checking in. Yes the steps are correct. I’m browsing archive-event.php when getting this error.

See this screenshot where the first top-most event says “1 november” but in the widget it’s marked 29-31 october (which is what I configured the event to be).

https://i.imgur.com/n0FS5Rn.png

I’m currently in class-eo-calendar-widget.php debugging but I can’t find any obvious errors. You have a foreach-loop in generate_output on line 220 and below where you loop over the events and set up multiday but it’s only a single call to $start = eo_get_the_start and that function doesn’t return anything by reference so I can’t really see that it would update the cache with wrong info.

Perhaps you see it more clearly :).

Also, an update of the core to 3.7 doesn’t seem to solve the problem. I have yet to verify this but there seems to be no bugs reported regarding the wp_cache_get/wp_cache_set-functions for this release.