I wanted to set up a blog on my website, to be accessible by something like /blog.
All the files were uploaded to public_html as instructed.
I then realised that I had both index.html (the original) and index.php in the same folder. I am considering moving all the WordPress files to a subfolder as I cannot seem to get any response from trying http://www.<mydomain>.co.uk/index.php
Am I barking up the wrong tree?
- This topic was modified 3 weeks ago by pinnerite.
At the moment it looks like
http://www.<mydomain>.co.uk/index.phpis going to go to WordPress while
http://www.<mydomain>.co.uk/still goes only to your primary site, so you should ultimately be able to make a redirect in htaccess to make something such as
At the mopment http://www.<mydomain>.co.uk/index.php is not going anywhere!
Except to a google listing.
It looks like I’m going have to learn about .htaccess before I go any further. 🙁
Your primary site uses index.html rather than index.php, and your current htaccess in public_html is redirecting index.php to your default use of index.html for your primary site. I do not know why index.php made it to WordPress yesterday and now it does not, but that really does not matter since your actually need to have your WordPress installation in a public_html/subfolder in order to completely avoid this kind of trouble. Then at that point, something such as domain.com/blog/ or whatever will always-and-only go to WordPress and all WordPress links such as domain.com/blog/page-2 will work properly. Yesterday I was being short-sighted while thinking a redirect such as domain.com/blog/ to domain.com/index.php could ultimately do what you need.
So now that you have a working installation of WordPress, you have a working copy of wp-config.php and it will not be difficult to get WordPress working in a sub-folder. I can help you with that step-by-step right here or you can start a new thread…but just be cautious of some of the casual “moving WordPress” advice you might get since you are dealing with a sub-folder installation that is a secondary target for your Primary Domain rather than what your overall hosting account is all about. Also, I would suggest *not* doing any editing to public_html/.htaccess at this point (or even ever at all) without first knowing precisely how your primary site and its access might be affected.
I really appreciate this.
I created /public_html/blog and moved all the WP files there.
So the next thing is to edit the database to include ‘/blog’ in the site address. However, first go to public_html/blog/ and delete any .htaccess file you might happen to find there.
note: Assuming you might do that via cPanel > File Manager, be certain you have things set to display hidden files in order to be certain you do not miss seeing an .htaccess if there actually is one.
Next find public_html/blog/wp-config.php and add these following lines just ahead of
// ** MySQL settings - You can get this info from your web host ** //to end up with this:
/** WP_SITEURL and WP_HOME ** * define('WP_HOME','http://example.com'); * define('WP_SITEURL','http://example.com'); */ //define('WP_HOME','http://www.asandco.co.uk/blog'); //define('WP_SITEURL','http://www.asandco.co.uk/blog'); /* note: Do not include a trailing slash on either line. */ // ** MySQL settings - You can get this info from your web host ** //
Those two ‘define’ lines should take care of the database and give you site access for login so you can set Permalinks and proceed with your new site. To activate those two ‘define’ lines, remove the double-slash comment marks ahead of ‘define’ on each line and save the file and then log in at the site…and then ultimately return to wp-config.php and put the double-slash comment marks back into place to de-activate those ‘define’ lines.
note: With those ‘define’ lines active, your site address lines at Dashboard > Settings > General will be grayed out.
I have not been handling this well.
I moved all the WP files from public_html to public_html/blog
I then edited wp-config.php as suggested.
There was no .htaccess in public_html/blog
I could not get into cPanel.
I assumed http://www.asandco.co.uk/blog/cpanel should do it.
For now I’m a bit stuck.
Your hosting account only has one installation of cPanel, and you get there by logging in at your hosting account and not by logging in at WordPress. Then at cPanel is where you should be able to find things such as File Manage, MySQL and phpMyAdmin utilities for doing your behind-the-curtain work on your primary site and its files as well as in or on your WordPress folders, files and database.
Having edited wp-config.php and having determined there is no .htaccess in public_html/blog, you should now be able to view
http://www.asandco.co.uk/blog/and to log in at
http://www.asandco.co.uk/blog/wp-admin, but I see those are returning an error unknown to me. I will give all of this some thought, but maybe someone else here already sees what you have going on and will jump in with a solution…
- This reply was modified 2 weeks, 2 days ago by leejosepho.
I finally managed to get into my hosting account’s cpanel and thence to MySQL.
I deleted and recreated the database. I returned wp-config.php and edite it to match the changes that I had made and copied the amended file to the site.
Fatal error: Can’t use function return value in write context in /home/asandcoc/public_html/blog/wp-config.php on line 32
That error is the same as what I saw yesterday, and the last time you could access the site at all was prior to adding the URL-update code to wp-config.php…and that makes me suspicious there might be some kind of coding or formatting error there in wp-config.php. Code files must be edited with a plain-text editor such as NotePad++, and then even just one wrong character can break the file such as you are now seeing when PHP gets to line 32 of that file. What you might try is to again delete the WordPress database and the wp-config.php file — first save a backup somewhere on your local machine — and then start over with domain.com/blog/wp-admin/install.php.
- This reply was modified 2 weeks, 1 day ago by leejosepho.
I always employ Kate for editing text but there is always the possibility of a ‘slip ‘twixt cup and lip’.
I’ll double check.
I reworked from wp-config-sample.php and uoloaded to the web site.
Line 32 seems to be just the closing marker of a comment(!)
I have done a little searching in relation to that error, and the things I have read lean toward issues related to PHP versions. But since you did not have that problem prior to moving WordPress to /blog/, I would doubt that is the actual issue. If I had your situation, I would delete everything in the /blog/ folder as well as all the database tables — tables only, not the database shell — and then unzip a fresh download of WordPress and then copy or move everything inside the /wordpress/ folder to /blog/, then double-check and add wp-config.php and see what happens. Other than that, my only only thoughts would be to talk with your host about the PHP error and/or try to find someone (such as on stackoverflow.com/) who knows how to troubleshoot that specific error.
As suggested I deleted everything on /blog and on my download directory relating to WordPress, excluding the zip file and went through the whole process again.
The only difference this time is that the error code is now 77.
I’ll tackle my hosting supplier as soon a i can.
Thank you for your efforts. I’ll report back as soon as I have some fresh information.
All enquiries led back to errors in wp-config.php.
Finally, it occurred to me to search for a php code checker. I tried it on the sample config.php file – No errors.
I then changed each item line by line running the php checker each time until finally the complete file was error free.
I copied it to the blog directory on my domain and attempted to access it from a browser. No problems.
I still am baffled by the earlier problems but thank you for hand-holding me. 🙂
Your error checking is beyond my own experience, and I am glad you got things going! Your initial problem of index.php not working after it had first worked made me suspicious of some kind of caching problem at your host, but neither do I know anything about that kind of thing.
Now that you have a working installation, you need to protect it by “hardening WordPress”…and my personal recommendation is to install the BulletProof Security plugin and use all of its recommended permissions settings…
For example: I have .htaccess set at 0404 and I have wp-config.php set at 0400 so nobody but me can ever read them or write to them. WordPress is “secure” in the sense it is not easily invaded via vulnerabilities, but not having good site security at the gate (where I use NinjaFirewall) and all doors (BulletProof Security) will definitely leave your site open for invasion.
- You must be logged in to reply to this topic.