It’s funny how little things like this crop up. But I wanted to change the date and time of a recent post to the current date and time. To do so, I manually change the month, day, year, minute, and second by hand. I can already hear it now… “how lazy are you?” As lazy as I can program my way around! I want a Now button to the right of the date/time fields.
Now I have one.
Two of Redux’s users reported a conflict with Maintenance Mode and Redux. Upon investigation, I found the problem with Maintenance Mode to be that it breaks compatibility with the entire pluggable architecture. Maintenance Mode probably breaks a lot more plugins then people realize, it’s just that most plugins don’t report the fact. That’s a nice feature inherited from Register Plus.
The offending code follows:
if (!function_exists('wp_get_current_user')) require (ABSPATH . WPINC . '/pluggable.php');
The plugin author was kind enough to explain the purpose of this code: “For current_user_can() -> “wp_get_current_user() in wp-includes\capabilities.php on line 969″. We need to include now since it is by default included AFTER plugins are being loaded.” So there was a problem with the current_user_can code not working. I’m surprised by that because current user_can is a pretty basic function for a plugin.
The following two posts in the WordPress Support Forum actually address the very problem Maintenance Mode must have been having…
http://wordpress.org/support/topic/current_user_can-in-the-_construct
http://wordpress.org/support/topic/using-current_user_can-breaks-plugin
Looking into it further, it appears the ApplyMaintenceMode function is the real culprit it makes a call to current_user_can() and to another function which in turn is dependent on current_user_can(). Regardless, all this is done in the constructor so it’s done pretty much immediately. We can fix this by changing the line $myMaMo->ApplyMaintenanceMode(); to add_action('plugins_loaded', array($myMaMo, 'ApplyMaintenanceMode')); and commenting out the if (!function_exists('wp_get_current_user')) require (ABSPATH . WPINC . '/pluggable.php'); line.
Thank you to pixelprohet for verifying these changes work!
With the influx of interest in Register Plus Redux, I figured it’s finally time to make a real blog… Easier said then done. If my obsession with perfect isn’t obvious yet… give it time. Anyway, I’ve got a section up top for Worklog. There I’ll post notes on this that and the other things I’m working on. I’m going to add tabs for Feature Requests and Bugs too, I’m just looking for the right plugins to get the job done. I made a concious decision to run this site on WordPress MS and I often regret it. I’d love to use Redux on my own site, but I can’t! I did do that on purpose though, to get myself motivated to make it work with WPMS. I digress.
I’ve also added cuddly little hearts to each page. I’m not particularly interested in them for these kind of posts, but I won’t complain if you like them, what I am looking for is feedback on different bugs/feature requests/worklog items. I’d like to know who wants what most and prioritize a little. I’m all tangled up in cleaning up the Settings page right now, but I bet most people could care less about it. So please, if something catches your fancy let me know, like it, comment it, both, whatever makes you happy.
Honestly, working on Redux has only gotten me more excited about coding in general, and working on this site has me sorely disappointed with the other plugins out there. I can’t believe there’s not a good suggestion box out there! I think I’ll gripe about that more later. In the meantime, keep breaking, fixing, and creating.
I recently made some changes to the user notification messaging in Redux. WordPress’ default configuration sends the user a message after the register with their credentials, including a system assigned password. Register Plus followed this up with letting users assign their own password, and a choice of using the default message or a custom message, either way the message went immediately after the user registered. One user on the register plus forum mentioned the potential privacy problem with sending the user their password when it is not system assigned.
My approach to the user message is a bit more sophisticated. With the least configuration, that is, no custom message, and no email or admin verification, the user will get the default WordPress message with their system assigned password, that message can be easily modified using the custom message option. When email verification is enabled, the user is sent a simple message with the verification code and nothing else. Once they have verified their email address they would then get either the default or custom message. Finally, if admin verification is enabled, the user will get no message until the admin authorizes the user, at which point they will then get either the default or custom message. In regard to the privacy issue mentioned previously, I would suggest to that user that they create a custom message that does not include the %user_password% keyword. To make things easier, the default custom message now mirrors the default message, and I added a restore default message button.
To further complicate matters, or possibly make things simpler, glass half full or not, I removed the exclusivity between email/admin verification. If both are enabled, the user will receive a verification code, and their account will be flagged in the administration panel as pending email verification. At this point the admin may choose to approve the user before the user completed email verification, or wait for the user’s status to change to email verified. Another nicety, or complexity, is when email verification is not enabled, the user will be flagged as email not verified. The administrator may choose to approve the user, or manually send them a verification code, at which point their status would be changed to pending verification.
The code behind all this is pretty simple. Previously depending on what verification was enabled, the user’s requested username was stored as either email_verification_user_login, or admin_verification_user_login. I now store the requested username as stored_user_login, and depending on whether their is an issued email_verification_code or not we can determine whether they are pending email verification or not, also, there is an added field for email_verification_date to determine whether the user has successfully verified their email address or not, this is especially useful when both verification processes are enabled.
Another process I modified following these changes was the user purge that is run each time the admin logs in. Previously only users pending email verification were purged, I’ve changed the default behavior to purge users pending either verification with no update with the specified “grace” period. For example, if the grace period were 7 days and both verification processes were enabled. If it took six days for the user to register their email address, they reset the clock so to speak, if seven days later the admin still had not approved them, then they would be purged. I added an option to modify this behavior, you can choose to only purge users pending email verification outside the grace period. I added another option to send the user a notification that their account was purged via automatic process, with a sub option to notify only users pending email verification either or admin verification. Again more complexity, but more granularity.
All the changes I have been making have me considered giving Redux it’s own category on the admin menu with pages for different features. I don’t want the settings page to be a mile long, but I don’t want the menu to be either. Any feedback would be appreciated, I could go nuts and make that a setting too! Oi, settings upon settings upon settings. I hope this clarifies things for anyone interested, I wish I knew how to express this even simpler, maybe I should start making some flowcharts!
Questions, comments, and concerns are always welcome, thank you for reading and for using Register Plus Redux!
PS, many of these administration options will not be available until 3.6.12.
I’ve learned more forking the code of Register Plus then I probably would have learned had I written my own plugin from scratch. Every time I look into the code I have to ask myself, why is this written this way, am I really improving this, am I breaking compatibility? These are really interesting questions that, as a lone wolf programmer, I’ve never had to ask myself before. Also, contributing to the open source ecosystem is really exciting, albeit, nerve wracking. Who’s to say my code won’t just be stolen, packed with WordPress and sold as some CMS? I guess that’s giving myself a lot of credit, but I really think Register Plus was the best registration plugin, and, I hope, I’ve only improved it. I’m excited for user feedback and to add more functionality and improve this little plugin.
I attempted to change the user_login of a user using the standard wp_update_user function. The following code is simplified for clarity.
wp_update_user(array('ID' => $user_id, 'user_login' => $new_user_login));
I was frustrated time and time again to find that my user_login was not changing. I opened the database using phpMyAdmin to see if something else was being changed… nope.
So it was time to dig into the WordPress code and see what was going on. A quick google search reveals that wp_update_user is defined in wp-includes/registration.php, from there it turns out that wp_update_user does a little magic, but relies on wp_insert_user to actually update the database, so let’s see how that works as well. This function is definitely more complex, but finally identifies my problem. When wp_insert_user is called to update a user, as opposed to create a user, the user_login field is never updated.
The only way to update the user_login is to manually run an SQL statement.
$wpdb->query("UPDATE $wpdb->users SET user_login = '$new_user_login' WHERE ID = '$user_id'");
UPDATE 10/13/2010: I also found it necessary to disable WordPress’ autosave feature. Here’s how… Adjust WordPress Autosave or Disable It Completely
Getting WordPress 3.0.1 working on GoDaddy’s Economy Hosting which came free with my domain purchase proved to be a little tricky. GoDaddy appends the following code to the end of each page.
</iframe></noscript></object></layer></span></div></table></body></html><!-- adsok -->
<script language='javascript' src='https://a12.alphagodaddy.com/hosting_ads/gd01.js'></script>
This code closes almost any tag, then adds it’s own script to create those GoDaddy ads that keep this service free. While we’re stopped at the technicalities, I’d like to mention, I’m not against GoDaddy’s advertising, this is a free service after all, however, GoDaddy’s method renders WordPress useless, and that trumps my moral obligation.
To circumvent GoDaddy’s code, I edited every file in my WordPress install that had the </html> tag and added the following code <script language="disable">. This opens up a script element, which is the one thing GoDaddy does not attempt to close. Everything following this element will effectively be ignored.
This worked well enough, until I realized I had another problem, GoDaddy is also appending it’s code to java scripts and style sheets.
Normally WordPress outputs a script element with the source set to the script. Stefano Torricelli (stefano.torricelli on WordPress forums) rewrote the code that loads scripts to read the script, remove the GoDaddy appended code, then output the code to the page, as opposed to linking it. The following changes must be made to the scrip-loader.php files located in your wp-includes directory.
The original code for linking a java script located in the _print_scripts function:
echo "<script type='text/javascript' src='" . esc_attr($src) . "'></script>\n";
The modified code for reading and writing a java script:
$script_data = file_get_contents($src);
$script_data = substr($script_data, 0, strpos($script_data, '</iframe></noscript>'));
echo "<script type='text/javascript'>\n";
echo $script_data;
echo "</script><!-- /wp-includes/script-loader.php -->\n";
The original code for linking a style sheet located in the print_admin_styles function:
echo "<link rel='stylesheet' href='" . esc_attr($href) . "' type='text/css' media='all' />\n";
The modified code for reading and writing a style sheet:
$stylesheet_data = file_get_contents($href);
$stylesheet_data = substr($stylesheet_data, 0, strpos($stylesheet_data, '</iframe></noscript>'));
echo "<style type='text/css' media='all'>\n";
echo $stylesheet_data;
echo $stylesheet_data."\n#conash3D0 { display:none; }\n";
echo "</style><!-- /wp-includes/script-loader.php -->\n";
The following thread was especially useful in crafting my solution, although it is in regard to WordPress 2.9.2.
WordPress › Support » Godaddy free hosting – Dashboard / Admin broken
Bad Behavior has blocked 1525 access attempts in the last 7 days.
