Posted on

Store Locator Plus Version 4.4.10 fixes the JavaScript error for Pages add-on


Store Locator Plus version 4.4.10

Recent updates to Store Locator Plus 4 have fixed a minor bug that effected the way the Pages add-on shortcode was rendering.

Another feature some of the users and/or administrators were inquiring about is the registry to participate in the Freemius survey feature. Yes, this is still the same author, developer and product. Even if you have registered, you can bypass the survey questions, or opt out. We understand some users are testing and deactivating the plugin and then reinstalling or re-activating SLP 4 to a newer version. You can still select the deactivate button at the bottom of the short survey without adding a reason but we sure would appreciate it if you could share any relevant information about how the plug-in is working for you, even if you are just testing. This allows Store Locator Plus developer to be proactive and improve the plug-in as well as get suggestions for new features.

The new Experience Add-on was published today. Read the latest info and news post and check out the short video.

Next up: The new Power add-on to be released later this month. Stay tuned. Subscriptions 520x520

Change Log for SLP

Posted on

Improving WordPress Plugin Development with Sass

SLP Sass Banner

If you’ve been following along since my WordCamp Atlanta trip this spring you know that I’ve been working on automating my WordPress plugin development and production process.    If you missed it you can read about it in the WordPress Workflow and WordPress Development Kit articles.   Since I needed to patch some basic CSS rules in my Store Locator Plus themes, these are plugin “sub-themes” that style the store locator interface within a page, I decided now was the time to leverage Sass.

Sass Is In The House

It was one of my first sessions at WordCamp Atlanta and I KNEW it was going to be part of my automation process.    Sass is a CSS pre-processor.   Store Locator Plus has its own “theme system”, a sort of plugin sub-theme that lives within the WordPress over-arching site theme.     The SLP themes allow users to tweak the CSS that renders the search form, map, and results of location searches to create in-page layouts that better fit within their WordPress theme layout.

Until this past release it was a very tedious process to update themes or create a new theme.    In the latest release there are some 30-odd SLP theme files.    The problem is that when I find an over-arching CSS issue, like the update to Google Maps images that rendered incorrectly on virtually EVERY WordPress Theme in existence, it was a HUGE PAIN.   I was literally editing 30 files and hoping my cut-and-paste job went well.   Yes, I could have done CSS include statements but that slows things down by making multiple server requests to fetch each included CSS file.   Since the store locator is the most-visited page on many retail sites performance cannot be a secondary consideration.   Sass deals with that issue for me and brings some other benefits with it.

There are PLENTY of articles that describe how to install Sass, so I am not going to get into those details here.  On CentOS it was a simple matter of doing a yum install of ruby and ruby gems and a few other things that are required for Sass to operate.  Google can help you here.

My Sass Lives Here…

For my current Sass setup I am letting NetBeans take care of the pre-compiling for me.    It has a quick setup that, once you have Sass and related ruby gems installed, will automatically regenerate the production css files for you whenever you edit a mixin, include, or base SCSS file.

NetBeans Sass Setup
NetBeans Sass Setup

I combine this with the fact that the assets directory is ignored by the WP Dev Kit publication and build tasks to create a simple production environment for my CSS files.   I store my SCSS files in the ./assets/stylesheets directory for my plugin.   I put any includes or mixin files in a ./assets/stylesheets/include subdirectory.     I configure NetBeans to process any SCSS changes and write out the production CSS files to the plugin /css directory.

The first thing I did was copy over a few of my .css files to the new stylesheets directory and changed the extension to .scss as I prepared to start building my Sass rules.


I then ripped out the repeated “image fix” rules that existed in EVERY .css file and created a new ./stylesheets/include/_map_fix.scss file.     This _map_fix file would now become part of EVERY css file that goes into production by adding the line @include ‘include/_map_fix” at the top of the SLP theme .scss files.    Why is this better?   In the past, when Google has made changes or WordPress has made changes, I had to edit 30+ files.  Now I can edit one file if a map image rule is changing that has to be propagated to all of the css files.   However, unlike standard CSS includes Sass will preprocess the includes and create a SINGLE CSS file.   That means the production server makes ONE file request instead of two.  It is faster.

SLP Map Fix Include
SLP Map Fix Include

As I reiterated this process I ended up with a half-dozen CSS rules that appear in MOST of my CSS files.    Since all of the rules do not appear in all of my plugin theme files I ended up with a half-dozen separate _this_or_that scss files that could be included in a mix-and-match style to get the right rule set for each theme.     I also created a new _slp_defaults include file that does nothing more than include all of those half-dozen rules.  Nearly half of the current CSS files use all of rules that were “boiled out of” the CSS files.

Store Locator Plus Default Includes
Store Locator Plus Default Includes


Along the way I learned about mixins.   At first I was a bit confused as to the difference between include files and mixins.  Both are “pulled in” using similar commands in SCSS, @import for the “include files” and @include for the mixins, but what was the difference?    While you can likely get away with “faking it” and having mixins act like includes they serve different purposes.   I like to think of a mixin as a “short snippet of a CSS rule”.

A common example is a “set the border style mixin”.  In the simplest form it can set the border style with a rule for each of the browser variants.  This rule is not a complete CSS rule but rather a portion of a CSS rule that may do other styling AND set a border.    The mixin includes the -moz and other special rule sets to accomodate each browser.   Rather than clutter up a CSS entry with a bunch of border-radius settings, use a mixin and get something like:

