Will Norris

well, sounds like you don’t have an XML parser ?? Check with your hosting provider about enabling the appropriate parser for whatever version of PHP you’re running. For PHP5, you want https://www.php.net/dom, for PHP4 it’s https://www.php.net/domxml Most hosts I’ve seen compile PHP with the appropriate module, they just may be commented out in your php.ini config file.

voyagerfan: yes, as of the last release, the ‘authenticate with OpenID’ checkbox is only displayed when the URL is determined to be a valid OpenID. The plugin includes the little 16px OpenID logo, so you could tweak your themes stylesheet if you want the logo to be displayed by the website field in your comment form or wherever you want.

well, it looks like the plugin is installed properly and working for the most part… Try logging in at https://testid.org/examples/consumer/ using the OpenID https://www.freshstitches.com/wordpress/?author=1

If that works, then it’s just a problem of getting the Blog Owner stuff working. First, make sure you’re account is set as the blog owner. Then go to your “Reading Settings” admin page and look at the first option “Front page displays”. If you have “Your latest posts” selected, then switch that to “A static page”, and select a page for each of “Front page” and “Posts page”. It really doesn’t matter which ones you select. Click “Save Changes”, then change it back to “Your latest posts” and click “Save Changes” again. If you already had it set to “A static page”, then you don’t actually need to do anything here… that’s not the problem.

If none of that works, let me know and we’ll try diagnosing it from there. Also, you’ll want to install the xrds-simple plugin if you haven’t already to fully take advantage of the OpenID provider.

I’m not sure that it would make sense to have the default implementations bail out if they are passed a WP_Error. Sometimes you might want authentication to fail over to a secondary method, sometimes not. Perhaps the best thing to do in your case is to actually remove the default password implementation from the authenticate hook:

remove_action(‘authenticate’, ‘wp_authenticate_username_password’, 20);

You’d want to do that in addition to returning a WP_Error.

err.. scratch that, I don’t think they will bail if a WP_Error is returned. hmph.

if ldap auth fails, then return a WP_Error instead of just null. The built-in ‘authenticate’ implementations will not try to authenticate the user against the wordpress user database, though there is nothing stopping some other plugin from doing something.

What is the URL that is causing the 404?

It’s possible that your permalinks didn’t get updated… try going to the permalinks settings page, and click “Save Changes”. You don’t actually need to change anything, just resave.

The best I can tell you is that WPMU compatibility is near the top of my to-do list on the plugin. Previously, this plugin was part of my day job. However, I’ve changed jobs recently, and this has been pushed back to “side project” status. The list of things to fix and add to the plugin has been growing in recent weeks, so I’m looking for some time in the next couple of weeks to hack it all out.

are you actually having this problem yourself?

If you take a look at openid.php, you’ll see that one of the first things the plugin does is to update the PHP include path. So no, this shouldn’t ever actually be a problem. If you are running into problems, then there’s certainly a problem somewhere, and I’d love to hear more about your environment.

I have a lot of reservations regarding the DR* themes, partially for reasons mentioned by others either here or on the PollDaddy poll. Having the sub-menus fly out to right, rather than open up downward both covers up part of the screen (maybe not a huge deal), but also breaks the ability to leave a commonly used menu left open all the time. That alone should be a deal breaker.

Something I’ve not heard others talk about is the placement and style of the “Help”, “Screen Options”, Quick Links, etc. IK seems to be the only design that gets the place completely wrong, having the Quick Links below Help and Screen Options. Quick Links are global, so should absolutely be in the top menu. Screen Options and Help however are specific to the page you’re looking at, so should visually be within the context of the current page.

One of my other concerns with the DR* themes is the fact that Help and Screen Options had been changed from tabs to buttons. Tabs actually work out nicely in the current UI, because they slide down to reveal the additional content. What would the buttons actually do? How would you display the Screen Options? You certainly wouldn’t want to slide in like the current UI, they would be very inconsistent with a button. You could do a lightbox, but why take over the entire screen for things that should rightly be in a sidebar. Tabs definitely make sense.

Given the extraordinary time and effort Jane and the Automattic crew put in to developing Crazy Horse, it would be shame to make a drastic change to the UI without a similar level of scrutiny and attention. If the desire is to ship a UI change with 2.8 (given how little time is left), then it needs to make the least amount of changes possible to achieve the goal (which is to get more of the primary menu above the fold). Almost all of the proposed designed (especially those that are getting high votes) change far more than should really be necessary.

I’ve released version 1.2 of the plugin which includes this bug fix as well as another one relating to local logins. I just noticed that if you have the plugin installed in the mu-plugins directory, you don’t see the notification that there is an update. Guess that’s something that should be patched in wpmu.

okay, it’s been fixed in trunk. I think I may have a few other outstanding bugs I need to fix and then I’ll cut a new release. Because this is using client side javascript to disable and enable the input fields, there is a chance that some browsers may have problems, depending on how it handles disabled input fields. I’ve tested it on Safari and Firefox and they work fine. Don’t have easy access to IE to test it though.

sorry I missed this… apparently I forgot to add the shibboleth support feed to my RSS reader. Yeah, this makes sense why it’s failing… definitely a bug. I’ll see about fixing that up. I’ll reply again once I do.

are you sure the openid plugin is actually causing this? Does it happen when the OpenID plugin is the only one you have active? We had memory problems with the plugin before version 3.0 (released October 2008), but nothing really since then.

Could you explain what you mean by “we can’t really trust those who log in with OPENID” ? I agree that there isn’t a widely used trust layer on top of OpenID right now, but how is that any different than normal WordPress account registration which requires only a username and email address? What does it mean to “trust” that account?

As for “Openid is really a superweak authentication method”, you must be confused with how OpenID works. OpenID in and of itself says nothing about how the user is actually authenticated at the OpenID provider. The fact of the matter is, however, that many OpenID providers provide much stronger authentication than a standard WordPress username/password account. Go take a look at MyVidoop, MyOpenID, and Verisign PIP.

I’ll consider adding more options for enabling portions of the OpenID plugin, while leaving others disabled. In the meantime, you can certainly disable portions yourself, as you’ve already done.