Support » Plugin: WP Custom Admin Login Page Logo » Logos stopped working

  • Very similar to “no logo visible”, yet different.

    On a multisite subdomains installation (originally 4.7.4, auto-updated to 4.7.5) this plugin was working fine. Today, setting up a new blog, I noticed that it is not working on the subdomain blogs. It still works on the root domain blog. The change may have happened when the 4.7.5 update happened, I could have missed it since I usually log in through the root domain blog.

    I updated to your latest an hour ago, no fix.
    I have tried disabling all other plugins, no fix.

    Symptom #1 – any attempt to add a picture in setup results in a “broken link” indicator.

    Symptom #2 – No new ‘wpclpl_plugin_options’ key is created in myWPprefix_#_options table in MySQL.

    Symptom #3 – the logo has reverted to the WP on all but the root domain logins.

    Symptom #4 – On a previously working (but now WP logo) blog, going to the WPCLPL Settings page gives an error
    “Warning: getimagesize(/hsphere/local/home/kagsunda/martintechs.com/sadhu./wp-content/uploads/sites/6/2017/05/cropped-MarshBayou-icon-300×300.jpg): failed to open stream: No such file or directory in /hsphere/local/home/kagsunda/martintechs.com/wordpress/wp-content/plugins/wp-custom-login-page-logo/wp-custom-login-page-logo.php on line 321”
    The listed URL above is “http://sadhu.martintechs.com/wp-content/uploads/sites/6/2017/05/cropped-MarshBayou-icon-300×300.jpg” (unchanged from before) and the MySQL ‘option_value’ is
    a:3:{s:15:”wpclpl_logo_url”;s:99:”http://sadhu.martintechs.com/wp-content/uploads/sites/6/2017/05/cropped-MarshBayou-icon-300×300.jpg”;s:22:”wpclpl_additional_text”;s:22:”The Sadhu of the Swamp”;s:17:”wpclpl_custom_css”;s:0:””;}

    https://web1201.opentransfer.com/webshell4/index.php shows the file cropped-MarshBayou-icon-300×300.jpg in folder /martintechs.com/wordpress/wp-content/uploads/sites/6/2017/05/

    Website is http://sadhu.martintechs.com
    Admin login available on request.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter kagsundaram

    (@kagsundaram)

    I got it working.

    It needed significant rework around lines ~310-330.

    I have published an excerpt, containing all my changes, ugly test-code echoes and all. Later I expect to clean it up, and add some switches, because what works for a server-aliased subdomain system will probably not work for a served subdomain system, nor for a subdirectory system.

    More in the next post. For now, here is the fix that works on the IXwebhosting Apache server.

    http://sadhu.martintechs.com/fix-the-login-logo/

    Thread Starter kagsundaram

    (@kagsundaram)

    It has been an enlightening four hours.

    As I see it, there are two problems in WPCLPL, perhaps three.

    As a preface, the “perhaps”. I don’t know whether the stored URL before today had the “wordpress” elided out back when it was working, or whether it had already been changed in error since the failure. Nor how it worked at all that way, if it was that way before.
    With that out of the way…

    Problem #1: Because this is a “Server Alias” system (the only way subdomain WP multisite will work the way IX has configured their servers) the “SERVER” ($_SERVER[‘SERVER_NAME’]) is ‘martintechs.com, although the apparent server is “sadhu.martintechs.com’. Thus when $_SERVER[‘SERVER_NAME’] is used to strip off the server from the URL, ‘sadhu.’ is left behind to cause trouble.

    Problem #2: Because the WordPress installation is in /wordpress/ but the apparent directory, the URL for login, is the root, the /wordpress/ was getting dropped out of the URL string as it was being reconstructed.

    Multisite has many variations of installation, all of which must be considered. There is first the simple subdirectories-vs-subdomains choice. I believe that if subdirectories everything is easier for us plugin developers.

    Then there is the choice between three possible configurations of home and installation directories.

    • WordPress may be installed in the root.
    • WordPress may be installed in root.com/wordpress, with login at root.com/wordpress/login.php
    • WordPress may be installed in root.com/wordpress, with login at an aliased root.com/login.php (My configuration. It is non-obvious how to install this way.)

    Then there ares the variations in how the host server configuration handles subdomains. This is NOT a choice of the WordPress administrator, usually. It is generally pre-set by the host company. Sometimes it varies at one hosting firm between dedicated-IP and shared-IP accounts, however, there is frequently no difference between these two. The configurations I have seen are:

    • Real subdomains, with an index.php in each to point to the wordpress installation in the root domain.
    • Real subdomains, with .httacces aliasing to the WordPress installation in the root domain.
    • Aliased subdomains, which don’t “actually exist”, they are merely “served by” the server of the root domain, where WordPress can intercept these requests. (This is the setup I am stuck with.)

    I suspect that there is some combination of ABSPATH, SERVER_ROOT, etc. etc. that will resolve all of these differences.
    However, this knowledge is not clearly documented in any easy to find place.
    I will keep looking.

    WordPress

    Thread Starter kagsundaram

    (@kagsundaram)

    I have listed the output of the echo statements in a comment on the fix page. http://sadhu.martintechs.com/fix-the-login-logo/

    Thread Starter kagsundaram

    (@kagsundaram)

    There may be a problem in the WordPress core concerning confusion between Home URL and Site URL for some MultiSite configurations.
    Or maybe not.

    The code below works on my installation for URLs of uploaded files edited directly into the “…insert an image url manually:” box.

    It does not work for images selected with the “Select an Image File” button.

    =========================================================================

    /*
    * function wpclpl_image_dimensions()
    *
    * @param boolean $return (default: false)
    *
    * returns or echoes image dimensions
    *****************************************
    */
    function wpclpl_image_dimensions( $return=false ){

    global $wpclpl_plugin_options;

    if( !empty( $wpclpl_plugin_options[‘wpclpl_logo_url’] ) ){

    // file location
    if( wpclpl_file_is_local() === true ){

    $wpclpl_logo_url = esc_url($wpclpl_plugin_options[‘wpclpl_logo_url’]);

    $wpclpl_logo_url = str_replace(‘www.’,”, $wpclpl_logo_url);
    $sadhu_site_url = site_url();
    $sadhu_slashed = $sadhu_site_url.’/’;
    $wpclpl_logo_url = str_replace($sadhu_slashed, ”, $wpclpl_logo_url);

    $wpclpl_logo_pathinfo = pathinfo($wpclpl_logo_url);
    $wpclpl_logo_file_path = ABSPATH.’/’.$wpclpl_logo_pathinfo[‘dirname’].’/’.$wpclpl_logo_pathinfo[‘basename’];

    $wpclpl_logo_dimensions = getimagesize($wpclpl_logo_file_path);

    $wpclpl_logo_width = $wpclpl_logo_dimensions[0];
    $wpclpl_logo_height = $wpclpl_logo_dimensions[1];

    if( !$return ){
    ?>
    <span class=”wpclpl-logo-size wpclpl-description”><?php _e(‘Original size’,’wpclpl’); ?>: <span id=”wpclpl-logo-width”><?php echo $wpclpl_logo_width; ?></span> x <span id=”wpclpl-logo-height”><?php echo $wpclpl_logo_height; ?></span>px</span>
    <?php
    } else {
    return array($wpclpl_logo_width,$wpclpl_logo_height);
    }

    } else {

    // external file: can’t read image dimensions.
    if( !$return ){
    ?>
    <span class=”wpclpl-description”><?php _e(“Note: The Plugin can not read dimensions of external files. Please add them to your stylesheet manually.”,’wpclpl’); ?></span>
    <?php
    } else {
    return ”;
    }

    }

    }

    }

    =============================================================

    I followed “https://codex.wordpress.org/Determining_Plugin_and_Content_Directories&#8221; as closely as possible.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Logos stopped working’ is closed to new replies.