I have a a WordPress multisite install (using subdomains, not subfolders) running on EC2 (with Cloudflare for DNS). It is working good.
I am starting a new project that I want to setup a subdoamin for that is not using the multisite install. I have been trying for a few days to get it to work, but i cannot get it to stop sending trafic to wordpress (which is telling me there is not site set up (I hae set nothing up in wordpress as this project has its own site / code that I want to keep seperate)
What am I doing wrong?
Thank you?
After quite a while of banging my head agenst the wall I figgured it out.
How I got it to work was I went into the Apache config file (httpd.conf) and changed the server name to a fake address, then wet into vhosts.conf and created a virtual host for every site on the server, including the main one (that had been listed in the main conf) and the wildcard (for multisite).
I made sure the wildcard was listed LAST. After restarting the server it worded like a charm.
Related
I'm trying to install my wordpress to AWS EC2.
I created my EC2 instance and send files to that. (and instance domain has ben blablabla.eu-west-1.compute.amazonaws.com)
I used aws certificate manager for my domain.
I used cloudfront for using ssl certificate and; values are:
origin: blablabla.eu-west-1.compute.amazonaws.com
cnames: mysite.com
But when I connect to mysite.com/wp-admin it redirects me to blablabla.eu-west-1.compute.amazonaws.com.
Yes, I tried to change siteurl and home variables. And it doesnt make any changes.
And other hand; when I try to connect with "mysite.com" it converts all files to http (buy when I try to connect wit blabla.eu... all files are https)
What should I make?
Can be various things but I assume (based on previous experience) that some strings in Wordpress still contain mysite.com.
Before you go any further, it's worth to note that you can migrate your domain mysite.com to cloudfront/ec2/acm.
But if you want to just switch to another domain what I usually do is that I install wordpress CLI https://wp-cli.org/ and then I run wp-cli search-replace mysite.com blablabla.eu-west-1.compute.amazonaws.com --all-tables. It's good to have a backup just in case something went wrong, but this worked for me multiple times without any issues.
I am migrating my site to digital ocean and I am having an issue with Https. I have moved the directory and the apache2 config file and mysql database. I believe I set everything up correctly but now I want to test it. I have edited my /etc/hosts file with my new ip and sitename.com. However when I try to go to my browser and look to see if the site works it keeps trying to redirect me to the https version of my site.
I have tried going to chrome://net-internals/#hsts and deleting the site but it still redirects to https. How can I test my site without being redirected to the still hosted version of my site?
Thanks!
Aside of the wp_options field, WordPress stores lot's of links 'hard-coded' which all will contain the https. You would need to do a full search and replace on the database, but be aware of serialized stuff. To to safely perform a search and replace you could use a program found on: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Works like a charm.
Another way is by using wpcli if you have commandline access and wpcli is available. From the command line go to your root directory (containing the index.php) and type:
wp search-replace https://www.your-domain.example http://www.your-domain.example
Or type:
wp search-replace https://your-domain.example http://your-domain.example
Based on your setup up course.
Always make a full backup of your database before performing these actions, so you can restore if any problems occur.
So I've seen a bunch of questions like this, but many of them have no answers or the setup seems to be slightly different, so I thought I'd venture a new one.
I also apologize if some of this is vague and rushed, I'm sort of pulling my hair out trying to figure things out, but want to give as much detail as possible.
So I have a multisite WordPress installation on a Google Compute Engine instance. It was launched from the Cloud Launcher (https://console.cloud.google.com/launcher/details/bitnami-launchpad/wordpress-multisite). I have three sites running, one at mydomain.com, one at dev.mydomain.com, and one at staging.mydomain.com. It's all been working great for the past several months, but this morning a colleague was updating a plugin (Beaver Builder in case that turns out to be significant), and perhaps simultaneously taking a backup with Updraft Plus. In the middle of the update/backup, the browser redirected to a long error saying the update failed, and from then on the site was showing a 500 Server Error.
I got in to work about half an hour later and noticed it was showing the "Apache2 Debian Default Page". I took a look at the httpd.conf, and noticed the DocumentRoot was pointing to the default Apache folder. I tried changing it to the WordPress install folder, and then was getting a different error related to permissions. I set the file permissions of the wordpress install to the recommended settings, and after that both subdomains worked. The root URL was kind of working -- it redirected from mydomain.com to http://IPADDRESS/wp-signup.php. I looked in the wp-config and saw that DOMAIN_CURRENT_SITE was now set to the IP address, as well as the home and site url fields in the database. I changed them all to the domain name, and started getting a redirect loop error.
So for now I've left it as redirecting to the IP address, and added a NOBLOGREDIRECT setting to the wp-config to stop the wp-signup.php redirect. I am obviously not great at sys admin things, so I have no idea what to try next. I've ruled out the htaccess, plugins, and DNS settings (DNS hasn't changed).
Any help or direction would be greatly appreciated!
If you got the Debian Apache page then it is highly likely that someone installed the Debian apache2 package, which conflicts with the apache bundled in the stack. I advise you to uninstall the Debian Apache:
sudo apt-get remove apache2
Then restart the server services:
sudo /opt/bitnami/ctlscript.sh restart
I am currently running on the newest freebsd 64 bit server 9~
the problem is that I have:
2 seperate blogs on my server with two different domains
The older one was "donosiciele.pl" - works fine
The newer one "digsite.cat" has a subdomain multisite configured.
Lets cut to the chase. I do not have a dns wildcard ( *.digsite.cat ) so I had to edit my namedb file digsite.cat.db. After www I added subdomains for scary.digsite.cat and so on.
www A 37.59.20.16
scary A 37.59.20.16
music A 37.59.20.16
fashion A 37.59.20.16
The problem is that when you go to www.digsite.cat everything is fine, www.donosiciele.pl - fine
www.music.digsite.cat - you will get redirected to the "elder/1st" wordpress cms which runs under www.donosiele.pl
I have no idea how to deal with the problem, and I thoroughly search wordpress forums for that.
The answer to that is to create an apache virtual host for the given subdomain :)
I have a Wordpress Multisite which was working fine until I migrated the instance over to a new physical server.
The funny thing is that The instance itself is fine: I can get to everything except one of the sites. I cannot get to it's Admin section either, both the individual site and it's admin section come up as blank white pages. But none of my other sites do which I find rather weird.
It's not a database connection issue. I don't believe it's an .htaccess issue because i just copied over the same .htaccess file from the server that the whole instance was previously working on.
The only thing I can think of is that the Drive that Wordpress sits on is now different (D: now as opposed to E:).
I have mod_rewrite enabled and like I said all the other individual sites are working along with their individual admins.
I moved from Windows 2003 server to a Windows 2008 server and they are both on Apache Web Server.
Anyone else have the same problem or know of a way to remedy this?
A blank white page is a php error.
Check your error logs. That one site is using a plugin or theme with a conflict.