Front End Syntax Highlighting With ExpressionEngine

Yesterday I was asked via twitter how I do syntax highlighting on this blog. It's actually quite simple with a couple of addons. I was using a different addon, but it stopped working when I upgraded the site last year and then switched to using EE Syntax by Eric Lamb Which does the bulk of what is needed.

My blog channel has Three custom fields - a blog image (file), a copy field (wygwam) and code sample (matrix). The matrix field contains all code blocks and then using the approach outlined here I place the code blocks into the wygwam field. I chose to use MX Jumper, but the other options will work just fine - this could also be done using Stash.

Not sure why, but when I try to post the template code that renders the template code the page doesn't load. Have tried several workarounds, but no go. Can post any code except the code that displays code. Instead check this pastie.

Git Ignore and ExpressionEngine

I've been working on trying to keep my git repos lean and only include files that need to be uploaded to the repo. Currently my gitignore file ignores ExpressionEngine cache folders, folders needed by CE Image to create dynamic images i.e. /images/remote and images/made the _thumbs folder used by expressionEngine in every upload directory and the backup folder used by DevDemon. Additionally I just added **/installer_OLD which is left over by DevDemon when doing an EE Update.

Below is my current gitignore file. If you have any suggestions for improvements, let me know in the comments. You should rename system and/or move it above root as well.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
## ignore cache
system/expressionengine/cache/*
!system/expressionengine/cache/gitkeep
 
## ignore dynamic image folders needed by CE Image
images/remote/*
images/made/*
 
## ignore thumbs folders
**/_thumbs
 
## ignore site backup folder Updater
/site_backup/*
!/site_backup/gitkeep
 
## don't ignore any file named gitkeep
!**/gitkeep
 
## ignore installer_old after updates using DevDemon Updater
**/installer_OLD

DevDemon Updater - enable only on localhost

I use the FocusLab Master Config setup to have my sites work in multiple environments. This works really great, however I also use Dev Demon's Updater to update addons and EE. Now I don't want to accidentally use updater on the live or staging site. So how do we prevent this while still being able to use updater on localhost. It's actually really simple.

From the master config setup open config.master.php and add the following - note 'disable', really this could be anything as long as it's not one of the real options

1
$env_config['updater']['file_transfer_method'] = 'disable'; // local, ftp, sftp

Then open config.local.php and add the following - you may need to adjust your third_party system and themes paths. I keep mine in /addons/themes and /addons/system/

1
2
3
4
5
6
7
8
9
10
	// DEVDEMON Updater
 
	$env_config['updater']['file_transfer_method'] = 'local'; // local, ftp, sftp
 
	$env_config['updater']['path_map']['root'] = $base_path; // Document Root
	$env_config['updater']['path_map']['backup'] = $base_path . '/site_backup/'; // Backup Dir
	$env_config['updater']['path_map']['system'] = APPPATH . '../'; // System Dir
	$env_config['updater']['path_map']['system_third_party'] = $base_path . '/addons/system/'; // Third Party dir system dir
	$env_config['updater']['path_map']['themes'] = $base_path    . '/themes/'; // Themes dir
	$env_config['updater']['path_map']['themes_third_party'] = $base_path . '/addons/themes/'; // Third Party dir in themes dir

Now you can use Updater locally and prevent mistakes from happening on your staging or live environments.

Git Workflow - Reflections of a solo developer

I just started using Git in January of this year, I've known about version control and the benefits for several years, but never felt like it would benefit me as a solo developer. How wrong I was.

When I was working full time at an agency I more and more felt the need to be using version control, but I was unable to get everyone else on board due to a number of factors. These included people not wanting to improve or learn, One of the project managers liked to dabble in CSS and would tackle client requests live on the server rather than pass them on to me, and the time taken to learn would reduce time available for client projects.

In January, I decided that I needed to learn Git and took the plunge on a small personal project with which there would be no impact on anyone except myself if mistakes were made. Turns out there were no real issues. 

I've been thinking about writing this post for sometime now. Today on twitter Patrick Pohler mentioned the article he had written, in September, Git workflow: Manage code complexity, which inspired me to do the actual writing.

How I learned

To learn git I watched a series of YouTube videos which helped me solidify what I'd picked up from reading various articles.

