pixelnate

The ID in the error was indeed the ID that was shown in the database, and it didn’t match up to any lists we have. I don’t know how that ID was different from the list ID that is shown in the MailChimp admin.

On a side note, no matter which list I chose in the select list in the plugin options, the list was never changed. Also, when the plugin options page loaded it didn’t show any list as being chosen, even on initial load, when there was clearly an ID set in the database.

Sure thing. There is a key/value pair in the postmeta table that specifies the list that gets used for the form. Run a query on the table to find the record where ‘meta_value’ = ‘id-number-in-the-error’. Change that id number to the id number of your list in Mailchimp and you’re good to go.

I went into the database and changed the option value for the plugin and now it is working again.

Just wanted to chime in here as one of the people that the git repo helped. Thanks.

I thought WordPress 3.6 was supposed to fix this. We got hit on a major site of ours and what I ended up doing was create a separate nav bar out of each of the main nav links. So it went from something like this:

<div class=”nav”>
<navbar 1>
link 1
-link 1.1
–link 1.1.1
–link 1.1.2
-link 1.2
link 2
-link 2.1
-link2.2
</navbar 1>
</div>

To something like this:

<div class=”nav”>
<navbar 1>
link 1
-link 1.1
–link 1.1.1
–link 1.1.2
-link 1.2
</navbar 1>

<navbar 2>
link 2
-link 2.1
-link2.2
</navbar 2>
</div>

It’s not perfect, but it was the only way to get around what we found was a limit to the number of items that would sit reliably in a navbar. I think we were hitting a limit of 35 or so items in a navbar before it would stop allowing more links.

Works fine for me. Have them clear their browser cache and their DNS cache:

Flush DNS cache in Windows

Flush DNS cache in OSX

Thanks for posting your solution to your problem. That doesn’t always happen, and it helps others that have similar issues.

I wonder, have you ever thought about SEO? Keeping the same page title in your title tag works against you with the search engines. Instead of managing your title tag in your template files I would recommend using Yoast’s SEO plugin so that you can have more control over your page titles and avoid the penalty you’ll get from the search engines.

FTP into your server and it should be in the root folder of your WordPress installation.

You might want to check your .htaccess file. Whenever I get a 500 error that’s the first place I look. Recently, there have been instances when we upload an image or change something in the page SEO area (using Yoast’s SEO plugin) and when the page is saved, the .htaccess gets nuked. Whether this is a WP issue or an issue with our hosts remains to be seen. Media Temple & Rackspace Cloud are where we have seen these kinds of issues.

Oh, that does look like a useful plugin. That’ll help me with a couple big projects I am working on. Thanks.

That link helped me a great deal, @elkay. Thanks for posting it. I am also having problems with the minified scripts in the admin of a couple of our clients’ websites. I haven’t yet reinstalled WP, but the SCRIPT_DEBUG flag did help me.

It’s a bit late, but you should add that near the bottom of your wp-config.php file just above the comment that reads:
/* That's all, stop editing! Happy blogging. */

I am now experiencing some of the ill effects of the 3.5/3.6 upgrades on some of our clients’ sites and this thread came up. I am sorry that nobody answered you during the eight months(!) that your comment has remained unanswered here.

That doesn’t fix the working feature broken by bad UX decisions by Automattic & Co. I love using WordPress, and the files are saved reliably on the server (where they are organized by folders), but the interface changes are a major step backwards for those that use the feature the most.

Telling users to use 3rd-party software because you have broken a previously working feature while completely dismissing the issue is not alright.

I have to agree with (most) of what @ursina is saying. I mean, I have never tried the Rubik’s cube thing, but there are serious usability issues with the way media is being handled in the admin. It was so much easier to manage media file imports with the old system before everything was switched to backbone.

My main gripes:

– Only 20 viewable items on a page. This really is a ridiculous limitation and if you have hundreds of images it’s a terrible pain in the arse to find the one you are looking for. There should be an option in the Settings area that would allow for more items on each page.

– There is only one way to view the files, a list with a tiny icon. If you are looking for specific images it would be much easier to find them with thumbnail views in sort of a masonry/pinterest sort of way.

– And during media uploads it is not obvious that you have completed the upload. There is not enough visual cues for the user to understand that their images have finished uploading. All they get is a slider bar that moves to 100%. There should be a flash that indicates the file is uploaded and they should be gently asked to add the meta data that they’ll need to find the image later in the huge pile of images that the Media section has become.

I’m with you, @ursinus, the Media section leaves a lot to be desired. [Unnecessary comments about a forum moderator removed]

I fixed it. I just put this function in the bottom of my functions.php file and now it always uses the secured url.

function my_force_ssl() {
    return true;
}
add_filter('force_ssl', 'my_force_ssl', 10, 3);