sickhippie

I ran into this same error today, which directed me to the FAQ that doesn’t actually address the javascript error. I’ve looked into it a bit, and it seems that AAM doesn’t actually serve any JS over HTTPS, even if ADMIN_SSL is set to true in wp-config.php. Since most modern browsers simply disallow non-SSL’d JS on HTTPS pages, they fail.

The biggest frustration with this is that AAM is technically a very well executed plugin, but it seems it went too far into MVC and forgot that it’s still a WordPress plugin. This is the only plugin on my site (running 26 plugins) that doesn’t autodetect admin SSL.

For reference, here’s the wp-config.php settings to force admin:

// Force SSL on wp-admin and login sessions
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

If you’re getting a SoapClient not found error and SOAP is enabled, then your hosting company (Dreamhost is one of the worst hosts, by the way) has it disabled by default. A post a few above yours mentions this:
“Plenty of hosts don’t have this module enabled. Dreamhost is one of them.”

That said, if your host does not support SOAP by default in 2012, you need to find yourself a new host. That host is not interested in user experience, they’re interested in most money for least investment.

One more update. Even putting a list of all my fields in, there are a number of them that quite simply aren’t checked. I’ve intentionally put in broken links and some of the time it just doesn’t even see it. I won’t have time to do more with it for a month or more (large projects looming), so I ended up using a third party service to check it externally instead. I still use BLC for pages and posts, but without working properly on custom fields, I’m not sure how much longer I’m going to stick with it.

It calls ./images/icon.png, which doesn’t exist.

It also uses wp_specialchars(), which was deprecated in 2.8. It doesn’t trigger with the deprecation checker plugin, but the function’s there in deprecated.php line 2121.

You never said you checked anything. You never said “WordPress is generating thumbnails properly.” You never said “I’ve disabled all plugins and reverted to default theme, but the issue persists.” You never said “I’ve checked to make sure that ‘thumbnails’ is checked in the ACF admin for that custom field.” In fact, you (again) stated it’s not a problem with your theme or other plugins, but you apparently came to this conclusion by just deciding it. Yes, an update caused the issue. Unfortunately for you, because it is not an issue for most users, the issue is in one of your plugins, your theme, or your server setup.

First rule of WordPress debugging – turn off all plugins and revert to default theme. If you can’t even do that and come back and say you have with the results, then no one will treat this as a viable bug.

Again, this is not an issue for most of the users of the plugin. This means that no, the problem is not guaranteed to be the plugin. I understand your logic of “I updated this and now it doesn’t work, therefore it’s this.” I also understand that it does not always work like that, and proper troubleshooting is the only way to find out for sure.

So, once again, here is the ONLY WAY YOU WILL GET HELP.

Go into that specific image field’s settings (Custom Fields->Custom Fields->Your Field Group-> Your Image Field). Make sure “thumbnails” is selected on “preview size”. If that is not the issue, disable ALL plugins and revert to Twenty Eleven theme. If the issue persists, then the problem is with your server setup. If the issue does not persist, there is a conflict with either your theme or another plugin. Once you’ve distilled that down, you can report back what your system setup is (I will be happy to explain how to get the useful info) or what plugin is causing the conflict.

You can complain all you want, but until it can be reproduced on a vanilla install you’re wasting your breath. I cannot reproduce the issue – images properly load the thumbnail preview regardless of location of metabox or size of image.

So yes, you acting entitled and impatient, berating someone who’s trying to help you, refusing to do basic debugging or not reporting back clearly that you have tried it, and not gathering the information requested of you is a great reason to be a jerk. After all, you’re getting exactly what you gave, mate. Time to reconsider what you’re giving.

You do realize different plugin versions can have different requirements, right? Just like new versions of WordPress can have different system requirements.

Did you ever bother to see if WordPress was generating the thumbnail images you’re trying to see? Did you ever bother to see if that library was installed on your server? Did you check and make sure “thumbnails” was selected in the ACF admin? Did you bother to test it with a default theme and no additional plugins installed to see if it was actually a conflict with a different plugin? You sure like to rule things out based on pretty faulty assumptions, so I figured I would ask these IMPORTANT QUESTIONS THAT NEED ANSWERED IF YOU WANT HELP.

I and most users never experienced the broken admin. I did experience the massive image size and told you the fix I used. You refused to look into it, or if you did you chose to complain instead of explain. You are so quick to blame ACF instead of taking a moment to see if maybe, just maybe, one of your other plugins is actually badly coded and caused the admin conflict in the first place.

What’s annoying is users like you who don’t work with people trying to help, complain that no is helping them after they’ve bit the hand trying to feed them, and are completely unwilling to do any sort of basic troubleshooting in lieu of saying “fix it fix it fix it fix it”.

