Knowledge Base

Installing composer on a shared host

I just moved a site from GoDaddy to InMotion Hosting. As a part of the move, I did a cPanel backup, then had their support team do a restore on the new server. This saves some work, in that all cPanel settings (email accounts, FTP settings, etc.) are transferred. However, it can also bungle some things if you aren't careful or aware of them. I'm not sure this is a result of the cPanel backup and restore, but the version of composer on InMotion was 1.1.1, which at the time of this writing is pretty outdated (currently at 1.6.2.) I wasn't able to do an inplace upgrade, as it was installed in a g

PHP Memory Limit for Drush

I have a client with a very low-end GoDaddy account. While this is bad, especially for Drupal development, it is still usable. One area that I've struggled with, however, is getting Drush to work for larger tasks such as reverting Features or clearing cache. The problem I was running into was that GoDaddy provides the shared hosts with a maximum memory limit of 64M by default. This doesn't go very far in the Drupal world. There are plenty of articles on how to change your PHP memory limit for the webserver, but the gist of it is this: Go to your root (~/public_html) directory (either in the cP

Updating command line PHP on Hostmonster

I have a site hosted on Hostmonster, and for a long time, I never really did much via the command line. However, I pretty much use drush for everything these days, and as I'm getting ready to upgrade to Drupal 8, I was going to need to update my version of Drush on the server (it was still 4.5... in 2016.) When I tried to update it via composer, I realized composer wasn't installed. When I tried to install composer via curl, I found out that it requires at least PHP 5.3, and I had 5.2.17. I updated PHP through cPanel, which updates what your website has, but doesn't update what you can use on

Multiple Environments on a Shared Host

Environments Every good Drupal developer should be familiar with Dev, Staging, and Production environments. Dev is where you test your code to make sure it won't break anything, Staging is where content is added (so users won't see a site being built before their eyes,) and Production is the live-to-the-world site. In theory, you could get by with just two environments, especially once the site is live, but it never hurts to have extra test cases before pushing code live. High-end hosts, such as Acquia and Pantheon , have a pretty slick online interface for moving your code from Dev to Staging

Block your test site from searchbots

Letting searchbots crawl through your site is how you can get your content to show up in search engine results. However, there are times when doing so could have an adverse effect on your results. If your Dev or Staging site has a lot of test content on it, then the searchbots are going to be lumping that in with your important content (and you probably don't want visitors to see your pages of Lorem Ipsum text.) If you've synced your database from the production site to your staging site, then the searchbot might flag the content as being duplicate, which can decrease your SEO score. The best

Drush Alias files for shared hosts

Once you have Drush up and running on your host , you will want to create an aliases file so you can use it properly and easily. An aliases file simply defines an alias for the site to which you want to connect, so Drush knows the paths and database settings necessary to bootstrap the site. Creating the aliases file The first thing to do is to create the aliases file or copy and edit and existing file on your local environment. There are multiple places where the file could be located so Drush can find it (these are listed in the default aliases.drushrc.php file): In any path set in $options['

Configure Drush on A Small Orange

If you use Drupal you need to use Drush. For things that are in the Drupal UI, Drush is often more efficient (you don't need to wait for page loads just so you can clear cache or enable modules, for instance.) However, what if you're a careless admin who forgot their password, or you need to login as a different user? Drush will generate one-time login links for you. Site down? Drush might be able to help you get it back. Point is, once you've gotten accustomed to Drush, you will never want to be without it! </soapbox> To install Drush on ASO, SSH into your account, and go to the home director

Settings.php For Multiple Environments

Note that placing settings.php files in source control is risky (your database settings are in there!) You might want to upload them manually via SFTP or other method rather than storing in your repository. This is a follow-up article on the Knowledge Base article about using GIT on A Small Orange . At this point, you should be able to get your code to the different repositories. However, in order for this to really work, you will need a separate database for each environment, as you don't want to alter the production database with test content. Creating a separate database for each environmen

Using GIT on A Small Orange

Using GIT for revision control is a great way to manage your website's code. It allows a team of developers to commit code, and if you need to go back through the history of a file, it is very easy to do so. It can sometimes be a challenge to get started with GIT when using a shared hosting plan, especially if the host doesn't already have GIT installed for you. For this article, I am going to describe how to use it on a small plan from A Small Orange ( http://asmallorange.com ,) and fortunately, GIT is already included. What you'll need To get started, you will need SSH access into your accou