.mystyle {
   @include mixin_border_radius;
   color: blue;

That is a very simplistic way of using a mixin. One advantage is that if you decide to change the default border radius settings in all of your CSS files you can edit a single mixin file. However that is not a typical use. Yes, you can create subsets of CSS rules, but it really gets better when you add parameters.

At a higher level a mixin is more than just a “CSS rule snippet”. It becomes more like a custom PHP function. In typical coder fashion, I snarfed this box-shadow mixin somewhere along the way:

// _csa_mixins.scss

@mixin box-shadow( $horiz : .5em , $vert : .5em , $blur : 0px , $spread : 0px , $color : #000000 ){
    -webkit-box-shadow: $horiz $vert $blur $spread $color;
    -moz-box-shadow: $horiz $vert $blur $spread $color;
    box-shadow: $horiz $vert $blur $spread $color;
@mixin csa_default_map_tagline {
    color: #B4B4B4;
    text-align: right;
    font-size: 0.7em;
@mixin csa_ellipsis {
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;

Since that rule is part of my default _csa_mixins that I tend to use in multiple places I use it as follows:

@import 'include/_csa_mixins';
@import 'include/_slp_defaults';

//blah blah boring stuff here omitted

// Results : Entries (entire locations)
.results_entry {
    padding: 0.3em;
    @include box-shadow(2px, 4px, 4px, 0px, #DADADA);
    border-bottom: 1px solid #DDDDDD;
    border-right: 1px solid #EEEEEE;

Notice how I now call in the include with parameters. This is passed to the mixin and the Sass preprocessor calculates the final rules to put in the CSS file. This makes the mixin very flexible. I can create all sorts of different box shadow rules in my CSS files and have the cross-browser CSS generated for me. No more editing a dozen box shadow entries every time I want to change a shadow offset.

Here is what comes out in the final production CSS when using the above mixin. You can see where the parameters are dropped into the .results_entry CSS rule:

.results_entry {
  padding: 0.3em;
  -webkit-box-shadow: 2px 4px 4px 0px #dadada;
  -moz-box-shadow: 2px 4px 4px 0px #dadada;
  box-shadow: 2px 4px 4px 0px #dadada;
  border-bottom: 1px solid #DDDDDD;
  border-right: 1px solid #EEEEEE; }

This is only a start of my journey with Sass and I’ve barely scratched the surface. However I can already see the benefits that are going to come from using Sass. In fact I already used it to fix a problem with cascading menus where one of the SLP theme files did not contain a rule set. Rather than copy-paste from another theme file that contained the proper rules I only needed to add @import ‘include/_slp_tagalong_defaults’ and the problem was fixed.

Going forward Sass will not only increase my throughput in CSS development but also improve the quality of the final product that reaches the customer.

My first SLP Theme file, Twenty Fourteen 01, that was built using these new Sass files is only a 136 line CSS file with LOTS of whitespace and comments.  When the final processing is finished it has all of the rules necessary to support the current add-on packs and style them nicely for the WordPress Twenty Fourteen theme in all major browsers.

A new SLP Theme: Twenty Fourteen Rev 01
A new SLP Theme: Twenty Fourteen Rev 01


Posted on

Google Drive – Did They Hear Me?

A few weeks ago I was on my Google Drive and organizing stuff from several project, prospective business ventures, and my WordPress plugins.  I have a half-dozen “things” going on these days and need to keep my notes, spreadsheets, flow diagrams, and other materials organized.    I created folders and moved stuff around.    To make it even easier to find things I assigned a color code to each folder as visual clues make for faster navigation once you train yourself on things like colors and shapes.  This is why good icon design is paramount, given mobile desktop UX that proliferates our lives thees days.

However, at Google Drive I noticed that the colors I assigned to various project folders only shows up as a colored box on the drop down menus as well as a few other discrete places.   I decided to drop Google a note via the web feedback form.    “Hey Google.  Why don’t you color code the FOLDERS themselves instead of keeping them all gray?   Should be easy enough to do.  You obviously are passing color code data to the UX already.”.   Something to that effect.

I never got a response, but today when I went to my Google Drive I saw EXACTLY what I had requested as part of the updated UX.

google drive colored folders
google drive colored folders

Unfortunately Google never responded to my suggestion other than their typical bot responder.   Did they look at my suggestion and send it to a developer that said “Great idea, that will take 2-seconds to put in place” and baked it into the experience?  Or did they already have this planned for months?  Approved by committee  and a band of meetings to to a UX review analysis and full UX studies?    I’d like to think Google is still able to operate in an Agile fashion, fast & nimble and responding to input quickly.    Or have they become a typical corporate giant where it takes a year to get even a single pixel moved after design, analysis, re-design, and several board meetings before anything happens?

I’m not sure if my request and the 3-weeks to seeing it go live was just a coincidence.  Probably.   But I’ll fool myself into thinking that maybe I was the 10th request they got this month for that feature and some dev just “threw it in there”.   If only Google would communicate with the user base, or even just the paid business apps accounts (yeah, I pay for gMail… I know, right?), and give us some clue that someone is listening.  Whenever I communicate with Google I hear the “on hold music” playing  in my head.. “Is anybody out there?   Just nod if you can hear me…”  – Pink Floyd.

Regardless, I’m happy that my Google Drive is no longer color blind.   Thank you Google!