Trello coloured lists for Tampermonkey updated to v4.x

Coloured lists make identifying their purpose quicker at a glance
Coloured lists makes identifying their purpose quicker at a glance

This evening I updated a script I first wrote back in March 2014. I wrote about it on the old University of St Andrews web team blog.

The script, which runs in the browser using an add-on such as Tampermonkey, lets you define Trello list titles to search for, and then apply a background colour to it.

Continue reading Trello coloured lists for Tampermonkey updated to v4.x

Bulk install packages in Sublime Text

A couple of weeks ago I was setting up a new laptop and kept putting off installing Sublime Text (my code editor of choice) because I knew that it would also involve about fifteen minutes patiently working through my curated list of packages (add-ons / plugins), installing each one by one.

There’s got to be a simpler way, I suddenly thought. Sublime Text saves me so much time doing other stuff automatically, surely they’ve thought about this too.

I was right.

In fact, front-end developer extraordinaire Paul Irish asked this very question back in 2012.

How do it it

So, here is how to do it:

  1. Install Sublime Text (2 or 3).
  2. Install Package Control.
  3. Create a JSON file listing the "installed_packages" you want (see below) and save it to Packages/User/Package Control.sublime-settings.
  4. Restart Sublime Text and allow it to pick up and install the new packages.

Just be aware of any packages that need dependences that Sublime Text cannot install, for example Git or Zeal (offline documentation browser).

Save locations

You can easily find the save location by going to Preferences > Browse Packages.

On Windows the save location is:
C:\Users\[YOUR USERNAME]\AppData\Roaming\Sublime Text 3\Packages\User

Package Control.sublime-settings

This is my installed packages list from work and home; I keep a copy in Dropbox so that I can keep the two in sync.

The names listed are exactly as they are listed in the Package Control: List Packages list.

{
    "installed_packages": [
        "Alignment",
        "AutoFileName",
        "Autoprefixer",
        "Bootstrap 3 Snippets",
        "BracketHighlighter",
        "Color Highlighter",
        "CSS Color Converter",
        "CSScomb",
        "DevDocs",
        "Emmet",
        "GitGutter",
        "Handlebars",
        "jQuery",
        "JSHint Gutter",
        "Markdown Preview",
        "MarkdownEditing",
        "MarkdownTOC",
        "Package Control",
        "Placeholders",
        "Sass",
        "Search WordPress Codex or QueryPosts",
        "SideBarEnhancements",
        "Status Bar File Size",
        "SyncedSideBar",
        "Tag",
        "Theme - Minimal",
        "TodoReview",
        "Tomorrow Color Schemes",
        "View In Browser",
        "WordPress",
        "WordPress Developer Resources",
        "WordPress Generate Salts",
        "Zeal"
    ]
}

 

Needless to say, doing that made installing Sublime Text so much easier and quicker.

I will try to keep this list updated, as much for my own benefit as any one else’s.

GitHub repository

I have stored my most up-to-date settings in a GitHub repository: sublime-text-settings.

Changing the Divi projects custom post type to anything you want

Now fixed for Divi 2.5

Clone this project on GitHub.

I’m currently building a website for a friend of Jane, using the Divi theme from Elegant Themes. The website is for a holiday property letting company. This post explains how I changed the built-in Projects content type to Properties, and how you can change it to anything you want.

The problem

Divi is a great theme to use: it’s very flexible, it’s responsive (so it works equally well on smartphones as well as huge desktop monitors), and it has the easiest, drag-and-drop editor that I’ve ever used for WordPress.

Divi comes with a built in content type called Projects; WordPress calls them ‘custom post types’. I use this content type on my own website to list the various projects that I’ve been involved in over the years.

As you can see from the WordPress admin menu ‘Projects’ appears on the list beneath Posts, Media, Pages, and Comments:

WordPress menu with Divi installed shows Projects
WordPress menu with Divi installed

Divi also ships with a number of attractive ways to display your projects using its Portfolio and Filtered Portfolio modules. You can even display these full-width or as a grid, such as this:

Demo of Divi's Filtered Portfolio module displayed as a grid.
Demo of Divi’s Filtered Portfolio module displayed as a grid.

These are exactly the features that I’d like to use on the property letting website:

  • Keep properties separate from pages and posts, using a custom post type.
  • Display all properties in a grid.
  • Allow users to filter properties based on the categories that are assigned to them.

So, I want all the features of Divi’s built-in Projects custom post type, but I don’t want them to be called Projects. I want them to be called Properties.

Use a child theme

