This article will guide you through the process of deploy your Laravel based application or website to the Conetix hosting environment using Plesk.

This process can be used also when migrating your Laravel site to Conetix.

Prerequisites

This article assumes you’re using a Git based repository to host your Laravel application and that you have access to make changes to that repository.

Instructions

1. Login into Plesk via the Conetix Control Panel.
2. For the website you wish to deploy the Laravel app to, choose Get Started:
   
3. Choose Laravel:
   
4. Choose Install from remote repository:
   
5. Enter the Git repository URL:
   
6. Ensure the public key has been configured within your hosted Git environment. We have guidance on the following services:
   • GitHub
   • GitLab
   • BitBucket
     (Other services should be compatible and you’ll need to consult their help documentation)
7. Click Install to start the process:
   
8. This will begin the deployment process:
   
9. After a few minutes, the deployment should be complete and you should see your application within the Plesk Laravel Toolkit:
   

On occasion, Conetix may request you send us a snapshot of your browser traffic. This is called a HAR export which is short for HTTP Archive. This is a file format used for tracking information between a web browser and a website, and for identifying performance issues.

Instructions

1. Open Google Chrome.
   
2. Navigate to the page where the issue is occurring.
   
3. Click the Vertical ellipsis button in the top right of the Chrome window ()
   
4. Select More Tools > Developer Tools.
   
5. Click the Network tab.
   
6. Click the Record button in the upper left corner of the tab:
   
   
7. Ensure the record button is red, if it is grey you can click it once to start recording your session
   
8. Check the box Preserve log:
   
9. Click the Clear button:
   
10. Reproduce the issue that you are experiencing, you should perform the exact steps to recreate the issue.
11. Once you have reproduced the issue, click the Export HAR button to download the file:
    
12. Save the file to your desktop so it can be easily located:
    
13. Send the .HAR file to Conetix as an attachment to your ongoing support ticket.

If you run or manage a web application that uses a database in some way, you may find some SQL queries run slower than expected. This can be especially evident when your dataset grows or a speed comparison is run between a development copy of the database (with less rows) and a production database.

Generally, this is only an issue where there has been custom development or a plugin or extension added to an existing Content Management System (CMS) which may not be optimised.

Conetix runs highly optimised infrastructure, which includes the latest Xeon Gold SP processors, high speed RAM and the latest enterprise grade NVMe storage to provide a highly performant environment for your application and database. However, no amount of hardware nor server level optimisation can fix poorly designed queries or data schemas.

Diagnosing the issue

Contact your developer

In nearly every instance, the first point of call for slow database queries should be your developer. You can pass this guide onto them, however they should already be aware of the issues and solutions raised in this article.

Basic diagnostics

Depending on the database type, each database engine generally has an EXPLAIN function which will detail how the SQL query is going to be executed.

This will provide an explanation or execution plan for your query and let you know how it’s accessing the tables. For MariaDB, you can run this via phpMyAdmin and for MSSQL based systems you may need SQL Server Management Studio to perform the execution plan.

In many instances, the use of temporary tables can be an indication that your database schema is lacking database indexing.

Enabling database indexing

When queries span multiple tables, they need a way to reference the data between the two. For example, if you have a table with customer information and a table with order information, there needs to be a JOIN between the two tables formed to select the correct information.

If you don’t have any indexing, the database must sequentially search every row until it finds the correct one every time you run a query.

The larger your dataset grows and the more complex the query, the slower therefore the query will become.

A database index is one way to help significantly speed up these queries, as it will create a rapid lookup per table based on the particular key used (eg the customer ID). This is like having an indexing system used by your local library, where instead of searching through every book, indexes allow you to quickly select the right row and shelf to locate it.

As an example of the performance difference, this was a production MSSQL query which was taking up to 20 seconds to complete without indexing an an average of 40ms to complete after indexing was setup:

We’ve included links to creating database indexes for both MSSQL and MySQL/MariaDB below.

Use a framework

The days of hand written database queries and database structures have been made mostly obsolescent by modern development frameworks, which incorporate object-relational mapping (ORM) interfaces and/or higher level query abstraction and optimisation.

While some of these used to be less efficient than hand written queries, the majority now have had significant optimisation and can in many instances outperform hand written queries due to this. Some example frameworks are:

• Eloquent (PHP / Laravel)
• Doctrine (PHP)
• Entity Framework (.NET)
• Dapper (.NET)
• SQLAlchemy (Python)

