The Widget add-on version 4.3.03 tweaks the Search by State Widget to be more intuitive when the map is rendered. In previous versions, when a visitor to your site selected a state from the drop down menu the drop down box within the Enhanced Search form on your map page would continue to reflect the drop down menu for “all of the states” contained in your location database as the default. In Widget Pack 4.3.03 the user “selected state” from the Widget Pack will be the default in the search form on the map page. This is the only change made and is a minor tweak. To see how SLP Widgets works, view the developers short video.
The latest version of Enhanced Search, 4.3.02, adds some new features and rules to allow for easier customization for styling and UI designers to change the search selector layout with the store locator plus plug-in styles. For more information, view the developer’s short video. Changes:
Additional identifiers introduced in the sl div wrap
Directory Builder version 4.3.01 fixes an issue that was occurring on some sites and producing error messages if the Directory Builder add-on was loaded before SLP was loaded in the call stack. An explanation of this change and how Directory Builder works in general can be viewed in the developer’s short video.
All of the videos contained here are also available for later viewing from the Store Locator Plus Documentation page. A “playlist” menu can be seen in the corner of the video package.
This new feature allows additional table structure design features with Word Press themes and Store Locator Plus styling, specifically to allow tables without the HTML wrappers that are built into the SLP base plug-in structure. Further discussion and instructions can be found in the 2 minute tutorial video at Premier 4.3.02 Video
Add Headers in the Results Layout
Ability to add results headers at the top of each column and allows flexibility in your custom design.
Add Drop down styling in the Search Layout
Adds the ability to change the Drop down style found within the Experience/Search panel using applicable “jquery smooth list themes”.
Also New SLP Plugin Style “Skywalk” coming to premier next. See preview in the following video.
Important!For additional details and technical information, please watch the short Tutorial Video on how to use, modify and enhance the users experience using the new features.
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 theWordPress 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.
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.
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.
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:
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:
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:
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.
As a plugin developer it is one of the more important principles of plugin development. It is one that took me far too long to learn and based on all the things the break when you install various themes and plugins, I am not alone in that department.
Why It Is Important
Why is this so important? You load your script on EVERY PAGE in the worst case scenario, or EVERY ADMIN PAGE in the half-right scenario.
Doing it wrong has two notable side effects, neither of which is a good thing:
It slows down page loads unnecessarily. Think about it? The server reads a file from disk (slow), loads it into memory, and does nothing. More stuff in memory = higher chance for paging (putting memory blocks on disk) = more slowness. Unless you are running a server on solid state drives (SSD) then disk I/O is the worst possible thing you can be doing in terms of performance.
Use The Hooks
Curious on how this all hooks into WordPress?
Look in the admin-header.php file in the wp-admin subdirectory. You will find this call sequence right at the top:
Always develop with debug mode on.
Always get a page handle when creating an admin page, you need to that to invoke the hook.
Always develop with debug mode on.
Always use classes. Do not use procedural code. It sucks.
Always develop with debug mode on.
Seriously. Turn on full debugging in your development environment. There are far too many (90% I’d guess) plugins out there that are barfing warnings all over sever logs every day. Multiple by millions of installs. Times thousands of visitors. You’ve got billions of lines of warning messaging spewing forth all over the Internet and server logs every day. No wonder my Internet connection is slow as hell some days.
The Simplified Version
While this technique may not be perfect, it gives you the general construct you need to do it right. The short version shows you the concept, it is not cut-and-paste code. Go to the WordPress Codex and look this stuff up.
This is the “down and dirty” version using a class construct as a namespace only. In the real world you will want to invoke the class as an object and avoid the static declarations and direct calls, but hey… its another step toward “don’t pollute other plugins or core WordPress with my crap” nirvana.
The whole thing starts with the add_action(‘admin_menu’) call. This runs whenever the WordPress dashboard loads up the admin pages.
It then calls the add_my_pages function within the MyPlugin class.
MyPlugin::add_my_pages() will build our admin page by using the add_options_page() function of WordPress. If you look that up you will discover what parameters to pass to make it build your admin page. You will likely be adding a “createAdminPage()” method to the MyPlugin class, but that is beyond the scope of this article. The important point here is that when WordPress does connect your plugin admin page to the system it will return back a unique handle for that page. You need this for the next step.
MyPlugin::add_my_pages() then tells WordPress that whenever your admin page loads, fire off the loadMyJS() method for your plugin. How? WordPress has a special hook called admin_head-<something>. That SOMETHING is the handle that you got from the add_options_page() call. That hook is ONLY called when your admin page loads. Which means the next step ONLY happens when your admin page renders, not every single page on the site.
So that is the general process. Go forth and learn how to incorporate this in your plugins. Then teach others.
The entire WordPress community thanks you for it.
Oh… and the CSS stuff I mentioned? Rename “loadMyJS” to “loadMyJSandCSS” for clarity, then throw in the wp_enqueue_style() calls.