First, I strongly recommend that you use a child theme when customising Divi (or indeed any other WordPress theme). A child theme inherits the functionality and styling of another theme, called the parent theme, and allows you to make local customisations to it which will not be overwritten when the theme updates.

Elegant Themes have a useful walkthrough on how to create a child theme, and why you should be using one.

The WordPress Codex also has useful information about child themes.

How to do it

This very useful post on the Elegant Tweaks blog: “Change Divi Projects URL-permalink” got me started, and about 95% of the way.

I copied the code, added it to the functions.php file in my child theme, and set about editing it.

remove_action / add_action

In a nutshell the code from Elegant Tweaks does two things:

  1. It defines a new function — called child_et_pb_register_posttypes() — that will redefine the characteristics of the Projects content type.
  2. It removes the default Projects custom post type contained in Divi, and replaces it with our one in the child theme.

This last point, I believe, is simply to be tidy: rather than clumsily overwriting the existing ‘project’ custom post type it gracefully removes the old one, and creates a redefined version in its place.

Labels

In that Elegant Themes post the author was only concerned with changing the URL from /projects/ to /photos/. So in his example, the names used in the WordPress admin screens still referred to projects: Edit Project, Add New Project, etc. But I want to change these too.

In the code for a custom post type these are referred to as ‘labels’ and are defined in the $labels array. This is what my code looks like now:

<?php function child_et_pb_register_posttypes() { $labels = array( 'add_new' => __( 'Add New', 'Divi' ),
    'add_new_item' => __( 'Add New Property', 'Divi' ),
    'all_items' => __( 'All Properties', 'Divi' ),
    'edit_item' => __( 'Edit Property', 'Divi' ),
    'menu_name' => __( 'Properties', 'Divi' ),
    'name' => __( 'Properties', 'Divi' ),
    'new_item' => __( 'New Property', 'Divi' ),
    'not_found' => __( 'Nothing found', 'Divi' ),
    'not_found_in_trash' => __( 'Nothing found in Trash', 'Divi' ),
    'parent_item_colon' => '',
    'search_items' => __( 'Search Properties', 'Divi' ),
    'singular_name' => __( 'Property', 'Divi' ),
    'view_item' => __( 'View Property', 'Divi' ),
);

 

As you can see, something I find useful is to list the elements alphabetically. Personally, I find it easier to work this way; your mileage may vary.

Obviously, if you are customising this for your own requirements simply edit this to reflect your needs.

Custom post type options

Next, we define the arguments to be passed to the register_post_type function. These define not only how the custom post type is used but also how it is displayed in the WordPress admin menu: where it sits and what icon it uses.

Slug

The most important option here, for our purpose of customising it, is the 'slug' key. You must set its value (in single quotes) to whatever you need it to be. In my case 'slug' => 'property'. I’ve highlighted this in the snippet below.

Just make sure you don’t set the slug to the same name as an existing page.

Menu icon and position

One useful new addition to the code provided by Elegant Tweaks are the options to set the menu icon and where it sits on the menu.

As these are properties I decided to use the home dashicon.

House icon
dashicons-admin-home

I also decided to move it up a bit, from beneath Comments to immediately below Posts. WordPress uses numbers to specify where custom post types should sit, e.g.

  • 5 — below Posts (this is where I want it to appear)
  • 10 — below Media
  • 15 — below Links
  • 20 — below Pages
  • 25 — below Comments

A full list can be found in the WordPress Codex.

So, here is the code I now have; I’ve highlighed these new menu options plus the ‘slug’ (how it will appear in the URL):

$args = array(
    'can_export' => true,
    'capability_type' => 'post',
    'has_archive' => true,
    'hierarchical' => false,
    'labels' => $labels,
    'menu_icon' => 'dashicons-admin-home',
    'menu_position' => 5,
    'public' => true,
    'publicly_queryable' => true,
    'query_var' => true,
    'show_in_nav_menus' => true,
    'show_ui' => true,
    'rewrite' => apply_filters(
    'et_project_posttype_rewrite_args', array(
    'feeds' => true,
    'slug' => 'property',
    'with_front' => false,
)),
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'comments', 'revisions', 'custom-fields' ),
);

 

Register the post type

The next line now does the grunt work and registers this custom post type with WordPress.

register_post_type( 'project', apply_filters(
    'et_project_posttype_args', $args )
);

This tells WordPress to apply all of these options to the ‘project’ custom post type.

Because we are redefining this existing custom post type (by changing the URL, the menu labels, the menu icon and position) it means that everything else (the default project page layouts and portfolio modules) will work as expected without any further customization.

Categories and tags

The rest of the code I left untouched. This code defines the categories and tags to be used with the projects/properties custom post type.

How it looks now

