Possible to have both WordPress and non-WordPress sections on the same domain?

Possible to have both WordPress and non-Wordpress sections on the same domain?

yes. You already have WP in its own directory. Tha’s fine.

There doesn’t seem to be a wp-config.php file.

Check if there is a wp-config.php in WP installation directory here: https://www.domain.com/wp

It should be there in the /wp folder unless someone moved it. If it’s not there, create one.

I would suspect a problem with htaccess since it seems WordPress is somehow assuming or is being told everything at that domain name is WordPress.

Thanks so much for the help, all.

@tara I Just checked and there appears to be a wp-config.php file in the /wp folder. According to my FTP program, its date is 11/15/12 so it looks like it hasn’t been changed recently. Do you think there might be something I need to update? As I mentioned earlier, everything seemed to be working fine until I upgraded to 3.7.1. I wonder if there could be some conflict there?

@leejosepho That’s really interesting. To be honest, I know next to nothing about htaccess files. I just checked and it appears that I have not only one .htaccess file, but also .htaccess copy, and .htaccess copy 2 in the /wp folder. Do you think this could be causing a problem? Here is the code in .htaccess file:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wp/index.php [L]
</IfModule>

# END WordPress

Have you tried:
– double checking all in the info in the wp-config.php.

– deactivating ALL plugins temporarily to see if this resolves the problem. If this works, re-activate them individually (one-by-one) to find the problematic plugin(s). If you can’t get into your admin dashboard, try deactivating via FTP or SFTP or whatever file management application your host provides. If applicable, also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old.
– To rule out any theme-specific issue, try switching to the unedited default, core-bundled Theme (such as Twenty Twelve or Twenty Thirteen) for a moment using the WP dashboard. If you don’t have access to your admin area, you can switch to the default theme by renaming your current theme’s folder in wp-content/themes and adding “-old” to the end of the folder name using via FTP or SFTP or whatever file management application your host provides. Alternately, you can remove other themes except the default theme. That will force your site to use it.
– resetting the plugins folder by FTP or PhpMyAdmin. Sometimes, an apparently inactive plugin can still cause problems (because the hooks remain unless plugins completely removed or some plugins stick around in cached files. So by renaming the folder, you break them and force them inactive).
– If the above troubleshooting steps fail to resolve the issue, try manually re-uploading all files and folders EXCEPT the wp-config.php file and the /wp-content/ directory from a fresh download of WordPress. Make sure that you delete the old copies of files & folder before uploading the new ones. Read the Manual Update directions first!
– Always backup everything (including your database) before doing any actions, just in case.

Our setups at our servers are not the same since I have a primary domain and three add-on domains, and neither do I really know very much about htaccess. However, and because of how BlueHost handles all of that elsewhere, I do not have a line like this even though my primary domain is in its own folder alongside my add-ons:
RewriteBase /wp/
I could be wrong here, but that looks to me like all incoming traffic is being sent to domain.com/wp/.

Check your copies of htaccess and see what might be different there…and then after you get things straight again, or even if the problem ends up being somewhere else, set the permissions for that file to 0404 so only *you* can ever change it!

Update! I got to thinking a bit more — I have been up for 16 hours now — and my new guess is that your attempt to go to domain.com/beta is being sent to domain.com/wp/beta where no wp-config should be found anyway…

@tara thanks for the tips. I just tried deactivating all my plugins and switching to the default 2013 theme but it didn’t seem to solve the problem. I guess the next step will be resetting the plugins folder and/or reuploading the files. To be honest, I’m a little nervous, but if all else fails…

Thanks again!

@leejosepho Thanks so much for the help. Especially considering the fact that you need some sleep!

I just assumed that the RewriteBase /wp/ was a signal that the WordPress folder exists in the /wp directory. Do you think that is causing the problem?

I should maybe clarify that the .htaccess file I posted above is contained inside the /wp folder, not the root directory. I just checked there and there is another .htaccess file with just the following code

DirectoryIndex index.php

Is it possible for a site to have multiple .htaccess files in separate folders?

Oh, and I also tried moving the extra two “copy” .htaccess files into another folder and unfortunately, the problem still persists…

Another note about .htaccess:

I also have a .htaccess file in the /beta folder. Within that folder, I am using Kirby (getkirby.com) a file-based CMS. Here is the .htaccess for that folder:

RewriteEngine On  

RewriteCond %{SCRIPT_FILENAME} !-d
RewriteCond %{SCRIPT_FILENAME} !-f  

RewriteRule ^(.*)$ ./index.php?request=$1

RewriteBase /beta

Is it possible for a site to have multiple .htaccess files in separate folders?

Yes, my primary domain has two. Its first is a short one in my public_html folder to send traffic to its own folder, then its second is in the WordPress installation’s own folder and is essentially identical to the ones BulletProof Security writes for my add-ons beside it in their own folders.

Needing sleep or not, I having exhausted my own knowledge here,,,but maybe check with your host about why things are not working as they should since I would guess that is a server problem rather than an actual WordPress problem even if WordPress did rewrite your htaccess. And again, lock those permissions after you get things straight! I have seven operating systems on my machine here at home, and I learned a long time ago to never again let any of them “take over” in control of my machine’s startup! But, I digress…

Ok, thank you all so much for your help on this. I don’t know how I missed this, but I just noticed that my /beta (i.e. non-Wordpress folder) was filled with a bunch of WordPress files. Everything from wp-activate.php to wp-blog-header.php to the WordPress index.php file. I definitely didn’t put them there so I can only assume WordPress somehow added them when I upgraded.

Very confusing but after carefully weeding out all the WP files it seems to be working okay. Again, a million thanks!

Cool beans, and post back if you ever learn or figure out exactly what had happened. The 3.7.1 update apparently believed it needed to do something — Do you ever wonder why we speak of software as if it had free-will cognition of its own (or maybe even hope it actually does)?! — in your /beta/ folder (or in every folder inside your “root” folder)…and those files you deleted would indicate it got confused at some point and attempted to do (or to update) an installation there but gave up when it found no wp-config file inside /beta/). If you ever need to dig further, talk with you host about how they point traffic to add-on domains. At BlueHost, none of my domains (primary or add-on) knows the others are there and each has no idea at all that it is in a folder of its own inside “root” (and each Site address and WordPress address at Dashboard > Settings > General looks like https://www.domain.com without anything tricky ever being done anywhere). So, and whether via your htaccess file or elsewhere, your host/server also should be able to point domain.com/beta/index.html or whatever to right there.

PS: My guess at this moment is that you might have to disable automatic updates (and maybe even only do manual updates?) to keep that from happening again:

/** Disable All Automatic Updates
** add to wp-config.php
*/
define( 'AUTOMATIC_UPDATER_DISABLED', true );