These frameworks with their database abstraction layers will take care of query structure, schema migration and database indexing on your behalf. This leads to greater time savings, better security and greater database optimisation.

While Git is an incredibly powerful tool for source code tracking and version control, if you accidentally upload the repository to your website then you may expose information which should be protected.

Tools such as GitJacker and GitHacker can automatically crawl a .git directory (eg https://<yourwebsite.com>/.git) then guess most of the filenames to rebuild the entire Git repository.

Repositories for platforms such as WordPress where you have your wp-config.php within the Git repository, a malicious actor will therefore have a copy and therefore access to your database credentials as well as other other sensitive information.

Prevention

Use Plesk for Git based deployment

Conetix uses Plesk because of the advanced features designed to make your life easier. One of these is automatic deployment via Git. This means, when you commit to your main branch, it can push the changes automatically to your website or web app. We have guides on the setup available:

• Automatic Deployments via GitHub
• Automatic Deployments via GitLab
• Automatic Deployments via BitBucket

Ensure the .git directory isn’t deployed

When using an existing Continuous Integration (CI) tool to deploy or simply transferring via FTP, the next best option is to ensure the .git directory isn’t uploaded at all.

As the most popular FTP client, FileZilla has a inbuilt filter functions which block .git automatically:

Users of CI tools for deployment will need to consult the support documentation of the various tools to check how a filter is implemented.

Explicitly block access to .git

As a last resort, if you can’t stop the .git directory being uploaded then the only alternative is to block access. To do this, you’ll need to edit your .htaccess file (or create if one doesn’t exist) and add the following:

# Block access to the .git directory and .gitignore etc
RewriteEngine on
RewriteRule ^(.*/)?\.git+ - [F,L]

Where a site has been compromised, we have seen odd traffic from web crawlers indexing sites continue. Many of these can included weird URL’s which have a number of GET variables in the URL. An example of this would be:

"GET /test/?s=phim%20anime%202d%E3%80%90<BADURL>%E3%80%91Watch%20Free HTTP/1.0"

Especially where this generates a WordPress 404, this can lead to high resource usage for your site and even interfere with real users being able to access your site. Ideally, you should remove / block this direct within each bot’s control area such as the Google Search Console and only use this method as a fallback.

Instructions

1. Via the Plesk File Manager, open the .htaccess file.
2. Add the following, customising to suit your specific requirement:
   

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} BLEXBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} PetalBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Adsbot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} Googlebot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} SemrushBot [NC,OR]
RewriteCond %{HTTP_USER_AGENT} bingbot [NC]
RewriteCond %{QUERY_STRING} s=.* [NC]
RewriteRule test/ - [F,L]
</IfModule>

In this example, we’re targeting all URL’s with /test and the GET variables s=. This would send a 403 to any request which matches, such as the one in the introduction. While this won’t fix the issue with the content in search engine results which will also be indexed (eg, in Google), it should at least remove the resource overhead so that your site is accessible again.

When development changes are being published, Wordfence will sometimes not recognise the source of the post. Seeing the post attempt from an “unknown” source (Plugin or User) Wordfence will then attempt to block the attempt. This can occur for a number of varying reasons, actions performed by a new user, posts coming from a niche plugin or theme or the users IP is on a blacklist database.

Instructions

You are posting new content to your site, when you hit publish/update, you receive the following warning from Wordfence:

1. If you are the user making the post, click on “Add action to allowlist”

Result

Adding the action to the allowlist means that the URL/parameters will be added to Wordfence’s whitelisted table and will not be tested by the firewall. They are typically added while the firewall is in Learning Mode or by an admin who identifies a particular action/request is a false positive.

This article covers how to set custom HTTP Headers for your website, using a .htaccess file located in your website’s file directory.

HTTP Headers let you supply additional info in HTTP requests – this could for example be used to fine-tune how your site loads, or to help protect your site with an additional layer of security.

Instructions

1. Log into Plesk either via your Conetix Account, or directly into your VPS (if you have one).
2. Navigate to the File Manager under the website you’d like to configure HTTP Headers for.

3. Navigate to the folder that contains your website’s files;
   • If you only have one website located within your hosting plan, it will be located within the httpdocs folder.
   • If you have more than one website within your hosting plan, choose the folder that has the name of the website. If no such folder exists for the site, it will therefore likely be within the httpdocs folder.

4. Click on the .htaccess file located within the site’s files, to open and edit it.
   • If the file doesn’t already exist, click the blue Plus button, and choose Create File;
     
   • Name it “.htaccess” (without the quotes), then click OK.
     
   • Then, click on the newly created .htaccess file to start editing it.
     
