WordPress.org

Ready to get started?Download WordPress

Forums

WordPress HTTPS (SSL)
[resolved] Cannot Log into Wp-Admin (18 posts)

  1. robertbeth
    Member
    Posted 2 years ago #

    Hi,

    I installed this plug in and now I cannot log in to my wordpress CP. Whenever I try to load my wp-login page,I received a page time out message.

    We have no way of getting into the admin CP at this point as we are continually redirected. Does anyone know how to fix this?

    Thanks in advance

    http://wordpress.org/extend/plugins/wordpress-https/

  2. esmi
    Theme Diva & Forum Moderator
    Posted 2 years ago #

    FTP into your site (or use whatever file management application your host provides) and delete the wp-content/plugins/wordpress-https folder.

  3. robertbeth
    Member
    Posted 2 years ago #

    Esmi,

    Cheers for your help; it worked perfectly.

    All the best.

  4. Mvied
    Member
    Plugin Author

    Posted 2 years ago #

    I'm working on a bug fix version to fix this issue. I'll post in this topic when I push it out.

    @esmi Yes, thanks! :)

  5. esmi
    Theme Diva & Forum Moderator
    Posted 2 years ago #

    Glad I could help :-)

  6. robertbeth
    Member
    Posted 2 years ago #

    Thanks Mvied, we'll keep an eye on this topic.

  7. Mvied
    Member
    Plugin Author

    Posted 2 years ago #

    Hey robertbeth,

    Alright, I'll see what I can do about getting a pre-release version up if you'd like to help test. Having trouble reproducing it. It would speed up the process of a fix. I'm kind of shooting in the dark looking for bugs that could be causing the redirect loops. :P

    Thanks,
    Mike

  8. penz
    Member
    Posted 2 years ago #

    I can also help test, I'm getting this issue too.

    Does this help? This is an nginx error I'm getting.

    2011/11/04 18:22:45 [notice] 792#0: *15 "(comment_author_.*|wordpress_logged_in.*|wp-postpass_.*)" does not match "PHPSESSID=kvenjuca3d27rag50aog1eg717; wordpress_test_cookie=WP+Cookie+check; wp-settings-1=m1%3Do%26align%3Dcenter%26imgsize%3Dlarge%26m5%3Do%26m2%3Do%26m9%3Do%26m4%3Do%26m11%3Dc%26m8%3Do%26m12%3Do%26editor%3Dtinymce%26uploader%3D1; wp-settings-time-1=1320266243; kvcd=1320425075982; km_ai=PJWgA%2FCmS3CNz6QISaL8lf7wrEk%3D; km_uq=; km_lv=x", client: 4.59.22.2, server: mydomain.com, request: "GET /wp-login.php HTTP/1.1", host: "www.mydomain.com"

  9. metakong
    Member
    Posted 2 years ago #

    FTP into your site (or use whatever file management application your host provides) and delete the wp-content/plugins/wordpress-https folder.

    Not exactly. Can't access anything. Even after delete.

  10. metakong
    Member
    Posted 2 years ago #

    This is infuriating.
    I haven't looked yet. But, I have a funny feeling I won't find the answer I'm looking for pre-loaded in an FAQ anywhere.

    Dear Plugin Authors,

    What wordpress files does your plugin alter so I can manually change them all back to defaults prior to installing your plugin and subsequently regain access to my f'n admin panel.

    The GUI will throw errors while actually writing the changes it states it refused to write, very nice. Those changes obv stay in place after your plugin is deactivated (it took me 30 seconds to realize this thing was unneeded and not nearly as valuable as 50 -5star ratings seems to imply) and deleted, but the changes it made it those 30 seconds now have all my admin pages redirecting to a non existent port on my domains server.

    Whoever can tell me exactly what files/functions/methods/hooks I need to remove to get back to where I was 5 minutes ago would be my hero. Until then I can't do sht on my site until I figure it out and I don't feel like digging through every f'n php file in my server to figure out what havoc this little doosie has managed to wreak in under 5 minutes.

  11. metakong
    Member
    Posted 2 years ago #

    Follow up:

    As expected: lack of documentation.

  12. metakong
    Member
    Posted 2 years ago #

    Answer:

    Log into your database GUI or via ssh

    out of wp_options in your wp database, navigate to your newest entries and delete anything that starts with wordpress-https AND the entry titled rewrite_rules.

  13. metakong - Your posts were caught as spam, so sorry about that, but that's why no one followed up with you.

    What wordpress files does your plugin alter so I can manually change them all back to defaults prior to installing your plugin and subsequently regain access to my f'n admin panel.

    None. No plugin alters any core files in WP.

    If you deleted the plugins folder from wp-content then you have removed the plugin. Once you try to go back to your admin dashboard, there uninstall is complete and there's nothing left of the plugin. If you have CACHING plugins, however, this can cause conflicts.

  14. Mvied
    Member
    Plugin Author

    Posted 2 years ago #

    Hey metakong,

    If you deleted the plugin, the only thing that could cause issues is another plugin caching like Ipstenu said, or your browser could be caching the redirects that the plugin was throwing so it kept throwing a redirect even after the plugin was disabled. I've experienced that in Chrome mostly.

    Also, the absolute only thing that could be left by the plugin is the options that begin with "wordpress-https". The "rewrite_rules" entries would be from another plugin.

    If you set your SSL Host to something valid (i.e. the host actually exists), it'll save it. If you also enabled Force Admin SSL, it'll always try to redirect to that SSL Host since that's what the option does. So if I get curious and I enter "google.com" into my SSL Host and I have Force SSL Admin enabled, I'll be redirected to "https://www.google.com/wp-admin/wp-login.php" or something ridiculous. In that case you generally have to delete the option from the database. It's certainly possible that the SSL Host was set to something invalid during the upgrade from 1.9.2 to 2.0. If so, if you could give me some specific details about what the host was set to before you upgraded, what you set it to, etc. that would be great. That way maybe I can figure out where the problem is.

    I am working on a fix to try to make it so that the options can not be set up in such a way that will cause this problem.

    Thanks,
    Mike

  15. metakong
    Member
    Posted 2 years ago #

    Thanks, Ipstenu and Mvied, for the replies guys.

    My caching plugins/options have not been set yet. I'm no tech expert, but I'm no dummy either, caching won't be set until I'm 100% production ready for launch.

    Good to know re: generally accepted plugin behavior. At the moment, it was all I could think of for the continued rewrite.

    RE: rewrite_rules db entry, I would assume that was WP doin' the rewrite biz upon install or plugin option saving.

    RE: Feedback for Mike's valiant improvement and follow through - My bonehead mistake was forgetting that 443 is the default SSL port and setting the incorrect port.

    Makes me feel like a douchenozzle admitting it publicly, but it will force me to give your plugin another shot now that I know.

    Maybe a simple note on the options page re: port selection would be good for people like me with more bullocks than brains would be good, something like "The default ssl port for most hosts is 443." Or, perhaps a friendly reminder to check with your host for their default SSL port.

    The two above would be the immediate simple solutions prior to implementing some idiot proof system that stops "go-getters" like me from setting options to quickly without thinking.

    Thanks again for the follow up guys.

  16. metakong
    Member
    Posted 2 years ago #

    Mvied, I'll kick ya' a donation once revenue is rolling in to say thanks for being an upstanding kat. I would still, ideally, like to see a little more documentation. But, from what I can tell, you do quality work. Thank you much for that.

  17. Mvied
    Member
    Plugin Author

    Posted 2 years ago #

    Hey metakong,

    It's funny you mentioned those ports. I made changes last night to specifically ignore those ports because I tried the same thing, haha. I think that'll fix a lot of peoples' issues. I'll try to get a release candidate for the next update out and we'll see if it works.

    Thanks,
    Mike

  18. J.Smith
    Member
    Posted 2 years ago #

    Hello,

    I just wasted quite a few hours of my life by trying to make wordpress-https work for shared SSL scenario.

    As metakong's mentioned, the key word is: the lack of documentation.

    Removing the plugin from the file system doesn't clean up WordPress installation:

    mysql> select * from wp_options where option_name like 'wordpress-https%';
    +-----------+---------+----------------------------------------+--------------+----------+
    | option_id | blog_id | option_name                            | option_value | autoload |
    +-----------+---------+----------------------------------------+--------------+----------+
    |       599 |       0 | wordpress-https_exclusive_https        | 0            | yes      |
    |       594 |       0 | wordpress-https_external_urls          |              | yes      |
    |       600 |       0 | wordpress-https_frontpage              | 0            | yes      |
    |       601 |       0 | wordpress-https_ssl_admin              | 0            | yes      |
    |       596 |       0 | wordpress-https_ssl_host               |              | yes      |
    |       598 |       0 | wordpress-https_ssl_host_subdomain     | 1            | yes      |
    |       597 |       0 | wordpress-https_ssl_port               | 443          | yes      |
    |       595 |       0 | wordpress-https_unsecure_external_urls |              | yes      |
    |       602 |       0 | wordpress-https_version                | 2.0.4        | yes      |
    +-----------+---------+----------------------------------------+--------------+----------+
    9 rows in set (0.00 sec)

    vs.

    $ grep delete_option plugins/wordpress-https/uninstall.php
    delete_option('wordpress-https_external_urls');
    delete_option('wordpress-https_unsecure_external_urls');
    delete_option('wordpress-https_ssl_host');
    delete_option('wordpress-https_ssl_port');
    delete_option('wordpress-https_exclusive_https');
    delete_option('wordpress-https_frontpage');
    delete_option('wordpress-https_ssl_admin');
    delete_option('wordpress-https_ssl_host_subdomain');

    I wish those simple instructions from the parallel thread could have been published as part of documentation:
    DELETE FROM wp_options WHERE option_name LIKE 'wordpress-https%';
    Somehow WPHTTPS_RESET leaves the garbage as per above select query :o(.

    I have a feeling that in order to make this particular plugin to work, quite a few unstated conditions have to be met.

    I am mostly into a scenario, where WordPress Address (URL) and Site Address (URL) point at the same insecure virtual host, while shared SSL access is provided via alternative URL.

    Most likely, in these circumstances, WordPress has to be deployed with multisite option, and WordPress Address (URL) should point at the shared SSL access via alternative URL.

    Would it be a correct assumption?!

    Back to the lack of the documentation, how option wordpress-https_ssl_host relates to WordPress Address (URL) and Site Address (URL)?

    Oh, well, it could be a repeat of the previous question, sorry!

    Cheers,
    John Smith

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic