[subtitle heading=”1″ subtitle_content=”How to get your WordPress website ready for https.”]

Starting in July 2018, your site will be marked as “insecure” by Googles Chrome browser.
We have added free SSL certificates for all our customers so that you are ready to go right now.

However, often you will need to make some changes to your website to ensure that it uses https:// instead of http://

Here we are showing you how to re-configure your WordPress to use https:

First, login to your WordPress admin and change the WordPress Address and Site Address to https://…

WordPress General settings for https
After logging into your WordPress, go to Settings -> General. Now change the Site Address and WordPress Address to https://

Now, if you made the mistake to use absolute links or images in your WordPress in the past, you now need to change those from http:// to https://.

You could simply go through each and every post and page of your WordPress and manually make that change.
If you however have hundreds of pages and post like us, we suggest to use a Search and Replace plugin instead.

The first step for this is to MAKE A BACKUP:
Login to your Control panel and access Softaculous.

Make A WordPress backup Step 1 Hsphere
If you are in our OLD System.
Make A WordPress backup Step 1 cPanel
If you are in our NEW system.

Now, get a list of your WordPress installations (1) and Click on the Backup icon next to the WordPress install you are working on (2):

WordPress https make a backup step 2

Follow the steps until the backup is complete.
Now go back to your WordPress Admin.

Choose Plugins -> Add New

Click on Plugins -> Add New

WordPress HTTPS Add new plugin step 2

 

 

 

Now type Search and Replace in the keyword fields. Choose the plugin from “Inpsyde GmbH”.

WordPress HTTPS use search and replace

 

 

 

Install and Activate the plugin as usual.

Now click Tools -> Search & Replace

 

Now, if you want to be really safe, click Create SQL File and then Download SQL file.
This will give you a backup of the database just in case something goes wrong and can be restored very easily using the SQL Import tab.:

WordPress HTTPS use search and replace db backup

replace http with https

 

Now you click on the Search & Replace tab.

 

Enter http:// in the Search for field.

Enter https:// into the Replace with: field.

 

 

 

 

 

 

 

 

 

Check the box “Select all tables”

