We have recently run into a few issues where users were attempting to parse PHP code in .html files. We don’t recommend this, and this post is meant to explain why.
First of all, an understanding of file extensions need to be made. Technically speaking, a file extension doesn’t really mean anything. In Windows, a file extension tends to have more meaning than in other operating systems, like Linux (which is what our servers run on). File extensions are largely hidden in new versions of Windows, but people who are familiar with older versions of Windows (and DOS) may remember that files with a .exe extension were able to be “run”. These were “executable” files that would start a program or application. Likewise a .doc file would open up the file in Microsoft Word. A .txt file would open the file up in notepad.
But technically speaking, you could just as easily open up Notepad, type up some notes, and save that file as “notes.exe”. All this would really do is confuse other users because they would expect “notes.exe” to run something and in order to open and read the file, users would have to know to open the file directly from Notepad.
In this sense, we can see that a file extension’s main purpose is used to categorize files. We have been brought up in a culture where .exe file extensions are meant to be “executable”, .txt files are meant to be simple text files that can be read by Notepad, .jpg files are image files meant to be opened by an image viewer. The extension of the file is meant to serve as a way to quickly and easily categorize what type of file this is.
You can think of this also as a filing cabinet. You may have an insurance statement that you would most likely file in the Insurance folder. A bank statement would be filed in the folder label Bank Statements. Can you put the insurance statement in the Bank Statement folder? Sure, nothing will stop you. But when you go to look for that Insurance statement 2 years later, where are you going to looK? In the Insurance folder or the Bank Statement folder? A statement that is misfiled can lead to a lot of headaches later down the road.
The same is also true about putting PHP code in .html or .htm files. This just isn’t the expected behavior. PHP code has to interface with the back-end webserver. How this is done gets technical very quickly, but just know that the web server has to talk to a system on the server that understands PHP code and interprets this back to something the web server can understand. By default the web server only sends code from .php files to this system to be interpreted. While it is true that the server can be made to send .html or .htm files, it is just not the default behavior. So any change in the way PHP operates or any change to this webserver -> PHP interface system, non-standard setups (like PHP code in .html files) may get overlooked.
The TL;DR version of this is to always be sure to use file extension properly. This is going to save you a lot of headaches later on, if you follow the expected behavior for any file extension. If you want to use PHP code, you should always use a .php file extension for that file. If you choose to operate outside of this expected standard behavior, do not be surprised when you encounter rendering issues.
Over the next few weeks we will be performing some updates to Apache and PHP on all of our servers. These updates are necessary to bring our servers in-line with upcoming PHP updates (PHP 7.0 and PHP 7.1). These updates should incur just a few seconds of downtime while services are restarted during the update process.
If you experience any issues after these updates, please open a support ticket so we can investigate and correct any issues.
Again, these updates are necessary so that we can deploy future versions of PHP on our servers. We don’t have an exact timetable for when each server will be updated, but our hope is to conclude all of these updates by the end of September.
PHP released version 5.5.38 recently for their 5.5 branch. This effectively marks the end-of-life for PHP 5.5. Although they do leave the door open ever so slightly for future PHP 5.5 releases:
Note that according to our release schedule, PHP 5.5.38 is the last release of the PHP 5.5 branch. There may be additional release if we discover important security issues that warrant it, otherwise this release will be the final one in the PHP 5.5 branch.
What does this mean for us? Not a whole lot actually. We essentially skipped over PHP 5.5 as a default version and went straight from PHP 5.4 to PHP 5.6 as the default versions on our servers. This means that very few of our accounts are actually using PHP 5.5. For those that are using PHP 5.5 we aren’t going to change you immediately to PHP 5.6. Typically we try to offer a PHP version for a year after it’s last release, meaning that we would continue to offer PHP 5.5 through July 2017. I have not looked specifically at the numbers, but there are just very, very few of our accounts that using PHP 5.5. We’re probably not going to install PHP 5.5 on any server that doesn’t already have it. But if you are using PHP 5.5 you are safe likely for another year (an unpatched security hole in PHP 5.5 may change our timetable). But if you are using PHP 5.5, now would be a good time to start thinking about upgrading your scripts and systems to ones that support PHP 5.6 or perhaps higher.
This brings us to our current PHP offerings and schedule. Currently PHP is supporting PHP version 5.6 and PHP version 7.0. PHP 7.1 is in beta and may get a public release in the not to distant future. PHP 5.6 won’t go end-of-life until December 31, 2018. PHP 7.0 won’t go end-of-life until December 3, 2018. We aren’t currently offering PHP 7.0, mainly because Ioncube and Zend do not yet have encoder support for PHP 7. Adding PHP 7.0 support is on our list of server todos.
Because of the success we had with skipping PHP 5.5 as a default version, we are considering doing the same thing with PHP 7.0. PHP 5.6 still has a lifetime of over 2 years remaining. PHP 7.1 will probably be here before the end of 2016. It really just depends on how things go, but it’s looking like we will skip PHP 7.0 as a default version and go straight to PHP 7.1 as the default version successor to PHP 5.6. Like PHP 5.5 we will offer PHP 7.0, just not as a default version. When will we make a default PHP change? Not before Ioncube and Zend release loaders for PHP 7 or PHP 7.1.
None of this is really written in stone at this point, but this is our current line of thinking. It really depends on how adoption of PHP 7.0 and PHP 7.1 goes from the standpoint of script developers. Right now, adoption of PHP 7.0 is slow – again this may be because of the lack of Ioncube and Zendguard support. It may be that adoption of PHP 7.0 and PHP 7.1 remains low, allowing us to extend PHP 5.6 even longer until PHP 7.2 comes out. All of that just remains to be seen. But it is looking like we are going to skip PHP 7.0 as a default version.
At AMS Computer Services we always focus on customers first. And in that sense, we are always looking for ways we can better serve our customers. Are there things we could be doing better? Are there services or features that our customers would like to see added? What are the things we are doing well?
All of this requires communication and feedback from our customers. That’s why we have released our Customer Survey to get a better idea of what is important to you – the customer – and what we can do to serve you better.
We invite you to complete the Customer Survey. It is a very short survey and is completely anonymous. We just want to know what we can do to make sure your hosting experience at AMS Computer Services is the best it can be.
We are sending out WordPress outdated notices to accounts that we show as having an outdated version of WordPress installed. If you are affected by this, you should receive an email from us with the details.
It is important to keep your WordPress (and any script) up to date and practice good, solid security for your account. If you do not, then this can lead to your account being hacked, defaced, or used for abusive purposes. If this happens, then we may have to suspend your account. That is why security is important.
If you receive a notice from us regarding an outdated WordPress script on your account, that message will contain a section similar to below. I am going to take a moment and explain some of the items.
The email message will contain a section that lists your outdated WordPress scripts, and it will look something like:
Installed Path: /home/%USER%/%PATH%
Installed Version: X.X.X
Latest Version: Y.Y.Y
Script Website: http://www.wordpress.org
If you have multiple accounts, then you may see 2 or more of these sections in the email message.
Let’s take a look at this line by line:
This refers to your account. The domain name of the account that contains the outdated WordPress script. This is the main account associated with your web hosting account in our system. The actual WordPress installation might be on a parked or addon domain on the account, but our system can’t differentiate that.
This simply refers to the script as being a WordPress script. Similar notices may be sent out for other scripts.
Installed Path: /home/%USER%/%PATH%
This is an important part. This refers to where the WordPress installation is at on the server’s file system. This may be an addon domain path – in which case you would access the WordPress script via the addon domain. Generally speaking if this path looks like /home/%USER%/public_html/%PATH% – then you can access this by using the domain name in the Account section above – http://%YOURDOMAIN.COM%/%PATH% – but not all Installed Paths are going to be under the public_html folder. To access the WordPress admin dashboard for this installation you would typically just add /wp-admin to the end of the path, i.e: http://%YOURDOMAIN.COM%/%PATH%/wp-admin If you don’t know what installed path this installation is referring to in your email message, simply write us back and we can figure it out for you.
Installed Version: X.X.X
This is going to tell you what version of WordPress is installed at the above Installed Path. This can tell you just how outdated that WordPress installation really is.
Latest Version: Y.Y.Y
This will tell you the latest version of WordPress as it applies to your WordPress script. WordPress has different release trees and therefore different latest versions, depending on what version you have installed. For example, if you are using WordPress 4.3, then your latest version might be WordPress 4.3.3. If you are using WordPress 4.4, then your latest version might WordPress 4.4.2.
Updating WordPress is fairly straight-forward. You simply need to log into the WordPress admin dashboard for the installation you are wanting to update. Click on the Dashboard tab on the left side and click on Updates. From there you will see “An updated version of WordPress is available.” and underneath that will be a link to Update Now to the new version. Simply click that link and WordPress will be updated.
You can also update your themes and plugins from this screen.