Jerry Stephens

I’m working on enabling internationalization for the next version of WP-UserLogin. It’s not something I have much experience with, so it’s been a slow process. Most of the front end will be handled by built-in internationalization via WordPress itself, but I may need some help with the admin options page.

That’s right. If you’re running the OpenID plugin then an OpenID field will be displayed in the widget. But OpenID capability is not part of this plugin yet.

Sorry it took so long to get back to you about this. I’ve been looking for help localizing my plugins, actually. I’ve got no experience with setting up .pot files, but I’ll look into it and would definitely appreciate any help I can get in that area.

I aim to please.

The recover password link takes you to the default password recovery page for WordPress. The plugin doesn’t handle password recovery at all, aside from that link. I’m not sure what the problem could be, but it isn’t with WPUL. If you got directed to the page for password recovery, then the plugin is working fine.

Have you tried upgrading to 2.7.1 yet? This may be a WP bug, but I’m not entirely sure.

2.3.1 has just been uploaded, and it fixes the implode problem. Please update as soon as the repo catches up with WP.org.

It was a small oversight on my part. I wasn’t writing the data to the database until the settings page had been displayed. That’s corrected and everything should be working smoothly now.

Thanks for your patience, guys, you rock!

Finally figured it out. If the Login and Control Panel title fields are left blank you will get the resulting implode error. I’ll work on fixing this in later releases.

I just released an update. It’s for 2.7 only, but it does solve your problem.

If you change line 161 from this
$form = "<form name=\"loginform\" id=\"loginform\" action=\"". $wp_url ."/wp-login.php\" method=\"post\">
to this
$form = "<form name=\"loginform\" id=\"loginform\" action=\"". $wp_url ."/wp-login.php&amp;redirect_to=".urlencode('[desired page]')."\" method=\"post\">

Of course, replace [desired page] with your actual desired page. That should solve it. Thanks for this post, I’ll probably look into this as an option on the next release.

You should be able to change all of that in the style.css file of your theme. Just create specific attributes for #user_login and #user_login li. Get those set up and you should be squared away.

I can’t seem to reproduce the errors you guys have given me on my local systems (Windows, Mac, or Linux). Perhaps reinstalling the plugin might help, there’s the slim chance that you may have gotten hold of the mid-fix revision that accidentally got uploaded as 2.2 some time ago. Other than that, I’ll definitely keep looking into this issue.

I’ve been gone for a while due to a huge move. Let me take a look at the code and see what might be causing the problem. Then I’ll get back to you. Thanks for being so patient.

I’m getting the same T_DNUMBER error as terasuccubi. Upgraded from 1.5.1 and it won’t activate now as it causes a fatal error.

I’m not seeing any errors on your site. Care to explain the error to me? What version of the plugin are you using?

I know where the problem is, I think. I’ll have a new revision up by morning (currently 19:35 California Time). Thanks for keeping me on my toes. ??