Cam

@alfjmrodrigues

Watched your video and have some further info.
1. The mu-plugins folder goes into the wp-content folder (so it is right alongside the regular plugins folder). Otherwise, it looks as though you followed the other instructions of mind perfectly.

However, I don’t think this is your problem.

What I would suggest for you to do is one of two things:
1. Double check that cookies are indeed enabled in chrome: https://support.google.com/accounts/answer/61416?hl=en

2. If that doesn’t work (cookies were/are enabled), then I would suggest following the instructions on https://codex.www.ads-software.com/Changing_The_Site_URL to change your url from https://www.maiscashback.com to just https://maiscashback.com as both the home and the site url.

Let us know how it goes.
~Cam

@programmin That definitely would cause the issue, but unless you have some interesting options set in your WP settings, my installs always seem to route me to either https://www.domain.com or domain.com depending on my site’s domain setting.

Unless something has changed with how WP redirects based on your side domain setting (which is definitely possible), I can say that this was not the issue facing my site.

~Cam

@alfjmrodrigues

To use my block of code, you could do one (1) of the following:
1. Paste the above code into functions.php of your active theme. (Downside is the fix won’t follow you between theme changes.)

2. Create a mu-plugins directory. In the mu-plugins directory, create a file called “cookie-fix.php”. In the newly created blank php file, add the following code:

<?php
//fix for cookie error while login.
function set_wp_test_cookie() {
	setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
	if ( SITECOOKIEPATH != COOKIEPATH )
		setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}
add_action( 'after_setup_theme', 'set_wp_test_cookie', 101 );
?>

(Their isn’t much downside to this option except for a little more hassle factor on the front end. [i.e. setting up a mu-plugins folder, etc.]). I did this second option — except I placed the code in an already created mu-plugin file which holds all my custom code.

Note that this edit simply sets the test cookie onto every page you visit. Setting the cookie early fixes the issue of it not being set when it checks during the login process. If you have cookies actually disabled, and cannot log in at all (even from yoursite.com/login.php) after two or three attempts, then this fix may not help.

Let us know how it goes.
~Cam

Thanks for this thread. Was having intermittant issues with iOS Safari users being hit with the cookie error.

Here’s the code I used to fix it (in a mu-plugin file):

//fix for cookie error while login.
function set_wp_test_cookie() {
	setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
	if ( SITECOOKIEPATH != COOKIEPATH )
		setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);
}
add_action( 'after_setup_theme', 'set_wp_test_cookie', 101 );

Props to @mirajas for pointing me in the right direction. MU plugins by default seem to be loaded too early, so I had to wrap in a function and hook it.

This allows my users, using BuddyPress and the sidebar login form, to not have to reenter their password on the wp-login.php page with the error saying that cookies are not supported.

Thanks for this thread! Hope this additional info helps others.

~Cam

And, by the way, thanks David for a great, lightweight plugin for this functionality.

I tried the updated (v.22) version and it still seemed to have issues with the code you provided . . . however, I tried a slightly different adaptation because I realized this was written for IDs and I was using classes for my wrapper div.

When I tweaked the code to this it started working:

jQuery(document).ready(function($) {
  $( ".tabs" ).tabs();
});

Hope this helps those who still might be stuck.

I have the same problem. I rolled back to the previous version of the plugin to get my tabs working again.

The original v.1 works for me on WP 3.5

(I am currently using WP 3.5 and have a custom function building my tab contents that is included in a page template, but not available via the WP page editor.)

In my case, the problem appeared once or twice after updating my theme and it was immediately after updating the plugin, but in a couple of minutes, it was gone.

I am not a programmer, but the plugin upgrade might have needed a brief moment to update the hundreds of events that are currently in the calendar over to the new style — but since I am not much of a programmer, I don’t know if that changeover would have modified the DB or taken much time.

Thanks for the update Marcus, and for pointing us in the right direction. ??

~Cam

This is happening to me too. I am using WP 3.3.1, Buddypress 1.5.2, Events Manager 5.0.1.

However as I am looking into this issue, the problem seems to have vanished. I’m confused. Perhaps a recent update to my theme (Custom Community) fixed it for me.

Hope this information helps even if it isn’t conclusive.

This appears to be fixed with version 4.15.

Thanks for the update Marcus!
~Cam

Ok. Totally deleted both EM and EME (and even went into the database and deleted the tables from each.

Then I reinstalled EM. Created a new location, Created a recurring event, modified the event and the problem still exists. (I am now using EM ver 4.14)

I also created a test blog from scratch. Default everything. (WP 3.2.1, Multisite enabled. BP v1.2.9. EM v4.14) — on a different webhost.

Problem still exists. See the test site here.

When I originally create the recurring events (with the start date in the past and it extending in the future) the event looked great.

Then I noticed that I needed to change the description, so I hit reschedule, and when I updated the event, it never deleted the original past event when creating a new one. (One workaround is to open the rescheduling in a new tab and with that tab open, delete the event in the original list. Update the info in the reschedule tab and save).

When I switched plugins, I had to recreate all the events from scratch. Unless both plugins are using the same tables (which I don’t think they do), I don’t believe this is a bug from the transition.

You’re welcome.

What I meant to say is –Wordpress updated their jquery and made this colorbox version invalid.

??