Support » Plugins and Hacks » Hacks » Simple custom login plugin

Simple custom login plugin

  • Hi there,

    First of all, sorry for my bad WP plugin knowledge. I just want to create a simple custom login following this guide because I do not want to add the code whenever the theme is updated. This is the first time I try to create a WP plugin. I already created a file called plugin.php with it’s header. And I do not know what to do next.
    Could you tell me what code I have to add to plugin.php to make it work like described in the codex document?

    Many thanks,

Viewing 15 replies - 1 through 15 (of 30 total)
  • Tara


    Volunteer Moderator

    There are many plugins.

    Just check them out and see which one will work for you.


    If your ultimate goal is to change the login, finding a plugin as Tara suggests is your best bet.

    If your goal is learning to customize WordPress, studying other plugins is a good experience. Of course you will want to develop your own code. Start with Writing a Plugin. Be sure your plugin file is in either the plugins folder or its own folder under that. As soon as you have some minimal code, activate your plugin to test it. There’s usually no need to deactivate and reactivate after that. Any code you see in tutorials where it’s suggested to place it in your theme’s functions.php would invariably work just as well on your plugin page.

    What actual code you use depends on what you want to change. Any example code that adds a filter or action would be a likely candidate for your plugin.

    Thank you for the response. I already read the writing a plugin document and know how to create a plugin. But because of my poor coding skill, I do not know how to do.

    I just want to get things done like in the “custom login tutorial” but instead of adding the code to theme’s functions.php, I want to create a plugin for that.

    I want to learn myself. For start, I just want to change the WordPress logo and it’s link. Can you help me with the coding?




    Volunteer Moderator

    you mean WP logo on the login page?
    Yes? Then add this snippet to your child theme’s functions.php:

    function custom_login_logo() {
        echo '<style type="text/css">
            h1 a { background-image:url('.get_bloginfo('stylesheet_directory').'/images/login_logo.png) !important; }
    add_action('login_head', 'custom_login_logo');

    To remove title “Powered by WordPress” when the mouse hovers on, add this snippet to your child theme’s functions.php:

    function my_login_logo_url() {
        return get_bloginfo( 'url' );
    add_filter( 'login_headerurl', 'my_login_logo_url' );

    I am willing to help you, but you may not like my style of help 😉 I’m not going to just give you the answers, part of coding is working things out for yourself and figuring out what you did wrong when things do not work. Trust me, you will continually be writing code that does not work, you cannot always have someone telling you where you went wrong.

    Don’t be afraid to try things. The worst that can happen is your site displays the “White Screen of Death”. Despite the ominous name, it just means you made a mistake. Big deal 🙂 If you set WP_DEBUG to true in wp-config.php, PHP will tell you what and where your mistake was instead of a blank white screen. Important: You do need to know how to edit your plugin files locally on your computer and then upload them to your server via FTP. If you do not, learn this before proceeding.

    Do not rely on the WP resident plugin editor! First of all, you cannot access it if an innocent error crashes your site. Second, it does not keep version backups, it’s not possible to revert to older versions. Finally, there are much better syntax highlighting programmer’s editors available that you will like working with much more than the resident editor.

    Your goal of changing the logo can be achieved by simply copying the example code (the function and add_action() call) in “Change the Login Logo” into your plugin file. The example omits the initial <?php tag, but your’s should still be in effect after the plugin header comment. Be sure to follow the instructions exactly (except where to place the code), the replacement image must reside in your active theme’s /images/ folder. Also note the current logo image is a different size than that noted in the tutorial, it is now 80×80.

    Do keep in mind when using the tutorial, like many things about WP on the Internet, that certain details may be out of date. WP has an aggressive update cycle and is constantly changing. It’s unreasonable to expect all documentation (maintained by volunteers) to keep up in every single detail. I have made a note to update this page, so expect some changes in the near future.

    Of course, it makes no sense for plugin resources to reside in a theme folder. You will want to modify the logo code so your custom logo can live with the rest of your plugin. Take a look at Determining Plugin and Content Directories.

    As for changing the link target, copying the provided code into your plugin page should work without any change at all, though you will probably like to change the ‘Your Site Name and Info’ return string. This can be nearly anything you like.

    Go ahead and try these things. If things go badly, either revert to a known working version or rename your plugin folder via FTP to deactivate the plugin completely. When you restore the folder name, you will need to reactivate your plugin. If you get really stuck and cannot figure out what the problem is, post your best coding effort here and I will try to point you in the right direction.

    Good luck and have fun!

    @ Tara: yes, child theme does work. Thank you for recalling me about child theme. I haven’t thought about this solution when trying to simplize the development of my site.
    @ bcworkz thanks for your time and great support. I have read your advices. Now I would like to know how to tell wordpress to add a code itself to theme’s functions.php (or any other file) using a plugin.


    If you are making a plugin, there is no need to alter the theme’s functions.php. (That would be considered very bad practice as well) Any code you would want to enter in functions.php will be just as effective entered on your plugin’s code page.

    Thank you,

    I will still go with the plugin solution instead of editing theme’s functions.php. The reason is that I use WP Multisite and the plugin helps me to apply the modification to all themes and all child sites with just 1 click!

    I will update more about my work here.

    Many thanks,

    To change the wordpress logo, this is the code provided in the guide:

    function my_login_logo() { ?>
    <style type=”text/css”>
    body.login div#login h1 a {
    background-image: url(<?php echo get_bloginfo( ‘template_directory’ ) ?>/images/site-login-logo.png);
    padding-bottom: 30px;
    <?php }
    add_action( ‘login_enqueue_scripts’, ‘my_login_logo’ );

    This is the code suggested by Tara:

    function custom_login_logo() {
    echo ‘<style type=”text/css”>
    h1 a { background-image:url(‘.get_bloginfo(‘stylesheet_directory’).’/images/login_logo.png) !important; }
    add_action(‘login_head’, ‘custom_login_logo’);

    But I use this code, because this is what wp-admin.css in WordPress 3.8 is using:

    function my_login_logo() { ?>
    <style type=”text/css”>
    .login h1 a {
    background-image: url(url);
    background-size: 320px 121px;
    height: 121px;
    width: 320px;
    body.login {background: #ffffff;}
    <?php }

    Could you tell me what is the best practice?

    I have highlighted the main different code.

    A major point of the guide is that providing more specific selectors is what ensures your style is used instead of the default. From that standpoint, the guide’s suggested code is best.

    But such code is more susceptible to failing after an update should any of the factors in the selector chain change. From a future proof standpoint, Tara’s suggested code is best.

    But there is a problem with being too generic as well. The change could have unintended side effects to other elements that you do not wish to be affected. So actually, using the same selector as the default CSS has some validity, except then which style is applied is dependent on which order the stylesheets are loaded, which is not that easy to manage in WP.

    I doubt it would be considered best, but I usually use the same selectors as the default to ensure the style is only applied to the correct elements. I then add the !important modifier to ensure my style is the one used. Admittedly, this doesn’t always work.

    I can’t claim to be any kind of CSS expert. My understanding of the application of more explicit selectors rule did not include specifying additional outer containers as the guide indicated. I do manage to learn a few things here and there even though I’m usually the one giving out the information 🙂

    @bcworkz from your provided information, I would go with the guide’s suggested code. The simple reason is that the code does work and as you said, is the best one. If after an update it fails to work, I am sure people will update it so we don’t have to worry. From the future proof standpoint, the guide’s code is pretty OK due to this reason 🙂 .

    So what is your choice, bcworkz?

    None of the above! 🙂

    I think I would actually use the selectors #login h1 a in place of the default .login h1 a. Since a # id selector is more specific than the dot class selector, my style would be used as priority over the default style regardless of what order the styles end up on the page. It’s enough to do the job and nothing more.

    The guide’s code is also fine, it’s just my opinion that it goes a bit too far with additional specificity. Perhaps it was to make a stronger point of the more specific = more priority concept. I don’t know.

    I wouldn’t be so sure that updates that break your plugin would break so many others that the applicable code would be patched, if that is your logic. I’m not sure I really am following your logic, sorry.

    While the core developers are very cognizant of avoiding code changes that could break plugins, they will do so if there’s good reason. Plugin authors are expected to take the responsibility to confirm their code remains functional before every update and to push any required plugin updates out along with the core update.

    There’s plenty of examples of plugins that were published and then forgotten. Neglect your plugin for too long and it will be removed from the repository.

    FYI, I just noticed the guide code does not quite work for child themes. With the bloginfo data, the image must remain in the parent theme’s images folder. People using child themes would rather the image were in their child’s folder, just like you would rather the image were in your own plugin’s folder.

    I edited the guide’s code to use get_stylesheet_directory_uri() so it would work with either main themes or child themes. Of course, plugins would need an even different code, but that’s beyond the scope of the guide and something you will probably need to figure out eventually 🙂

    Hi bcworkz, I plan to use the plugin on my sites only since it’s too simple and not deserved to be submitted to the repository. In my case, I will replace <?php echo get_stylesheet_directory_uri(); ?>/images/site-login-logo.png with direct logo url (something like http://domain.com/media/logo.png ). That is more clear and simple.
    But do you think get_stylesheet_directory_uri will still work when people are trying to using CSS files instead of embedded style sheet?

    get_stylesheet_directory_uri() simply returns the URI to the active theme’s style.css folder. There’s a different function that returns the actual style.css path including the CSS file. Thus get_stylesheet_directory_uri() is a good base for any file related to the active theme.

    Embedded styles, such as what is seen in a pages’s <head> section between <style> tags are introduced with ‘wp_enqueue_styles’ action and have nothing to do with files. The style.css file is always a theme’s primary stylesheet. It’s a WP theme requirement. Many themes also include additional stylesheets. By convention, they are usually in a /css/ subfolder, but can reside anywhere really, even a different site.

    Even if your code is not destined for the repository, I believe it’s good practice to strive to write code in a professional manner even for one’s own personal project. I admit I have failed to do so on occasion and succumbed to quick and dirty coding, but it’s still something to strive for.

    So hard coding an image path for personal use is OK, but there are similar path functions for plugins to use as there are for themes. What if in the future you want to use this plugin on a different site? Going back through and finding all the hardcoded references is far less than ideal. Better to do things right the first time. We never know what the future will bring.

Viewing 15 replies - 1 through 15 (of 30 total)
  • The topic ‘Simple custom login plugin’ is closed to new replies.