Rouven Hurling

Hi,

here is a patch which fixes the issue described above: https://www.dropbox.com/s/3jxv244ijipcols/ig-pagebuilder_row-bg-color.diff

It would be great if you incorporated the patch into the next update, i’ll apply it manually for now.

Yeah, i know that it’s being merged… just didn’t think about testing it on trunk.
If the changes get merged into wp-admin/themes.php and not into wp-admin/network/themes.php i’m sure it’ll work (since it wouldn’t need to hook into load-themes.php, which fires on both)

Will test it tomorrow though, just hope that i don’t forget it

i found a fix for this problem here: https://gist.github.com/ethitter/4430520

i just used an or, so it should be backward compatible, replace gist-fix line 19 with this:
if ( (isset( $_POST['customize'] ) && isset( $_POST['theme'] ) && $_POST['customize'] == 'on') || ( is_a( $wp_customize, 'WP_Customize_Manager' ) ) )

okay, did that and uploaded my patch
I’m pretty sure it doesn’t go with the WordPress Coding Standards and I’m using the php Session, but that was mostly was just a quick’n’dirty solution which I wrote months ago.

@iandunn: I would love to help with that (if i can).
maybe that would be a start for me to contribute to WordPress (which i wanted to do for quite some time, but didn’t really know where to start^^)

well, google authenticator and autologin would never work, since you can’t store dynamically generated codes in your password manager (or can yours do that?).
and if you have an extension for your browser it could happen that it breaks the AJAX solution, because it loads before the javascript for the ajax would load.
then the 2nd page would be the only option

okay,
i guess it wouldn’t mess with the loginflow in the way it happens now, which would be more future-proof, but i wouldn’t really like it.

furthermore:
any plans of implementing something like a force mechanism (for example for different user levels or based on capabilities; example: users who have edit_them_options need to have google authenticator enabled)

i just fixed the bug that showed an empty error field, so here it is:

google-authenticator.zip

okay,
i don’t really know if it’s the best solution, but it works and i wouldn’t know any other way to achieve this

google-authenticator.zip

i didn’t test if it passes through users who don’t have google authenticator enabled, but in theory that’s what should happen^^

it would be awesome if Hendrik could merge it into the plugin,
until then you could use the version above

okay, here are some actions and filters that should really help implementing something like this

filter login_redirect
check if global $user is valid and if he has activated google authenticator return url to wp-login.php?action=go (whicht triggers login_form_go action; also log the user back out and save info for later)

action login_form_go
verify post if exists and redirect or echo form (see wp-login.php for code example) and exit at the end to prevent duplicate due to switch statement after do_action in wp-login.php

and this is what i got so far

function loginredirect($url) {
    global $user;
    if ( !is_wp_error($user) && isset($_POST['log'], $_POST['pwd']) && trim(get_user_option( 'googleauthenticator_enabled', $user->ID ) ) == 'enabled' ) {
        wp_logout();
        session_start();
        $_SESSION['cred'] = array(
            'log' => $_POST['log'],
            'pwd' => $_POST['pwd'],
            'rememberme' => $_POST['rememberme']
        );
        wp_safe_redirect( wp_login_url() . '?action=go' );
        exit();
    }
    return $url;
}

function loginform_go() {
    session_start();
    var_dump($_SESSION['cred']);
    exit();
}

and this in init

add_filter('login_redirect', array( $this, 'loginredirect' ) );
    add_action('login_form_go', array( $this, 'loginform_go' ) );

    #add_action( 'login_form', array( $this, 'loginform' ) );
    #add_action( 'login_footer', array( $this, 'loginfooter' ) );
    #add_filter( 'authenticate', array( $this, 'check_otp' ), 50, 3 );

it disables google authenticator for now, but now almost the only thing left is copying the ‘login’ case statement and changing the fields (either write the credentials to hidden fields or leave them in session and pass to wp_signon

what about something like this:

in check_otp see if user has google authenticator activated
if so check if user POSTed token and verify if he did
and log in with the username from session and unset the saved username from session
else remove the default wordpress login action,
replace the login fields with token field
and store username (or whatever is needed to log the user in later) in a session

i’ll try to get together an at least halfway working example as soon as possible