After watching these videos I was still a little unsure how to get deployments to the live server working and the video tutorial that made it all clear was from Mijingo, which was 100% worth the $20, currently $15.:

Tools

The tools that I use are:

  • SourceTree (Git Gui) - opensource and cross platform. Dead easy to use.
  • Command Line - rarely as the gui means I don't need to remember various arcane commands. but sometimes it's necessary.
  • Bit Bucket - Free private repos (GitHub charges for private repos)
  • Dploy - deploy code to staging/production
  • Navicat - Remote access to database, db dumps, imports, data transfer and more. Way better than phpmyadmin
  • FocusLabLLC Master Config - Sets EE up for multiple environments

Workflow

My workflow is pretty simple. I've created a default install of ExpressionEngine default install, which as everything set up the way I like it, including, bootstrap, a simple index template, various EE settings, file directories, client member group,, database dump, javascript, and sass files all preconfigured.

  1. The first step is to create a project in Bitbucket and then clone that empty project to my local computer. 
  2. I then copy and past the default EE project, minus the .git folder into the empty project
  3. Open Navicat create a local db, import the default.sql dump
  4. open /config/ which has the FocusLab master config files and enter the config.local.php db credentials. Open config.env.php and enter the local/staging/production domains
  5. Login and confirm that everything is working correctly. If it is, then I do an initial commit and push everything to BitBucket
  6. Create a Development Branch and Start Building out the site.
  7. Once the site is ready for the client to preview and/or enter content, it's time to set up the staging environment.
    1. Create your db, and staging environment - I have a specific dev domain that I set up subdomains for all my clients.
    2. Enter these credentials into config/config.stage.php (FocusLab master config)
    3. Login to Dploy.io and connect a new Repository, enter the sftp/ssh credentials and set it to auto deploy from the Development branch. Deploy your repo.
    4. While the site is deploying open up Navicat, create a staging connection and test that it works. Assuming it does, close the connection, open your local database and do a "data transfer" to the staging server. This does a direct transfer to the staging server. No need to take a dump and then import.
    5. Check that staging site works.
  8. Now that we have a staging site, workflow changes a little. At this point any changes to the database need to be done on Staging and then moved to the local database either by a "data transfer" or by dumping/importing. Template code, is done locally and pushed to the staging server. Workflow has two different directions:
    • Database (channels, fields, entries etc)  Staging ---> Local
    • Code (HTML, JS, CSS, PHP etc )  Local --> Staging

Production!

Woo Hoo! the site is done, the client has entered all the data and has approved the site to go live. At this point you repeat step 7 above but set Deployment to be manual, i.e. you have to login to dploy.io and click a button to deploy the site. This ensure there's no accidental deployment of code that's not ready. The deployment branch should be set to Production or Master.

In the future when changes are made to the site, you would work on the Dev branch, push to staging, get client approval, Merge to Production and push to production.

Benefits to the Solo Developer

There are several benefits to the solo developer. No longer do you need to create duplicate tempates and make changes there or inform your client that there may be some wonkiness on the site while you do the work they've requested.  No more worrying about accidentally deleting/modifying something and then having no way to recover that file. All changes are version controlled allowing you to easily roll back your changes. 

Collaborating is easy. But wait, I"m a solo developer? Are you really a solo jack of all trades developer? Have you ever needed help on something either due to time constraints or perhaps your skillset doesn't cover something you need done. Git let's you share the repo with another developer, they can do their work and you can then see it before merging it into your staging/production branches. Brilliant.

I'm a solo developer, but I also do a fair amout of outsourcing work for other agencies. Either as the sole developer on the project or as part of a team. Using Git has opened up work opportunities for me that I would have otherwise not been able to do. I can clone an existing project from the agencies repo and make my changes and push back.

GIT-ifying an existing site

Converting an existing, ExpressionEngine, site to Git is super easy. Copy the site to your local server. Drop in the FocusLab Master config files, get the site working locally including upload directories. ONce that's set, set up a staging server and test. Finally set up the live server in Dploy, move existing site to a new folder (I call it DELETE_me_later) and deploy. There will be a few minutes of downtime, but you can easily schedule that at a time the client is comfortable. Now your previous projects are ready to use git workflow.

Your Voice Here
Leave a Comment