So yeah, someone did offer a solution. You rejected it without looking into it, then denied anyone offered a solution. Now you expect to hear from the dev? Why would he respond? So he can just get chewed out by you like I’ve been? Not likely, mate. In order to be helped, you have to be willing to say “I don’t know what I’m doing and will try someone else’s suggestions.”

If you go into /wp-content/uploads/year/mo/ you should be able to see if thumbnails are being generated at all. If you uploaded filename.jpg, you should see filename.jpg, filename-150×150.jpg, etc. If you don’t, then make sure the GD library for PHP is installed, otherwise WordPress will not generate the thumbnails needed to show.

Update to this – field groups are a grouping of custom fields, and it looks like it’s part of how several CPT plugins function but not normally part of WP core. If your custom field was created on its own, then it wouldn’t be part of a field group.

Looks like the latest version of Broken Link Checker now lets you specify which custom fields to search, which is helpful until you have more than a few. The site I’m working on right now has 30+ custom fields that are constantly being changed and updated, which has proven to be frustrating.

Give the ID a shot, it should work – separated by comma like this: in_category(5). It’s ‘in_category’, not ‘is_category’, so that should help too.

If you have 3 tabs – tab1, tab2, tab3 – from tab one you should be able to link with href=”#tab3″ or href=”mysite.com/pagepath/#tab3″.

Have you tried using the category ID?

Had this issue on version 1.52. I have a workaround here, perhaps you can take this and work it back into your coding style.

Extra info: I was seeing those errors when selecting a page template and no exceptions – so any time I did not use the ‘select pages’ dropdowns. I solved it by changing lines 66-68 to this:

if(!isset($visi['not'])) :
	if(isset($visi['select'])) {
		$the_visi[$visi['show']]['show'] = $visi['select'];
		$eval[$visi['show']]	= widget_logic_visual_selection_function($visi['show'],$eval,$visi['select'],false);
	} else {
		$the_visi[$visi['show']]['show'] = NULL;
		$eval[$visi['show']]	= widget_logic_visual_selection_function($visi['show'],$eval,NULL,false);
	}

It’s personal preference, of course – I prefer $post->post_type for readability, but I would also swap $GLOBALS[‘post_type’] at line 432 with $post->post_type as well. Since the global $post object is called at the beginning of the function (line 414), it just makes more sense to me to call the attribute of that object rather than pulling it from $GLOBALS. Regardless, undefined index errors aren’t major, but they do fill up the error logs a bit, which can cause actual problems to get lost in the shuffle.

I just ran into this same issue. I use ACF to create my custom fields, and fixed the issue by selecting ‘field groups’ instead of manually entering the custom fields. Switching your custom fields to field groups should fix the issue.

@jane – hey there! Good to hear some inside scoop. I agree that vertical space was (and still is) an issue, especially as many plugins create their own main menu items instead of nesting inside stock menus. IIRC, this is what led to Ozh’s plugin in the first place. If I hadn’t worked with people just like you describe, I wouldn’t believe people don’t see the connection between backend and frontend. Alas, never underestimate the power of human stupidity.

“It can’t be turned off in the dash because it is the dashboard header.” Is this change between 3.2 and 3.3? If not, why the option change in 3.3? Were people turning it off then unable to figure out how to turn it back on? Or was it the Log Out issue that Ipstenu was talking about? It seems more logical to put the Log Out in the User’s menu, but I suppose in the Howdy toolbar makes about as much sense, and is probably easier for the average user – “I click my picture to do things relating to me.”

@ipstenu – side note: the Log Out in the User menu is put there by Ozh’s plugin, probably since without the top bar logging out would be tricky, to say the least. Also, I apologize for being a jerk – frustration gets the best of me sometimes, and I tend to take it out on whoever is around instead of whoever is responsible.

I hope that Ozh is working on updates for this. I’m sure it is possible, as there’s hooks for nearly everything non-core-critical. However, were it not for this single option removal, it wouldn’t be necessary.

I do see your point on the number of users. Still, number of administrators (instead of users) would most likely be more, but that’s all moot – what matters is overall users, as WordPress is designed for users as much as administrators and developers, something I seem to have forgotten.

Mark Jaquith just sent me an email, and in it he summed up the ideology behind the new look quite well: “Don’t think of it as the admin bar becoming mandatory so much as the header being massively redesigned to be tighter and permanently accessible in the admin.”

I still don’t like the removal of the option, and a number of others don’t as well, but I do agree that it is in the best interest of the majority of users (not just administrators, but overall users), and it is up to the third-party plugin dev to modify the plugin to fit whatever core is doing – not the other way around.

Thanks to everyone for filling in the blanks and giving some insight into the logic behind the change. I take back what I said about this feeling like Drupal in here.