I recently moved my Drupal 7 site to a new hosting server and I'm stuck at the login page. As soon as I try and log in, I get directed back to the same page, but the URL changes from /user to /user/1, which leads me to believe that I am actually logged in, but I'm not being forwarded to the correct page.
I tried cleaning my cache, emptying the cache tables in the DB but nothing helped.
Any ideas?
EDIT: To make things a bit more clear, I've used the specific server for various other Drupal 7 sites, so I know for a fact that the server configuration is not at fault here.
I suspect your $cookie_domain in /sites/default/settings.php is incorrect.
Try making it match your new domain and ensure there's a leading dot .
$cookie_domain = '.mydomain.co.uk';
Sometimes problems relating to logging in after a site migration can be because mod_rewrite was enabled on the first machine but not the second. A simple way to test this is to use the ?q= URL format (http://site.localhost?q=user) and see if you can log in like that. If that works then you can either disable clean urls from within the Drupal interface, or enable mod rewrite in Apache.
In my case the issue was solved only after refreshing .htaccess file in drupal root folder.
You can take the source here: https://github.com/drupal/drupal/blob/7.x/.htaccess
seddonym's comment about mod_rewrite led me to a slightly different solution. I was having the same problem but was able to solve it by copying the file rewrite.load from /etc/apache2/mods-available to /etc/apache2/mods-enabled.
I think the files in mods-enabled are some sort of link files (I am novice at linux still) but copying the files worked just fine. Maybe someone will come along and tell us the proper way to do this.
Sometimes all you need is to clear the cookies for the domain/website - it's possible you have old cookies alive that are causing this.
Get a cookie manager to help simplify this, e.g.:
Edit This Cookie (for Chrome)
Other answer might be that rewrite php module is not installed, to do that do the followings:
sudo a2enmod rewrite
Restart apache2
sudo service apache2 restart
In my case it was very stupid, on my page.tpl.php, there wasn't any "content" and the page--user.tpl.php didn't get read. Only had the line to show content in the page.tpl.php
Although that it is unlikely that you're as stupid as me. ;) Maybe it will be helpful anyway.
Arne
Related
I am setting up a website with Drupal, the website is deployed on the live server through bitbucket pipelines. Normally when I browse to myurl.com/user it redirects me to myurl.com/user/login however now I get this error:
Redirects to external URLs are not allowed by default, use \Drupal\Core\Routing\TrustedRedirectResponse for it.
I have already set-up the "trusted_host_paterns" however this doesn't seem to fix the problem.
trusted host patterns:
$settings['trusted_host_patterns'] = array(
'^myurl\.com$',
);
Just in case somebody else comes here: It is also possible, that you have migrated a multi language site to a different server / localhost, and in your database are still the old redirect domains, that will now no longer work.
To fix this, you need to manually change the following value in the database. Go to dr_config and search for language.negotiation
In the cryptic blob, search have a look for something like
{s:6:"source";s:6:"domain";
and change it to
{s:6:"source";s:6:"path_prefix";
afterwards empty all cache_* tables (to force a reprocessing of the configuration) and there is a good chance it might work then.
The pattern seems OK to me. However there is what I'd check:
Confirm using your browser that the redirect to /user/login happens to exactly myurl.com domain. Not www.myurl.com for example.
Try clearing cache as well.
Then looking through this post on DO
And then this one. It's a D8 issue not fixed yet.
I remember having a similar issue on one of my websites during development on a local environment and the issue was really in the pattern.
In the case you have this because of a multilingual site not finding the domains on localhost, put in settings.php:
$config['language.negotiation']['url']['domains']['en'] = 'my-en-url.localhost';
$config['language.negotiation']['url']['domains']['de'] = 'my-de-url.localhost';
$config['language.negotiation']['url']['domains']['es'] = 'my-es-url.localhost';
$config['language.negotiation']['url']['domains']['fr'] = 'my-fr-url.localhost';
I've been filtering through google to try to find an answer to this, but I still can't find one that fixes my issue. I have migrated a website to a new server. The framework is Symfony 2.8 on php5.6 using Nginx and PHP-FPM.
Here is a screenshot of the config.php page.
To resolve this, i've tried...
Changing the user for Nginx and php-fpm to both the user I log in with and Nginx, both didn't work
I've opened up the privileges on the cache and log folder to 777 within the app folder, and that didn't work, nope.
I've tried assigning the cache and logs folder to nginx:nginx, no go.
I've manually assigned app.php, app_dev.php, and the console file to have the umask(0000) and umask(0002), nope.
Restarted the Nginx service and php-fpm service after each change, nodda.
I've restarted the entire server thinking something might be stuck, but you guessed it. No!
That leaves me here. I've gone through everything that I can think of and it baffles me that Symfony still won't recognize the directory as writable. It seems like the most simple thing, but... nope.
Anything will help, please pass anything along.
After countless hours of research and scraping the internet for details, I have found the answer! I'm posting it here in case someone else is having the same issue... and hopefully I can save them some time. This took up two days of my life that i'll never get back.
For whatever reason, SELinux was causing this error. I came across this issue on superuser stack exchange, and it told me to temporarily disable SELinux to test. After running sudo setenforce 0 everything came back up. I then completely disabled it and everything has been working fine since.
This happened suddenly and i'm still unsure of the reason. The site worked for about a week before this was triggered.
You should read this to setup you directories permissions http://symfony.com/doc/current/setup/file_permissions.html
I always go for the point 3. with Debian/Apache, Unfortunately i never tried it with nginx.
I have around 10 plugins installed.
I use a wordpress theme by sitemile.
The site works fine sometimes, but very often, if I were to go to the login or sign up page, it displays the 500 internal error. I want to set up logs for see to see whats happening but I am not sure how I can do that.
Also, sometimes the homepage of the website loads very funky but if i go to other pages, it may or may not load that page properly.
Not an internet issue. Cleared cache as well. Interestingly, I see different results in normal and incognitu browsers.
Do these internal errors occur most of the time when you have a lot of plugins? Is there some other source of problem that I can check to make sure everything in my site is alright?
Error screenshot attached.
Homepage of website
Depending on your webhost, you might already have more details in a log file. Often times with apache it's called "error_log" and it can be found in your root directory or the directory of the file causing the error.
It could be anything from access permissions or a security block. So it's going to be hard for someone to give you an answer on this without more information.
Things to try:
You can try disabling one plugin at a time until it works.
Look for an error_log (or similar) file
Double check all of the file permissions, chmod and chown
Contact your web host and see if they can provide any insight
If you ARE the web host (or manage the server yourself) then you can check the apache error logs (if enabled) and/or security logs on the server
Double check any errors on the .htaccess file
A script could be consuming too much resources or taking too long to load, you can narrow it down by process of elimination and then disable/patch the culprit
Please see my DNN Forum Post for more details.
I've never had any issues with DotNetNuke installations. But with the new v5.20 (or v5.02, whichever it really is), everything runs perfectly fine through installation. I then get to the main default portal homepage. But as soon as I click any of the links available to continue (Home, Register or Login) I get 404 errors every time with a reference back to the applicable aspx page (Home.aspx, Register.aspx or Login.aspx.).
Windows 7, IIS7, SQL Server 2008. All permissions are setup properly on the directory and in IIS. I would think this is an IIS7 configuration issue, but I've tweaked everything in there a half-dozen times. No one at DNN is returning answers on my forum post anymore either after one guy tried.
Help!
This is something to do with the Friendly URL stuff. I found this blog post which talks about the Friendly URL Provider architecture. This made me try changing the urlFormat attribute for the DNNFriendlyUrl provider from "humanfriendly" to "searchfriendly", which made the URLs the way they used to be. I'm not sure exactly where things are going wrong and don't really have time to dig into it at the moment, but hopefully this will be helpful to get you moving again too.
With the release of DNN5 (up until 5.02.01 as of the time of writing), the friendly URL provider won't work when DotNetNuke is not on default port 80. There are different solutions floating around, but the simplest is just to replace the DNN friendly URL provider with the free one from iFinity. The installation is really simple and included in the download. Or see the following blog post:
http://www.sailer.com.au/dotnetnuke/dnn5-friendlyurl-port
Okay have you tried the 'old style' of login - domain.com/default.aspx?ctl=login
If that still doesnt work then i have to say that most likely something has happened to IIS - if so then you might just see if you can install the package you have on a different box or have a friend try a different box
I have done 2 upgrades with 5.2 and a few test installs with the Starter Kit Package and Install packages and have never seen this problem - not to say that it doesnt exist.
My next trial would be to go and redownload the install package from CodePlex and start from scratch to see if you can make the same thing happen again.
OKayone thing I dont think that has been mentioned in reading through everything is double check IIS.
My first guess without looking on your server would be to check if something happened to the 'check file exists' setting - i know this is changed in IIS7 so I cant point to the exact place to check this.
Here is a link to the IIS7 forums on it - http://forums.iis.net/t/1092696.aspx
http://forums.asp.net/t/1191083.aspx
either one might help - google also has a lot on this
Tell me how this goes in checking up on it and we can move forward from there!
you probably need to reg_iis on the version(s) of asp.net that your IIS is going to support.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
If the right version is not set up then you will get the 404 error
So placing it under port 80 works, right?
Is there a good reason not putting it under that port?
I am getting this error message while trying to access a wordpress blog which is installed in a directory. Is this due to .htaccess or something? Any help is appreciated.
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#xxxxx.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at xxxx.com Port 80'
This is almost always a problem with your Apache configuration. Errors originating in PHP won’t trigger the Apache 5xx handler, which is what you’re seeing.
Unfortunately, without more information, your problem is impossible to diagnose. I’d recommend that you:
Check the logs. First thing! It should give you a better idea where your problem is.
Stop and restart Apache. If there is a problem with permissions on something Apache needs write access to (logs), it could completely fail to start. This should give you the proper motivation to fix the problem, particularly if there are other VirtualHosts on that Apache.
Move your .htaccess file(s) somewhere else. If Apache works, you know it’s a problem with that file.
It sounds like you're getting some sort of PHP error but PHP isn't set to display errors. You'll want to check your Apache logs for detailed error info.
The mostly likely culprit is that you're missing some prerequisite for running WordPress, although all you should really need is Apache, MySQL, & mod_rewrite.
I was able to fix it by adding the following line to my .htaccess file:
php_value memory_limit 128M
Russ
This is happening to me RIGHT NOW.
As to from what I know, my hosting providers did a DNS change and so I'm waiting for the DNS to propagate, it's been like three hours and still zero.
Blog is showing ok, apache is up and working, I just can't get access into the WP Admin area.
If it does get fixed by tomorrow, I'll reply here so it can be of help for others.
Edit: I just fixed my problem.
In my case it was determined that the Fast Contact Form plug-in was creating the problem. I modified the folder name from si-contact-form to si-contact-form-hold then I regained WP Admin access.
After that I created a php.ini file with this string inside 'memory=64MB' and saved that into the wp-admin folder.
Manually deleted the si-contact-form-hold (to avoid possible corrupted files) and reinstalled the Fast Contact Form.
All my settings were already there and everything is back up and running good!
Hope this helps.
Look at http://zemalf.com/1470/wordpress-htaccess-the-definite-guide/, and look for the paragraph which says something like "Good and default .htaccess looks like this...."
My issue was a little bit different. I had an .htaccess file inside the wp-admin directory. I deleted the .htaccess inside of wp-admin and that fixed my problems.
Unfortunately it could be anything. Do static pages on the site work properly.
Have you checked the server logs.
I think it is likely to do with php. If static pages are there then possibly your config for wordpress is incorrectly configured or files missing.
Has php be working? Did the blog work and then stop? Did you get through the install process?
Check wordpress files ownership for the user are correct or not.
In linux ls -laZ command will display the ownership.
For setting the ownership for a folder use this command
chown -R username:username /user/username/public_html/
An HTTP 500 error could be caused by a great many things. Have you changed your .htaccess file recently? If you try to use a .htaccess feature that is disabled on your host, that is one possible cause.
Some more points
Blog has been running successfully. Just observed this problem since yesterday.
Blog is in a directory so it works something like this www.xyz.com/blog. Apparently www.xyz.com is working perfectly.
Update on logs
Getting these two errors in the logs:
File does not exist: /home/directory/public_html/500.shtml
/home/sub-directory/public_html/sub-directory/.htaccess: RewriteCond: bad argument line '%{REQUEST_FILENAME}!-f'
/home/directory/public_html/sub-directory/.htaccess: # without matching # section
How do I restart apache on cpanel ?
memory = 64MB;
The above line inside a php.ini file uploaded to the wp-admin folder solved my problem. I was not being able to log into the dashboard either through /wp-admin or /wp-login.php, and was getting a HTTP server error 500.
There can be multiple causes for this, I just solved mine, after 2-3 hours of going crazy.
I had another WP instance in a subdirectory inside the main WP instance (in the root folder).
Have checked / deleted .htaccess
deleted plugin folder
In the end, it was to do with the permission of the subfolder in which second instance was running. It was originally 775 (write permission for group), I had to change it to 755 (no write permission for group) and this finally fixed it, like magic.
This is of course just one of possible the answers to your question, I wanted to write it down though as I didn't find it explicitly written anywhere so it might save others some time.