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)
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 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.
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 am new to drupal.I have to work on Live website with drupal 7. This website is working fine. I downloaded the website on my localhost.Home page of the website works fine.But when I click on any link in menu it shows me page not found.When I checked the url it is showing me like this:
http://Locahost/page/category/she.php
But when I check my project page and category folders arenot present.Also when I searched on live website these folder are not there also. But on live server it works fine.Url on live server is like this:
http://mywebsite.com/page/category/she.php
But Page and category folders are not there. I am a new to drupal. Any help to resolve this url generation issue will be appreciated.
After checking for possible misconfogurations as outlined by jpschroeder's you could try using the Backup and Migrate module.
Use the default settings and the cache tables will not be saved in your backup. You don't need them, as they will be re-created on the new server as pages are served for the first time there.
There's a good tutorial on this at http://www.seascapewebdesign.com/blog/how-transfer-your-website-one-server-another
Using Wordpress-Heroku and ran into some issues. Changed my app name from heroku's autogenerated name to something more descriptive, but /wp-admin gets redirected to the old name. Of course there's no such app anymore. Also tried to set up a local version but found that going to localhost:8888/wp-admin redirects me to app on heroku.
I guess that something in the installation process creates permalinks to the site address in the database. Is there a way to fix this without resetting the installation?
I change servers (copying live sites to localhost) fairly frequently following the Codex. While not on Heroku, I assume the process would be the same.
In your case, the Search and Replace for WordPress Databases Script mentioned should do the trick (after backing up the database, of course).
I assume you've updated your wp-config.php to point to the new database.