Adding all the code (see below for the complete script) this is what my WordPress admin menu looks like:

Divi theme now with Properties instead of Projects
Divi theme now with Properties instead of Projects

That’s now working as I expect it. Job done.

Complete code

Here is the full code that I have in my child theme’s functions.php file:

<?php function child_et_pb_register_posttypes() { $labels = array( 'add_new' => __( 'Add New', 'Divi' ),
    'add_new_item' => __( 'Add New Property', 'Divi' ),
    'all_items' => __( 'All Properties', 'Divi' ),
    'edit_item' => __( 'Edit Property', 'Divi' ),
    'menu_name' => __( 'Properties', 'Divi' ),
    'name' => __( 'Properties', 'Divi' ),
    'new_item' => __( 'New Property', 'Divi' ),
    'not_found' => __( 'Nothing found', 'Divi' ),
    'not_found_in_trash' => __( 'Nothing found in Trash', 'Divi' ),
    'parent_item_colon' => '',
    'search_items' => __( 'Search Properties', 'Divi' ),
    'singular_name' => __( 'Property', 'Divi' ),
    'view_item' => __( 'View Property', 'Divi' ),
);

$args = array(
    'can_export' => true,
    'capability_type' => 'post',
    'has_archive' => true,
    'hierarchical' => false,
    'labels' => $labels,
    'menu_icon' => 'dashicons-admin-home',
    'menu_position' => 5,
    'public' => true,
    'publicly_queryable' => true,
    'query_var' => true,
    'show_in_nav_menus' => true,
    'show_ui' => true,
    'rewrite' => apply_filters( 'et_project_posttype_rewrite_args', array(
    'feeds' => true,
    'slug' => 'property',
    'with_front' => false,
)),
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'comments', 'revisions', 'custom-fields' ),
);

register_post_type( 'project', apply_filters( 'et_project_posttype_args', $args ) );

$labels = array(
    'name' => _x( 'Categories', 'Property category name', 'Divi' ),
    'singular_name' => _x( 'Category', 'Property category singular name', 'Divi' ),
    'search_items' => __( 'Search Categories', 'Divi' ),
    'all_items' => __( 'All Categories', 'Divi' ),
    'parent_item' => __( 'Parent Category', 'Divi' ),
    'parent_item_colon' => __( 'Parent Category:', 'Divi' ),
    'edit_item' => __( 'Edit Category', 'Divi' ),
    'update_item' => __( 'Update Category', 'Divi' ),
    'add_new_item' => __( 'Add New Category', 'Divi' ),
    'new_item_name' => __( 'New Category Name', 'Divi' ),
    'menu_name' => __( 'Categories', 'Divi' ),
);

register_taxonomy( 'project_category', array( 'project' ), array(
    'hierarchical' => true,
    'labels' => $labels,
    'show_ui' => true,
    'show_admin_column' => true,
    'query_var' => true,
) );

$labels = array(
    'name' => _x( 'Tags', 'Property Tag name', 'Divi' ),
    'singular_name' => _x( 'Tag', 'Property tag singular name', 'Divi' ),
    'search_items' => __( 'Search Tags', 'Divi' ),
    'all_items' => __( 'All Tags', 'Divi' ),
    'parent_item' => __( 'Parent Tag', 'Divi' ),
    'parent_item_colon' => __( 'Parent Tag:', 'Divi' ),
    'edit_item' => __( 'Edit Tag', 'Divi' ),
    'update_item' => __( 'Update Tag', 'Divi' ),
    'add_new_item' => __( 'Add New Tag', 'Divi' ),
    'new_item_name' => __( 'New Tag Name', 'Divi' ),
    'menu_name' => __( 'Tags', 'Divi' ),
);

register_taxonomy( 'project_tag', array( 'project' ), array(
    'hierarchical' => false,
    'labels' => $labels,
    'show_ui' => true,
    'show_admin_column' => true,
    'query_var' => true,
) );

$labels = array(
    'name' => _x( 'Layouts', 'Layout type general name', 'Divi' ),
    'singular_name' => _x( 'Layout', 'Layout type singular name', 'Divi' ),
    'add_new' => _x( 'Add New', 'Layout item', 'Divi' ),
    'add_new_item' => __( 'Add New Layout', 'Divi' ),
    'edit_item' => __( 'Edit Layout', 'Divi' ),
    'new_item' => __( 'New Layout', 'Divi' ),
    'all_items' => __( 'All Layouts', 'Divi' ),
    'view_item' => __( 'View Layout', 'Divi' ),
    'search_items' => __( 'Search Layouts', 'Divi' ),
    'not_found' => __( 'Nothing found', 'Divi' ),
    'not_found_in_trash' => __( 'Nothing found in Trash', 'Divi' ),
    'parent_item_colon' => '',
);

