A client wanted a site-wide landing page with some basic images and a few navigation buttons to front-end their WordPress site and other places like their Etsy shop and Social media links. Out of the box WordPress allows you to define a home page (see under the admin options for Settings->Reading) but that isn’t exactly what they wanted as that is still within WordPress and so has the header, menus and footer and all the other stuff related to a WordPress site unless the theme allows for all of these to be turned off.
When you connect to the URL without any path or a resource file name e.g. www.openmutual.org rather than for example www.openmutual.org/blog/example.txt then (using Apache) the file that will be presented if a file is not specified in a URL is decided by the mod_dir DirectoryIndex directive (or in IIS the
WordPress by default has an index.php file in its root and usually this is what is normally used. If your hoster has setup their DirectoryIndex similar to the above then the index.html file will override the index.php If so then you are good to go. If not then you will have to get your hoster (or it may be you) to get index.html being dished out in preference to index.php. The two options open to my client are to,
a) move the WordPress out of the site root e.g. move the files to /blogging or similar subdirectory and then add a static web page e.g. index.html
b) or add an index.html with static code in it that will be run first before index.php
The option a) is obvious but I wanted to avoid that for the moment so I picked b) to see if that would work. Please read the “quirks” at the bottom and test this on your own test beds before playing with a client site !
Step 1) On WordPress create a new page with any name and slug (we’ll called it My Home and have a slug of my-home )
Step 2) Copy the contents of the existing Home page to this new page (use control-C and control-V or similar)
Step 3) There is usually no need to change anything in Settings->Reading for the front page displays but you cannot set it to a Static page that is navigable in the menu. The reason being is that whatever you set as the WordPress Static front page is given a slug of /. If it is already set to posts of Home then you can leave it as that.
Step 4) Edit your Theme menu in Appearance -> Menus and remove the existing “Home” or whatever has a slug of your site root (/) and replace it with your new copied home page (in my example “My Home”)
Step 5) You can add the original Home page back but give it a different name e.g. “Site Root” as it will jump you back to the non-Wordpress file.
Step 6) Test that your tweaked WordPress site still works OK. You won’t notice many problems yet.
Step 7) Create an index.html file and have at least the one link to your new “My Home” WordPress slug e.g. <a href=”./my-home”>My Blog Site</a>
Step 8) Upload and check the new file gets priority. If not then check the Apache mod_dir DirectoryIndex directive is set correctly e.g.
DirectoryIndex index.html index.php
That is all is needed. Now when web visitors hit your web site they will get the index.html and they can then navigate from there. When they click any WordPress link slug from that landing page then they then go to your WordPress site and will stay there unless you have given them a menu option to escape back up to the index.html.
- You MUST set Permalink Settings to something other than the default of …site/?
- When you are in Media Manager then when you try and view an attachment then it will go to the attachment page and not the media file link.
- When you insert an image into a post or page then do not use the attachment post ID but the media file link.
- This may not work on other web servers – I have only done this on Apache
Using Contact form 7 Version 3.2 fine on my personal blog web site and then upgraded to WordPress 3.4. The contact form stopped working with the usual red administration error message.
I found that I had to add WP-Mail-SMTP (latest version Version 0.9.1 ) plugin and set SMTP to defaults of localhost and then it worked again.
Rather odd. Take care if you are upgrading to WP 3.4 to check your contact forms still work.
Client had decided to change ADSL provider. They got sent a new ADSL modem and I had to install this. The modem didn’t need any configuring as it was ready-to-go out of the box but its default LAN that it allocated DHCP was 192.168.1.0/24 rather than the old LAN of 192.168.0.0/24
The client site has a SITECOM AP on this LAN and in another part of the building, a Belkin WIFI universal range extender that extended the WIFI. I had power cycled the SITECOM AP as it got its internet facing IP address from the DHCP server in the ADSL modem, but I never rebooted the range extender as it is in another part of the building and shouldn’t need to be rebooted.
The laptop that connects via the range extender was working fine but every few minutes Windows complained about an address collision. The laptop is the only device on this range extender. The fix was easy – power cycled the range extender. So though it shouldn’t need this as it’s using the different address space of the SITECOM AP (which is doing NAT), it did actually need doing.
My main laptop that I use on a daily basis just is not surviving this weather (we’re 30 DegC indoors). It’s a 5 year old IBM that has had a hard life but the CPU is overheating and so the CPU is going into thermal shutdown.
I’m migrating my settings to a spare Laptop whilst I pull apart the IBM to fix it.
The new laptop is a clean build from bare metal and whilst I can copy files from backups I need to also copy my profile for Firefox and Thunderbird.
I used mozBackup and it works perfectly. I installed version 1.5.1 on the old laptop, performed the backup of Firefox (version 5.0) and Thunderbird (version 3.1.11) and then installed the mozBackup on the new laptop and did a restore (Firefox is 5.0 but Thunderbird on the new laptop is 5.0 as well).
All my emails, passwords and settings have been copied perfectly. The Firefox backup file was only a few megabytes but the Thunderbird was just over 1 Gigabyte. I have a dozen email accounts and hundreds of thousands of emails. This is a real torture test for that program and it worked perfectly.
I have enigmail and lightening so you’ll have to update these to the new versions but Thunderbird does this for you when you first use it. Also on the new laptop I have installed GNU-PG version 2 so you’ll have to set the OpenPGP preferences to the gpg2.exe file but that is about it.
I’ve just donated some money to this developer. This is the second time in 4 years that I have used this program and it’s done the job just right.
The simplest way of migrating a web site from one IP to another and testing it before changing your DNS is to just change a local test PC host file.
It varies by operating system but if you change the host file and make the new IP address point at e.g. www.example.com then you can install your new content management system and add the content at your leisure by just referring to it by its normal URL. Everyone else in the Internet gets the old site on the old IP but you (and only you) gets the new site on the new IP.
Upload your content, edit and test it as usual.
You can also test POP3 and SMTP in this same way by editing your test PC hosts file to point at the new IP address for the POP3 and SMTP addresses e.g. pop3.example.com or even webmail.example.com.
When you are ready then simply change the DNS (@) A (and AAAA) records to the new IP addresses.
Do this in two steps,
1) switch the www and similar Web site related IP addresses but keep the webmail and MX records on the OLD IP address. If the web site works as expected (remember to remove any “test” entries in your test PC hosts files) then…
2) at a suitably idle time change the Webmail and MX records. Now test the incoming and outgoing email works. On any test machines make sure that a ping to the relevant record e.g. mail.example.com or pop3.example.com returns the expected IP address.
If it is fine then after a suitably long delay you can decommission the old web site. Do this as follows,
a) backup all databases – mark them as the OLD SITE
b) backup all web site content (media etc) – mark them as the OLD SITE
c) backup any other OS specific configuration files – mark them as the OLD SITE
d) delete the old site. How you do this will vary (delete containers on VPS or reformat a server disk on standalone machines or delete the files via FTP or ssh) but never leave it hanging around.
We’ve been running this for around 6 months on a local test server. We’re currently in the process of migrating clients and servers to logging to our openmutual.org server.
We have built up a number of modules to monitor certain interesting items on eJabberd and Asterisk. Currently looking at status for Freeswitch (which is what we use locally to handle internal calls).
We’ve shifted our server from where it was to Host Europe (Germany) because the hosting was up for renewal and Host Europe prices for the basic Virtual Server (Ubuntu 10 with 1 Gigabyte of memory) that we need looked good plus I have been using a forum that is hosted with them and never really seen any problems.
Will be moving the .net and a few other domains over next two weeks.