and Dry Run. (This is to test what will happen before anything actually happens.

 

 

 

Click Do Search & Replace.

 


The results of the search and replace dry run

 

Here is an example of the result:

Clicking on view details will show you what actually will be changed.

The last step is to UNCHECK “Dry RUN” and choose “Save changes to Database”.WordPress HTTPS use search and replace step 3

Click “Do Search & Replace” one more time and you are done.

Clear your WordPress Cache as well as browser cache to check the results.


If you are using Drupal on your website please read on…

The Drupal CMS team has fixed a highly critical security flaw that allows hackers to take over  site just by accessing a URL. We highly recommend that Drupal site owners immediately update your sites to Drupal 7.58 or Drupal 8.5.1, depending on the version you’re running. If you are unsure how to do so, please contact our Support team.

The Drupal team pre-announced the recent patches last week when it said “exploits might be developed within hours or days” after the disclosure.

This new Drupal Vulnerability allows an attacker to run any code he desires against the Drupal CMS’ core component, effectively taking over the site. The attacker doesn’t need to be registered or authenticated on the targeted site, and all the attacker needs to do is access the URL.

A nickname for this Drupal Vulnerability is “Drupalgeddon2”.

Drupal 6 is also affected. However, since Drupal was declared end of life (EOL) in 2016, NO patches will be issued by the Drupal Team.


HelpingHost.com is happy to announce a new partnership with CloudFlare, the web’s easiest performance and security solution. As a CloudFlare Certified Partner, we deliver their simple and free solution to help protect and accelerate your website. Once your website joins the CloudFlare community, it loads twice as fast and is protected from a range of online threats.

Getting started is super easy—you just need to log into your control panel and look for the CloudFlare icon. With two clicks, you can activate CloudFlare and your website will automatically be faster and safer around the world.

We are pleased to offer you the CloudFlare service for FREE. There is no commitment. Turning CloudFlare on and off takes two clicks of the mouse, so feel free to try it out. We think you’ll like it.

To learn more about CloudFlare, you can take a look at our CloudFlare Hosting page hereCloudFlare Hosting LOgo


With the recent Joomla exploit it became even more clear that we hsphere hosters have to find a way to get the latest PHP versions onto our servers.
We are using CloudLinux on every web server already to take advantage of its ability to keep customers resource usage in check.
CloudLinux also comes with alternative PHP packages (alt-php) including hardened PHP which are EOL php versions that the CloudLinux team keeps patching.


For several weeks we researched ways to use the alternative PHP packages as replacements for hsphere PHP.
Good news! We did it!
Before we go into detail on how this was accomplished, please keep in mind our hsphere web setup before any changes are made:

  • – Apache 2 worker mode
  • – FCGID active
  • – mod_hostinglimits active
  • – CloudLinux 5 with Hybrid Kernel (CL6 will work just as well)

Now on to how we accomplished the goal of replacing hsphere PHP with Cloudlinux PHP.
At first we tried to get a custom suexec from CL to replace the hsphere suexec. However, under hsphere, the pathnames to all PHP binaries are actually hardcoded into the suexec. So, a custom suexec with just adjusted parameters will NOT work.

Next, we decided to try to litterally replace the hsphere php binaries with cloudlinux binaries.
This turned out to work pefectly well even though sadly cagefs will not work within PHP scripts due to the missing custom suexec.

Here are the steps:

  • yum install cagefs lvemanager -y
  • yum groupinstall alt-php -y
  • yum install alt-php54-zend-guard-loader -y (only on CL5)
  • /usr/sbin/cagefsctl –init
  • Now copy the sample PHP ini files from one user to /etc. Reason is that under Hsphere, the suexec does not respect cagefs which means php is looking for the php.ini in /etc/cl.php..
    cp -r /var/cagefs/00/[SAMPLEUSER]/etc/cl.php.d /etc/
  • edit the global php ini file to your liking: /etc/cl.selector/global_php.ini. What you add here will be compiled into each global php.ini in the next step
  • /usr/sbin/cagefsctl –setup-cl-selector
  • The last step is to copy the CloudLinux php binaries over the old hsphere binaries.
    Reason this needs to be done this way is that the hsphere suexec containts the path to the php binaries hardcoded.cp -f /opt/alt/php44/usr/bin/php-cgi /hsphere/shared/php4/bin/php
    cp -f /opt/alt/php52/usr/bin/php-cgi /hsphere/shared/php5/bin/php
    cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php53/bin/php
    cp -f /opt/alt/php54/usr/bin/php-cgi /hsphere/shared/php54/bin/php
    cp -f /opt/alt/php55/usr/bin/php-cgi /hsphere/shared/php55/bin/php
    cp -f /opt/alt/php53/usr/bin/php-cgi /hsphere/shared/php-internal/bin/php
    (You need to use PHP 5.3 for internal PHP, otherwise the webshell will no longer work)
    rm -f /usr/bin/php
    rm -f /usr/local/bin/php
    ln -s /opt/alt/php55/usr/bin/php /usr/bin/php
    ln -s /opt/alt/php55/usr/bin/php /usr/local/bin/php

BTW, nothing stops you from for example doing a:
cp -f /opt/alt/php5.6/usr/bin/php-cgi /hsphere/shared/php4/bin/php

So, if nobody uses PHP 4.4 anymore on a server you convert it to PHP 5.6 this way, or if you are on CL6 you can use PHP 4.4 to be PHP 7.


A security flaw has been discovered in Joomla version 3.5.0 through 3.8.5.

It has been assigned [CVE-2018-8045].
The User notes list view is missing a type casting of a variable which can lead to an SQL injection.

This means that somebody can make changes or read out data from your Joomla database without permission.
It can be achieved by simply calling the User notes list view with specially crafted parameters.

The Joomla team considers the severity of the flaw as low.

Please login to your hosting control panel and use our Softaculous installer to update your Joomla.
If you are unsure, please contact your HelpingHost.com support team to help you out.


Simple Explanation of Meltdown and Spectre:

By now I’m sure you have heard about Meltdown and Spectre.

 

Meltdown exploit snippet They are names to describe exploits that take advantage of bugs in most modern processors.

In the Common Vulnerabilities and Exposures List the following code numbers were assigned:

 

Meltdown: [CVE-2017-5754]

Spectre: [CVE-2017-5753]

Any company that runs software on computers will have to apply patches to protect themselves and their customers.

The action HelpingHost.com took:

The race was on to patch these vulnerabilities. HelpingHostcom has patched all Servers against the recently discovered Meltdown and Spectre bugs on the same day as our Software vendors released the patches.

Spectre code piece


Many of you are probably wondering if you have to worry about the Heartbleed vulnerability if you are hosted with HelpingHost.com.

The short answer is NO.

Heartbleed is a recently found vulnerability in the so called “TLS heartbeat extension” of OpenSSL. A piece of software installed on most web servers.

This TLS extension however was only added to OpenSSL in Version 1.0.1 and newer which means that older versions of OpenSSL simply do not have this featrure.

The infrastructure currently in production here at HelpingHost.com is based on CentOS 5 and Redhat Enterprise Version 5.

These operating systems are using a secure and fully vendor patched OpenSSL version 0.9.8e.

Because of this our servers (your websites) are NOT affected by the Heartbleed vulnerability  (CVE-2014-0160).