Development of XenWord 3.0 began almost one year ago, and while the beta milestone has been reached, a sticking point is now the new authentication system working properly with creating and destroying sessions kept in the WordPress _usermeta table.
WordPress 4.0 introduced new security measures for login, leading to an issue with using wp_set_auth_cookie in the XenWord login files. In particular, a nonce error happened whenever an administrator attempted to activate or deactivate a plugin. To avoid the error, a cookies.php file was created which contains a replacement for wp_validate_auth_cookie.
Replacing the wp_validate_auth_cookie means caching plugins will not properly read the cookies and not function properly. This is a major draw back for many customers trying to tune their site performance.
The hardest part has been discovering the lines of code creating a problem for the new authentication system. It turns out the verify token line is the issue. Commenting it out allows a user to login, get to the WordPress dashboard, and administrators can activate and deactivate plugins.
[pastacode lang=”php” path_id=”949859df6af136b3dc809f0dd524e0a9″ file=”” highlight=”” lines=”” provider=”gist”/]It’s best to figure out how to not replace the function, and so after several more days of tweaking and pulling out hair, and after reading the WordPress code a little more, a fourth parameter was added in the wp_set_auth_cookie line. An important line of code now reads wp_set_auth_cookie( $user->ID, true, is_ssl(), true );
With these code changes the authentication system works and a session_token is created in the _usermeta table. However, this token should be destroyed after logging out and this isn’t working.
XenWord 3.0.6.01 is now installed on the server. This version has new authentication code.
Decided authentication needed my full attention. The following video shows the last sticking point, which is the login requires a refresh.
[MEDIA=youtube]zt3pfSzJ9Mo[/MEDIA]
The good news is that the WordPress cookie is being seen and caching is enabled on the development test sites.
Note for a possible Temporary fix for Login Widget:
[php]
//cheks if ? already exists in URL
if( strpos( $redirect_to, ‘?’ ) !== false ) {
$redirect_to .= “&login=”.rand( 1,999999999999 );
} else {
$redirect_to .= “?login=”.rand( 1,999999999999 );
}
[/php]
The new authentication code seems to be holding up under different cache systems. Tonight I added a new file for author descriptions in the author box. This deprecates a complex file that caused issues with get_userdata.
Here is the code:
[php]
function get_the_author_meta_filter( $field = ”, $user_id = false ) {
$author_id = get_the_author_meta( ‘id’, $user_id );
$userModel = XenForo_Model::create( ‘XenForo_Model_User’ );
$user = $userModel->getFullUserById( $author_id );
return $user[‘about’];
}
add_filter( ‘get_the_author_description’, ‘get_the_author_meta_filter’ );
[/php]
Pretty straight forward code: filter the description by returning the about information in the XenForo user table. The code has been uploaded onto this server and we’ll see how it works.
Started to organize the public CSS file. Each section is listed by most relevant to all sites; that is, most sites use the discuss link and the login widget. The least used is the WP Toolbar and Branding.
Most of the time was spent on the discuss link CSS since it and the PHP were messed up. It looks like corrections made in a previous version were lost. Oops.
I hope this improvement is useful.
[ATTACH=full]1172[/ATTACH]