I have a drupal 7 site that I just moved to a new server. I'm logged in as admin, but when I click the logout button on the admin bar (I have admin module installed) or on the /user page, I get the following:
Page not found
The requested page "/user/logout" could not be found.
Looking in the apache logs reveals a 404 for /user/logout.
So, what's going on here? Flushing caches both locally and through the admin menu in drupal does nothing--I remain logged in, and the admin bar is still there, so I don't think it's a cache problem.
I'm fairly new to drupal, so please include extra detail in any responses. I won't necessarily know where to put php code if you just give me a block of it without context.
This turned out to be something fairly specific to my case. I had an module installed which used the CAS module. It allowed authentication through a particular ldap server. (This module was built for all users of that particular ldap server, and isn't home-made or available on the drupal site) We'll call it foo_cas for expedience. When I moved to the new server, foo_cas was no longer required--besides that, foo_cas broke and no longer allowed me to login to the ldap server. My new server did not have the php ldap plugin installed, and I suspect that that's why.
Anyway, after the move, I couldn't log in again to disable foo_cas (because of the above ldap problem), so I just deleted the folder sites/all/modules/foo_cas on the backend. This is what broke the logout url. I'm not sure what did it on the code level in foo_cas.
My solution in the end was to put the foo_cas folder back in the sites/all/modules directory, which made the module available again, but disabled. I then used the uninstall tab under modules in the UI to uninstall foo_cas.
I suspect foo_cas made a database change when it was installed that needed to be undone properly by uninstalling it. Now, /user/logout works again.
Related
Background:
I have a WordPress website that lives in a Google Cloud-based load balanced environment, and as I work through getting CI/CD setup I elected to isolate one of the servers so that my team could properly run through isolated testing. Since the website is on a regular domain (www.mybusiness.com), I created a duplicate database from our production DB and pointed the isolated server at this new test database. From there, I updated both the 'siteurl' and 'home' values with the isolated server's IP address in my wp_options table, and from there I can access my isolated WordPress site by simply using the URL. However, this is where things get frustrating: the login page simply refreshes after a successful login attempt, while blatantly incorrect login attempts with invalid credentials properly return user login error messages.
After countless hours searching the Internet, Stack, and elsewhere, I've found that the most common solutions are either:
Clear your browser's cookies / cache.
Try logging in with completely different devices (other cell phones, laptops) to confirm it's not a device or local browser-cache issue.
Deactivate and test each plugin,
Confirm your 'siteurl' and 'home' values are correct.
Test your .htaccess file to confirm that's not the problem.
Clear your user's WordPress 'session_tokens' meta_key value.
Revert back to an older / default WordPress theme to confirm if it's a theme problem
Run WordPress's built-in DB repair tool.
Create new WordPress salts and swap them in inside the wp-config.php file.
Enable the 'WP_DEBUG' constant to see if anything in the error logs pops up.
Test non-HTTPS versions of 'siteurl' and 'home'.
After trying all of the above, nothing seems to work: reverting to an older theme (twentynineteen) still presents the same login page refresh issue, and I've gone through every plugin on the server to see if deactivating one or all of them creates a solution - none seem to be the root cause. Error, mysql, and auth logs are also maddeningly clean.
Interestingly, if I add a trailing slash to my IP address-based 'home' and 'siteurl' value, from 'https://11.11.11.11' to 'https://11.11.11.11/' I do successfully get to the correct internal landing page (https://11.11.11.11/landing-page/) - however it just displays a 404 with the basic white screen.
Current WordPress version: 5.4.7
This leaves me with a few questions:
Is this a file permissions issue somewhere? Are there any key WordPress files in which permissions could create this effect?
Would Apache or anything VPC be in play here? I checked out our Apache .conf files, but those don't seem to be the suspect.
Should we look into a WordPress upgrade knowing we're a bit behind with 5.4.7?
Thank you in advance for the help!
I have working Drupal project on an old server running Apache2. I am trying to move to new server running nginx+php-fpm. I also changed the site's domain during the move.
The move was mostly successful except a few details:
In the admin panel #overlay stoped working and every link (ex.: mysitename.org/#overlay=home/structure) rewriting to mysitename.org/home/structure. I guess I have some problems with new php.ini/nginx rewrite rules or something similar but cant find out what exactly.
After login user being redirected to mysitename.org/users/username but on previous domain user stays on page he was logging. Database and files of Drupal are exactly the same on both servers.
image_captcha module stops generating visible captches. Have read many topics about this module but no answer found. (GD JPEG support is ON)
I recently installed the newest patch to my Magento site (v1.7.0.2) as well as a custom extension called GeoIP from MageWorx.
After installing the above and clearing my cache/sessions, going to log into the site it presents me with the admin login screen as usual, but after I log in correctly the page 404s. The URL is showing a correct back-end URL, but the actual page is a complete 404. No admin panel, no errors.
I've checked the error logs to no avail, I've cleared the cache and sessions multiple times, I've uninstalled the extension by tracing the files it put up and deleted them, I reverted the patch installation, cleared the cache and sessions again, and I'm still not able to get into this site.
It's a multi-store for what it's worth, and any information or help getting pointed in a correct direction would be very much appreciated.
I was having the same issue (Magento CE 1.9.2) - and for me the solution was a question of a setting for the Admin Startup Page ( in System - Configuration - Advanced - Admin - Startup Page )
The list of pages to select are in the current Admin language - but if the default language is different, then you'll (usually) get a 404
... in other words, make sure that you are in the default language when you change this setting, AND change this setting if you change the default language
(for info, the Admin language is set in General - Locale options, with scope of "Default Config". If you want front-end to have different language, then override the same setting with scope of "Main Website")
i have a really weird problem on a typo3 site.
The site currently runs on Typo3 4.6.6 (yeah i know we are in the process of upgrading it to 6.2 LTS)
In the backend we have 3 separate pages. The webspace where this site runs was currently upgraded to PHP 5.5. Nothing else has changed (as far as we know)
The problem is that on certain pages we get redirected to a https version of the same page, although the link is a http link.
See for instance here: http://www.phd-cell-signaling.at/home.html
If you open this it loads fine. But as soon as you click on a (http) link on the site, you get redirected to an https version hence the browser doesn't load all the stuff included via http (stylesheets for instance). But when you then delete the "s" from the address bar and hit enter you don't get redirected. And this is something i don't really understand.
And if that'd be a general issue shouldn't the other pages in the same typo3 environment also be affected? Or am i missing something here.
Since I'm not that familiar with typo3 it would be greatly appreciated if somebody could link me in the right direction where the problem could be.
We use realURL for example. But I checked the configuration i found and it doesn't appear to do anything that causes the redirect.
I also checked the typoscript configuration of all the pages in the backend with no success.
Are there any other plugins that might cause something like this?
Any help greatly appreciated.
When you follow a link on the page you posted, then the webserver returns the statuscode 301 (moved permanently) with the new location for that page (which is the requested page with the HTTPS scheme).
When TYPO3 is properly configured for SSL usage for single pages (so a backend user can use "Choose protocol" selectbox in the backend), then it already renders affected links with the proper scheme.
Your problem described can have multiple reasons. Please check the following:
Inspect the .htaccess file in the root directory of the TYPO3 website for any scheme redirects
Check if the webserver itself has configured scheme redirects for that virtual host
Goto the TYPO3 extension manager and search for local installed HTTPS or SSL redirection extensions
I moved my WordPress install from a development server to a freshly installed CentOS Apache 2.2 PHP 5.3 server. Initially, everything was working well. Logging in wasn't a problem, but then I noticed after logging in as a WordPress user and loading a new page I would be logged out.
What PHP settings do I need to have enabled, or are there any other considerations, when using a fresh server for WordPress that would make users not able to stay logged in (almost like the session isn't saving them)?
edit
It seems like the server isn't logging people in, but is reading the $_POST variable, so why would WordPress not save logging in?
The answer was looking at output_buffer. When this was off, the wp functions couldn't save to the session because something was already writing to the header.