1. Home
    2.  » Category: "Web Hosting Tips"

Web Hosting Tips and Tricks.

Here we post articles to help you running your website most optimal and fast. 

How to get your WordPress ready for https

Last updated Jun 14, 2020 at 11:36AM | Published on May 22, 2018 | Web Hosting News, WordPress Tips

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://…

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.

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 2Follow the steps until the backup is complete.
Now go back to your WordPress Admin.

Next, add the Search and Replace Plugin

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.

Securing and updating HSphere PHP using CloudLinux

Last updated Jun 14, 2020 at 11:36AM | Published on Mar 25, 2018 | Web Hosting Tips

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.

Using the PHP Form Builder Class (PFBC) within your own Joomla Component.

Last updated Jun 14, 2020 at 11:36AM | Published on Mar 13, 2018 | Joomla Tips, Web Hosting Tips

Why?

I was in the need of professional forms for a Joomla component I’m currently writing. With “professional” I mean the forms have to look professional and also need to be validated in a professional manner. I first went through a lot of Javascript/CSS solutions. However, in the back of my mind I thought I still have to validate all input on the Server level (Within the Joomla component itself) Finally I found an actively maintained Forms Library that after some testing worked great within any Joomla Component.

Here are some basic notes on how I accomplished this:

I’m using a file called loader.php located in the library path in my component Directory. I call it from my main controller file like this:

require_once(JPATH_ROOT.DS.'components'.DS.'com_component'.DS.'library'.DS.'loader.php');

in my loader PHP I have this line:

JLoader::register('Form', JPATH_COMPONENT.'/3rdparty/PFBC/Form.php');

As you can see I just copied the PFBC folder into a folder called 3rdparty within my Joomla component folder. Now you can use PFBC anywhere in your component by creating the object like this and add a field for example:

$form = new Form("testing", 300) ;
$form->addElement(new Element_Textbox("My Textbox:", "MyTextbox"));
$form->addElement(new Element_Button);

Assign it to the View as usual:

Joomla Open Source logo

$this->assignRef('myform', $form);

And render it in the tmpl file:

echo $this->myform->render();

PHP Modes under Apache explained

Last updated Jun 14, 2020 at 11:36AM | Published on Mar 25, 2015 | Web Hosting Tips

Today we will talk  a bit about the different modes in which the PHP Engine can run under the Apache web server and what the differences are. The two modes available are mod_php and CGI.

  • PHP running under mod_php means the PHP engine is activated and configured only one time exactly when you start apache. The biggest advantage of this mode is that PHP runs very fast since it can take advantage of caching and does not have to perform certain tasks every time a PHP script is being executed. One of those tasks is for example loading the configuration. This is also one of the big dis-advantages mod_php has. To make any configuration change, PHP or actually Apache needs to be restarted. Another negative for mod_php is the fact that is executed under the user under which Apache runs. This creates various permission issues especially for files created by the PHP script.
  • PHP running in CGI mode means the PHP Engine is called whenever Apache detects a php script needs to be parsed. It has th advantage that configuration changes can take effect immediately but it also makes the script execution a lot slower since the Engine has to read its configuration on each and every php files that needs to be executed. In addition, it is much harder to take advantage of memory caching since every call to a PHP script creates a whole new environment. So basically a script you are executing multiple times will need to be loaded into memory from the harddisk every time. The biggest advantage of running PHP in CGI mode is the fact that it is executed under the FTP user account it belongs to. It creates a lot less issues with writing files via PHP Script.

With HelpingHost.com you can switch the mode in which PHP runs on each of your websites independently. Simply login to your hosting control panel and edit the Web Service settings of the domain you are working on. Just remember, it can take up to 20 minutes after you hit “Apply Changes” until the web server picks up your changes.

Update:

You know have the option to choose the FastCGI mode to run PHP.

This mode combines advantages of both, mod_php and CGI mode.
Basically it starts PHP one time on the first request of a PHP script and keeps running for the next several requests. This will dramatically speed up the speed of your PHP scripts.

As stated before, you can just switch your website from within the hosting control panel to use PHP 5.3, 5.4 and 5.5 in FastCGI mode.

Update 2018:

We now have PHP 5.6, 7.0, 7.1 and PHP 7.2 available.
In addition a new PHP mode where PHP runs under mod_lsapi is now available.

This new mod_lsapi is based on the LightSpeed API. It is ultra fast. Test it out!

How to convert a IIS SSL certificate and Apache private Key into a PFX Certificate

Last updated Jun 14, 2020 at 11:36AM | Published on Jan 28, 2015 | Web Hosting Tips

How to convert a IIS SSL certificate and Apache private Key into a PFX Certificate. So, you are in the unlikely situation of have an OpenSSL private key and a IIS PCB7 Certificate from a certificate Authority. You would like to install these two in IIS. Of course after an hour of trying to figure it out you will notice that it simply can not be done. You need to perform some conversions to turn the .cer and .key into an .pfx file. These are the steps:

  • First convert the issued certificate from the CA (its in the format of P7B mostly ending in .cer) into a pem file.
openssl pkcs7 -print_certs -in domainname.cer -out domainname.pem
  • Next, convert the pem certificate and the private key into the PFX cert.
openssl pkcs12 -export -out domainname.pfx -inkey private.key -in domainname.pem
  • The resulting domainname.pfx file can now be imported via the certificate MMC snap-in (Local Computer Account).
  • Once imported, just open the Website properties -> Directory Security Tab -> Server Certificate -> Assign an existing certificate.
  • Voila, you have just created and installed a pfx certificate from an PEM private Key and a P7B Certificate.

One last tip, if you ever have odd issues with a site not responding with an SSL certificate installed. Download and install Microsofts SSLDiag tool. It works great!

How to call a custom html module within a Joomla component

Last updated Jun 14, 2020 at 11:36AM | Published on Jan 15, 2015 | Joomla Tips, Web Hosting Tips

Today I needed to render a Custom HTML module within a Joomla Component I’m currently writing.
After some research and testing this seems to be working great for me:
 $mod = &JModuleHelper::getModule('custom', 'Custom HTML'); echo JModuleHelper::renderModule($mod);

I have this piece of code in my default.php file within my views/default/tmpl/ folder. The ‘custom’ refers to the module mod_custom and ‘Custom HTML’ specifies which of the mod_custom modules to call.

Lets say you have a Custom HTML module with the title MODULEA and one with the title MODULEB then you can call and render them this way:
    
$mod = &JModuleHelper::getModule('custom', 'MODULEA');
echo JModuleHelper::renderModule($mod);
$mod = &JModuleHelper::getModule('custom', 'MODULEB');
echo JModuleHelper::renderModule($mod);
 
A couple of important notes:
  • At the time of writing I’m using Joomla 1.7
  • The modules HAS to be published.
  • It needs to be assigned to the pages/menus you want it to display.