$args = array(
    'labels' => $labels,
    'public' => false,
    'can_export' => true,
    'query_var' => false,
    'has_archive' => false,
    'capability_type' => 'post',
    'hierarchical' => false,
    'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'comments', 'revisions', 'custom-fields' ),
);

register_post_type( 'et_pb_layout', apply_filters( 'et_pb_layout_args', $args ) );
}

function remove_et_pb_actions() {
    remove_action( 'init', 'et_pb_register_posttypes', 15 );
}

add_action( 'init', 'remove_et_pb_actions');
add_action( 'init', 'child_et_pb_register_posttypes', 20 );
?>

 

Final thoughts

Like many things on my blog I’m primarily putting it here for my own reference, but if you find it useful — or would like to suggest improvements or additional features — please leave a comment below.

Clone this project on GitHub.

Update: Remember to reset your permalinks

Friday 20 March 2015

I meant to say this in the article above. Sometimes WordPress gets a bit muddled when you play around with custom post types.

The way to fix this is to go to Settings > Permalinks > Save Changes.

That’s enough to flush the permalinks and your custom post type should work. I had to do that a couple of times while figuring out how to do this.

Update 2: Plugin discovery

Monday 20 April 2015

A few days ago I discovered this plugin: Divi Page Building for Custom Content Types.

This plugin allows you to use the Divi builder for Posts, or indeed any custom post type.

Update 3: Fix for Divi 2.5

Saturday 26 September 2015

I’ve now (finally) updated the code to make it work fully in Divi 2.5.

In the end it was quite simple: the add_action(...) and remove_action(...) priorities were wrong in my code. These tell WordPress in which order actions should be executed.

In my previous code I was instructing WordPress to unload the default Divi project custom post type before it had even been defined.

The default priority value is 10; I’d set mine to 0 and 1, respectively.

A huge thank you to Craig Campbell for his excellent Chrome Logger extension and ChromePHP class — two tools that greatly helped me work out what was going on.

Porting Monokai colour scheme to WeBuilder 2014

WeBuilder 2014 beta 7 with the new Monokai theme
WeBuilder 2014 beta 7 with the new Monokai theme

I have been using Blumentals WeBuilder now since March 2006—nearly seven years. It’s a solid web code editor and IDE (integrated development environment) but over the last couple of years it has been creaking at the seams a little. Some features were quite slow, others weren’t keeping up with the astonishing rate of change that the web standards have been going through of late.

So, over the last year or so the Blumentals team have been rebuilding the application from scratch, moving to a more up-to-date code base (they code it in Delphi, I believe) making it much faster and preparing the way for future enhancements and improvements. And boy! does it show. The new version is looking great. But I’ll get to that in a minute.

While they were working on what will soon be released as WeBuilder 2014 I found myself—as I do every six months or so—looking around at competing web IDEs to see what they were up to. I tried the usual candidates: Aptana, CodeLobster, Notepad++, NetBeans, Komodo Edit, etc. but nothing grabbed me until I stumbled on Sublime Text 2.

Wow! Sublime Text 2 is fast. Lightning fast. And it’s packed with features, and what it does’t have there is usually an add-on for it — which is most easily installed via the Sublime Package Control. But I digress.

I found myself using Sublime Text 2 more and more, and one of the things that I loved most about it was one of the in-built colour schemes: Monokai (based on a TextMate theme by Wimer Hazenberg). I had never used a dark theme before on an editor, but this one I really liked, and it was much easier on my eyes than the glaring white themes I’ve been using in the past.

Porting Monokai to WeBuilder

When WeBuilder 2014 was released in beta, owner and developer Karlis Blumentals invited users to create and submit colour schemes for WeBuilder (a new feature in 2014). So I set about porting the Monokai theme to WeBuilder.

Every code editor highlights its code syntax slightly differently. The code highlighting in Sublime Text is pretty simple, defining the same colours for a number of elements regardless of the language. So, for example, all strings are #e6db74 (yellow), all keywords are #f92672 (dark pink), etc.

WeBuilder’s colour schemes are more granular: if you want HTML elements within a PHP document to look different to HTML elements within an HTML or ASP document then you can in WeBuilder.

Also, the way that code elements are broken up into different syntax colours is slightly different between editors. It’s more-or-less impossible to port one theme to another editor exactly colour-for-colour, element-for-element. I decided, then, to try to keep within the spirit of the theme.