5. Scroll to the bottom of the .htaccess file’s code, and add a starting line of;
   # HTTP Headers
   This is simply used to help you (or your developer) identify where your HTTP Headers have been set.
6. Add the opening line of;
   <IfModule mod_headers.c>
   Your HTTP Headers will then be located under this line.
7. Add your HTTP Headers as required – Plesk has a list of example headers that you may wish to consider looking at.
8. Once you have added all of the required lines for each of your HTTP Headers, add the following line below them;
   </IfModule>

9. Click Save to save your changes.

10. Open your website in a new tab or window to confirm that the new HTTP Headers are working as expected.

A common occurrence when when working on large sites is to spin up a copy of the site as a staging or development copy of the live website to make changes to.

While this is a great way to avoid issues with breaking the main site, many forget about the copy of the site after the task is complete. As most of the security patching only occurs on the live sites, these forgotten clones therefore mean you have a large security risk just waiting to happen.

As the cloning of a website can be as quick as 4 clicks, Conetix recommends that you delete the staging site as soon as you’ve completed the work and synchronised the changes with the live website.

Alternatively, if you want to keep a copy of the development / staging site, you can disable this site within Plesk so that the files can’t be accessed externally. This allows you to quickly enable the site again as required to complete work and disable once you’re done.

Buddy.works is a comprehensive Continuous Integration / Continuous Deployment (CI/CD) platform which allows you to automate workflows to get your code into production sooner and in a more reliable fashion.

While Plesk has basic Git integration, Buddy.works allows for a number of intermediate steps (such as image compression and minification) to be actioned at the same time. This guide will show you how to configure a pipeline which is compatible with Plesk.

Instructions

1. Within Buddy.works, select your existing project or create a new one.
2. Add a new Pipeline:
   
3. Give your new pipeline a name and select “On push” if you want automated deployments:
   
4. Search for “FTP” within the actions and select FTPS (not SFTP):
   
5. Add in your FTP details for your existing Plesk subscription, then click Browse:
   
6. Select the path of where you wish the files to be deployed to. For example, for a WordPress theme you’ll want to select httpdocs/wp-content/themes/<theme-name>:
   
7. Save the configuration. You can now test with a manual run:
   
   Once completed, this should provide a confirmation that the pipeline completed without error:
   
8. To ensure the pipeline is automatically deployed, select Webhook URL from the right hand side:
   
9. Copy the webhook URL into your chosen Git repository as a hook:
   
10. Integration between Buddy.works and Plesk has now been configured.

Recent changes to both Google Chrome and Mozilla Firefox (in early 2017) have started to push secure (HTTPS) based connections by default instead of optional. If your site is already HTTPS based, this could also indicate an issue either with the HTTPS certificate or server configuration. Google Chrome now has the following three status messages and icons about the security of your website: 

This article shows how you can help determine the cause of the issue.

NOTE: As of Chrome 68's release in July 2018 all sites serving content insecurely (not HTTPS) will show as Not Secure in Chrome.

Instructions

1. Firstly, if you only see the "Not secure" link only on pages where you have a login or form, you need to update your website to use an SSL certificate. For example:
   
   Google Chrome and Mozilla Firefox will now flag any site where you're passing details in plain text (unencrypted) as this means they could potentially be intercepted and used. Please contact your web host to determine the best way of installing an SSL certificate for your site.
2. If you have an SSL certificate loaded for your site and accessing it via HTTPS, you may still see an error message, like this one below: 
   
3. To determine why this is the case, open the Chome Developer Tools (F12 on a Windows / Linux PC, Ctrl + Opt + I for macOS) and click on the Security tab. You should see something similar to the following: 
   
   This is indicating issues with the certificate. In this example, the certificate had been generated with an older SHA-1 hashing algorithm. We have a further article explaining this in detail here. Essentially, you need a new SSL certificate generated and the best way to find out how is to contact your hosting provider.

   You may also see errors in regards to either an expired certificate or the "Server Connection" shows issues with the configuration. Again, both of these errors you should contact your hosting provider in regards to a fix or purchasing a new certificate.

4. Lastly, you may also see errors in regards to Mixed Content. These are a web development issue to correct and we have a full guide on how to find the exact errors here.

If you are a Conetix customer and need any further assistance with the above, please don't hesitate to contact our support team and we'll be able to provide you with further information.