I relalised fairly quickly, therefore, that I needed to keep things as consistent as I could across all languages. So all strings would be yellow (#e6db74), all numbers (integer or floating) purple (#ae81ff), all HTML tags or language reserved words would be dark pink (#f92672), etc.

I created a spreadsheet to plan things out and document what I was doing.

Spreadsheet of many colours
Spreadsheet of many colours

That really helped. Especially when I did something wrong and reset my entire colour scheme to system defaults. Having documented it as I went along it only took me about 45 minutes to retype it. (A back-up would have been useful, huh!)

I’m really pleased with how they turned out, to be honest. And it would appear that Blumentals Software are too.

Available now

I passed the file to Blumentals last week and it’s already been incorporated into beta 7, which is currently available for download. (The beta versions are free while errors are being addressed, the final version will be available to purchase.)

To say thank you for what I did I received this kind email from @blumentals the other day:

@garethjms - you have earned a free upgrade to v2014 by porting Monokai scheme for our editor
@garethjms – you have earned a free upgrade to v2014 by porting Monokai scheme for our editor

How wonderfully generous of them. I was so delighted by their generosity. I simply did it because I really like the colour scheme, and I wanted in a small way to say thank you to Blumentals for all that they’ve given to the web building community over the last 6+ years.

More themes…

I’m starting work on porting another couple of themes now: Twilight (also used in Sublime Text 2) and Tomorrow, which is a lovely collection of dark and light themes.

Extending colborder in Blueprint CSS

Blueprint

For the last few months, when time has allowed, I’ve been working on a new CSS framework combining my favourite elements from Blueprint CSS framework and 960 Grid System but this week I ran into a problem.

I’m developing the adapted framework to use when I redesign my website later this year. When it’s completed I will also make it publicly available on my website to whoever wants to use it and adapt it.

This is what I want

On Friday night, while testing it, I spotted something about the original Blueprint framework that I hadn’t noticed before.

It was to do with the colborder rule. What if I want to do this:

12 columns of text

That is create two blocks of text, the first spanning six columns with two blank columns appended on the end, then a colborder (which as the name suggests is a border that span an entire column) and finally the second block of text which spans three columns.

Just to be clear, in this example I’m using an adapted Blueprint grid. The default grid uses 24 columns, but in this example I’m using 12 columns as fewer and wider columns make it easier to demonstrate what I’m talking about.

The code, I initially thought, would look like this:

span-6 append-2 colborder

Lorem ipsum dolor sit amet, …

span-3 last

Lorem ipsum dolor sit amet, …

My blank columns have disappeared

But testing this out, what this code actually gives you is this:

Six columns, a line, three columns

Hang on! Where are my two appended columns in the first block, the ones that should appear after the span-6 and before the colborder?

append-x and colborder don’t mix

To answer that I had to take a look at the Blueprint source code. As these three classes are to do with the layout grid these CSS rules span-6, append-2 and colborder are all defined in (my adapted) blueprint\src\grid.css:

.span-6 {
  width: 460px;
}
.append-2 {
  padding-right: 160px;
}
.colborder {
  padding-right: 49px;
  margin-right: 50px;
  border-right: 1px solid #eee;
}

So, in order:

  1. span-6 class is setting the width of the content to 460px.
  2. append-2 class is setting a padding-right of 160px.
  3. colborder is then overwriting padding-right with a width of 49px thereby making our appended two columns effectively disappear.

A new rule is required

I really wanted a solution that didn’t require any extra mark-up. Because I realised that this could be achieved with this code:

span-6 append-2

Lorem ipsum dolor sit amet, …

span-3 last

Lorem ipsum dolor sit amet, …

but that has an extra level of div tags.

After a little pondering, and a little scribbling on a scrap of paper, I realised that the solution lay in writing a new CSS rule that would prepend a colborder before the second block rather than append one after the first block.

In keeping with the append/prepend terminology of Blueprint I decided to call the new rule precolborder. The 12-columns version looks like this:

.precolborder {
  padding-left: 49px;
  margin-left: 29px;
  border-left: 1px solid #eee;
}

The 24-columns version (compatible with the default Blueprint CSS framework) looks like this:

/* Border with more whitespace on left hand side
    of a column, spans one column. */
.precolborder {
  padding-left: 24px;
  margin-left: 15px;
  border-left: 1px solid #eee;
}

and so our HTML now looks like this:

span-6 colborder

Lorem ipsum dolor sit amet, …

precolborder span-3 last

Lorem ipsum dolor sit amet, …

which looks like this on the rendered page:

Text spanning six columns, two blank columns, a border and then text spanning three columns

Which, if I’m not mistaken, is just what I wanted.

Feel free to use it if you like.