Posted on

Get An Invite To Our New Locator Service

Go ahead and sign up for our Early Access Program to the My Store Locator Plus service.

My Store Locator Plus is an online subscription service that brings Store Locator Plus to ANY web technology stack.  WordPress, Django, Ruby, ASP.Net.    As long as you are hosting a site that can run JavaScript then My Store Locator Plus will work.

We are currently in the very early stages of development; what we call our “alpha release”.  It is far from being the final product but it IS functional and has been tested on various web technologies to see how well it can bring the Store Locator Plus service to non-WordPress sites.

We are now opening up our private invite to the Alpha Release of My Store Locator Plus.   The select few users that are granted access will help guide us in the features and overall user experience that will make it into our initial public launch coming in early 2017.

MySLP Locations July 2016 Alpha Release
MySLP Locations July 2016 Alpha Release

Continue reading Get An Invite To Our New Locator Service

Posted on

WordPress 4.5 Breaking JavaScript (aka Where Is My Map?)

Ever since WordPress 4.5 rolled off the press there have been numerous complaints about websites breaking.   Numerous reports are coming into our Store Locator Plus forums and support email telling us “our map broke when they updated our website”.  The problem?  jQuery. To be more specific the problem is not jQuery but  how some plugins and themes implement jQuery in WordPress.

WordPress 4.5 started shipping jQuery version 1.12.3 as the “official” version of jQuery being used  with WordPress core. jQuery 1.12 has more stringent controls than previous versions.   The most obvious, jQuery 1.12 no longer “hides” some of the syntax errors that lay dormant in plugin code.   If there is malformed  or incorrect syntax, jQuery 1.12 will complain.  Your browser will most likely stop executing ALL scripts from that point forward.  As you can imagine, this causes things, like themes and plugins  to break.
Continue reading WordPress 4.5 Breaking JavaScript (aka Where Is My Map?)

Posted on

IMPORTANT: Experience Add On / Store Locator Plus Upgrades

SLP 4.4.14 Info Tab

Store Locator Plus 4.4.17 was released today with several updates to increase performance.  One of the biggest issues was the use of the third party support assistant service, Freemius.    There have been multiple reports of issues communicating with the Freemius servers which is slowing down some customer sites.    Until we can resolve the issue with Freemius that code has been removed from Store Locator Plus.

Experience add-on users MUST UPGRADE to Experience 4.4.03.     The older versions were relying on some WordPress functions that were loaded by Freemius.    That was a bug.  All add-ons , Experience included, should be self-sufficient.   SLP version 4.4.13 and 4.4.14 will cause Experience 4.4.02 or earlier to crash.    SLP 4.4.17 will automatically deactivate Experience if version 4.4.02 or earlier is found on your site.    If you re-activate this and ignore the “upgrade Experience or a fatal error will occur” warning your site will crash.   If that happens you must use cPanel or FTP and remove the ./wp-content/plugins/slp-experience subdirectory.     Login to your account on Store Locator Plus and get the latest version of Experience 4.4.03 or higher, install and activate it.

Other performance features include a faster and simpler “News and Info” reader that uses the built-in WordPress RSS feed processor to get the latest Store Locator Plus news.    You will notice the Info tab has been reworked along with this update.   The How To Use page now includes the news feed on the right side as well as an introductory setting up SLP video.  This will also improve performance during the initial install and during the first visit to the Store Locator Plus Info tab each day.

SLP 4.4.14 Info Tab
SLP 4.4.17 Info Tab

 

Posted on

2016 Store Locator Plus Add Ons

 2012_NYE_Fireworks_(8331173703) (2)

A lot of things are underway for 2016 that will provide a vastly improved experience for our users and your customers.   Changes will be made to the add-on pack offerings that will simplify the product selection process and eliminate some confusion as to what to buy and what packs complement each other to obtain the best results.  Additionally, negotiations are underway with one of the most-talented WordPress and SaaS development teams in the world to bring a new and improved “Software As A Service” version of Store Locator Plus online.   We will also be expanding our support and technical team in-house at Charleston Software Associates.

Add On Packs

There will be a number of changes designed to simplify the add-on selection process, create a better and stable plug-in environment, reduce redundancy, and simplify our product cycle allowing us to focus on product improvements versus overhead and maintenance.

Legacy Add Ons

Starting in early 2016 , the legacy add-on packs will enter the first transition phase.  The plugins that are selected will only receive bug fixes and security patches going forward.   All of the Charleston Software Associates (Store Locator Plus author) products will be classified as legacy products over the next few months, For example:

  • Contact Extender
  • Directory Builder
  • Enhanced Map
  • Enhanced Results
  • Enhanced Search
  • Pages
  • Pro Pack
  • Tagalong
  • Widget Pack

Customers that have purchased these products will still have access to the downloads and will receive updates whenever a new security patch or bug fix is released.

New Add Ons

When the legacy products enter this transition phase, they will no longer be available as a separate stand alone purchase by new customers.    In their place we will have three core add-on packs in addition to a group of “ala-carte” third party add-on packs available for purchase.    We will be simplifying the add-on pack selection by offering just 3 options, Power Users, Enhanced Experience, and Premier.

Users of the legacy products can opt to retain their prior add-on packs and operate as normal.  However, users that wish to take advantage of the new add-ons, simplifying the installation process will need to purchase them as a new product package.   Once the packages are installed the legacy products can be removed. More details will be available and reminders sent as that date approaches.

Power Users

The forthcoming “Power” package add-on will include all of the features and functionality of the current Pro Pack, Tagalong, Pages, and Contact Extender add-on packs.  The focus of this add-on is the administrative side of location management as well as various features that tend to be utilized by the power user.  As part of this new offering the Pro Pack user-interface-related “Experience / View” setting, which determines the overall layout structure of the Store Locator Plus interface (map on left, right, below search form, etc.) will be moved into the forthcoming Experience add-on.

The Power add-on will be selling for $250 per-site one-time fee.

Experience

The Experience add-on, being released in early 2016, will include all the features of the user-interface-centric features of the various Store Locator Plus legacy add ons.   This new add-on will include the features of Enhanced Map, Enhanced Results, Enhanced Search, and the Widget Pack.   It will also inherit the Experience / View setting from the Pro Pack.    This add-on will also make it far easier to deploy the built-in plugin styles as you will only require one plugin-in to achieve most of the visual updates.

The Experience add-on will be selling for $250 per-site one-time fee.

Premier

Technically now a “new” plugin but one that will carry over from the legacy model to the new model, the Premier add-on will continue to be the flagship plugin where new “never been done before” features are added.    While the Power and Experience add-ons will occasionally see a new feature added, anything that is completely new and introduces more complex features to the product will appear in the Premier add-on.   The Premier add-on is only available to users with a Premier subscription.

Speaking of the Premier Subscription, users with an active subscription will get the new Power and Experience add-ons as soon as they are available and will have access to the prerelease versions of both products.   There are not changes anticipated for the Premier Subscription in 2016.   An exclusive first-response Premier Forum, access to our real-time Slack channels, and access to all plugins and themes crafted by Charleston Software Associates remains in the plan.

The Premier Subscription will retain the current $250 sign-up + $30/month pricing.

Third Party Add Ons

Due to our compensation agreements with third party authors, the third party plugins will remain online in their standard ala-carte form.   These plugins will have a new forum where all 3rd party plugin questions will be answered and supported by both the original author and, as needed, Charleston Software Associates.  The following plugins will remain as ala-carte options:

  • Extended Data Manager
  • Event Location Manager
  • Social Media Extender
  • Gravity Forms Integration
  • Gravity Forms Locations
  • MultiMap

Most third-party add-ons are priced at a $50 one-time fee.

End Of Life Offerings

The following offerings will be going away in 2016.

All Icon Packs will be replaced with a more efficient loading process to be introduced in 2016 and added to the Premier plugin.

The Experience Package is going away.  This will be replaced with the Experience plugin.

The Kitchen Sink Package is going, going, gone as a separate purchase.  Users wishing to get all of the nifty features and more should subscribe to the Premier Subscription as a one-year subscription. It is less than the price of the Kitchen Sink package and provides more benefits.

 

The SaaS Project

Work will begin in earnest on a subscription-based Store Locator Plus service.    This should not be confused with the Premier Subscription.  Purchases and subscribers  of the Premier Subscription will not be automatically enrolled in the SaaS system .   The SaaS (Software As A Service) product will allow companies to sign up via a new website and use a simplified interface for managing their locations and tweaking their user interface.    When everything is ready the user will be given a short JavaScript snippet or iFrame code to place on ANY site, not just WordPress sites.

This new service will look-and-feel much like the Store Locator Plus WordPress plugin with some big visual improvements.   However, users of this system will no longer need to worry about updates to ensure they have the latest version, backing up their locations, moving their installs from a staging to live site, or other management tasks related to maintaining their locator plugin.

Pricing is yet to be determined.   Initial models include a free tier for a handful of locations and $30/month for most sites.

Posted on

Configuring Apache 2.4 Connections For WordPress Sites

Recently I upgraded my web server to PHP 5.6.14. Along the way the process managed to obliterate my Apache web server configuration files. Luckily it saves them during the upgrade process, but one thing I forgot to restore was the settings that help Apache manage memory. Friday night around midnight, because this stuff ALWAYS happens when you’re asleep… the server crashed. And since it was out of memory with a bazillion people trying to surf the site; every time I restarted the server I could not log in fast enough to get a connection and fix the problem.

Eventually I had to disconnect my AWS public IP address, connect to a private address with SSH, and build the proper Apache configuration file to ensure Apache didn’t go rogue and try to take over the Internet from my little AWS web server.

Here are my cheat-sheet notes about configuring Apache 2.4 so that it starts asking site visitors to “hold on a second” when memory starts getting low. That is much nicer than grabbing more memory than it should and just crashing EVERYTHING.

My Configuration File

I put this new configuration file in the /etc/httpd/conf.d directory and named it mpm_prefork.conf. That should help prevent it from going away on a future Apache upgrade. This configuration is for an m3.large server running with 7.4GB of RAM with a typical WordPress 4.4 install with WooCommerce and other plugins installed.

# prefork MPM for Apache 2.4
#
# use httpd -V to determine which MPM module is in use.
#
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# ServerLimit: maximum value for MaxRequestWorkers for the lifetime of the server
#
# MaxRequestWorkers: maximum number of server processes allowed to start
#
#
# TOTAL SYTEM RAM: free -m (first column) = 7400 MB
# USED SYSTEM RAM: free -m (second column) = 2300 MB
#
# AVG APACHE RAM LOAD: htop (filter httpd, average RES column = loaded in physical RAM) = 87MB
# TOTAL APACHE RAM LOAD: (htop sum RES column) 1900 MB
#
# BASE SYSTEM RAM LOAD: USED SYSTEM RAM - TOTAL APACHE RAM LOAD = 2300 - 1900 = 400MB
#
# AVAILABLE FOR APACHE: TOTAL SYSTEM RAM - BASE SYSTEM RAM LOAD = 7400 - 400 = 7000MB
#
# ServerLimit = sets the maximum configured value for MaxRequestWorkers for the lifetime of the Apache httpd process
# MaxRequestWorkers = number of simultaneous child processes to serve requests , must increase ServerLimit
#
# If both ServerLimit and MaxRequestWorkers are set to values higher than the system can handle,
# Apache httpd may not start or the system may become unstable.
#
# MaxConnectionsPerChild = how many requests are served before the child process dies and is restarted
# find your average requests served per day and divide by average servers run per day
# a good starting default for most servers is 1000 requests
#
# ServerLimit = AVAILABLE FOR APACHE / AVG APACHE RAM LOAD = 7000MB / 87MB = 80
#
#

ServerLimit 64
MaxRequestWorkers 64
MaxConnectionsPerChild 2400

The Directives

With Apache 2.4 you only need to adjust 3 directives. ServerLimit, MaxRequestWorkers (renamed from earlier versions) , and MaxConnectionsPerChild (also renamed).

ServerLimit / MaxRequestWorkers

ServerLimit sets the maximum configured value for MaxRequestWorkers for the lifetime of the Apache httpd process. MaxRequestWorkers is the number of simultaneous child processes to serve requests. This seems a bit redundant, but it is an effect of using the prefork MPM module which is a threadless design. That means it runs a bit faster but eats up a bit more memory. It is the default mode for Apache running on Amazon Linux. I prefer it as I like stability over performance and some older web technologies don’t play well with multi-threaded design. If I was going to go with a more stable multi-thread environment I’d switch to nginx. For this setup setting ServerLimit and MaxRequestWorkers to the same value is fine. This says “don’t ever run more than this many web servers at one time”.

In essence this is the total simultaneous web connections you can serve at one time. What does that mean? With the older HTTP and HTTPS protocol that means every element of your page that comes from your server is a connection. The page text, any images, scripts, and CSS files are all a separate request. Luckily most of this comes out of the server quickly so a page with 20 web objects on it will use up 20 of your 64 connections but will spit them out in less than 2 seconds leaving those connections ready for the next site visitor while the first guy (or gal) reads your content. With newer HTTP/2 (and SPDY) connections a single process (worker) may handle multiple content requests from the same user so you may well end up using 1 or 2 connections even with a page with multiple objects loading. While that is an over-simplification, the general premise shows why you should update your site to https and get on services that support HTTP/2.

Calculating A Value

# TOTAL SYTEM RAM: free -m (first column) = 7400 MB
# USED SYSTEM RAM: free -m (second column) = 2300 MB
# TOTAL APACHE RAM LOAD: (htop sum RES column) 1900 MB
# AVG APACHE RAM LOAD: htop (filter httpd, average RES column = loaded in physical RAM) = 87MB
# BASE SYSTEM RAM LOAD: USED SYSTEM RAM - TOTAL APACHE RAM LOAD = 2300 - 1900 = 400MB
# AVAILABLE FOR APACHE: TOTAL SYSTEM RAM - BASE SYSTEM RAM LOAD = 7400 - 400 = 7000MB
# ServerLimit = AVAILABLE FOR APACHE / AVG APACHE RAM LOAD = 7000MB / 87MB = 80

There you go, easy, right? Figuring our RAM resources can be complicated, but to simplify the process start with the built-in Linux free command and I suggest installing htop which provides a simpler interface to see what is running on your server. You will want to do this on your live server under normal load if possible.

Using free -m from the Linux command line will tell you the general high-level overview of your server’s memory status. You want to know how much is installed and how much is in use. In my case I have 7400MB of RAM and 2300MB was in use.

Next you want to figure out how much is in use by Apache and how much an average web connection is using per request. Use htop, filter to show only the httpd processes, and do math. My server was using 1900MB for the httpd processes. The average RAM per process was 87MB.

You can now figure out how much RAM is used by “non-web stuff” on your server. Of the 2300MB of used RAM, Apache was using up 1900MB. That means my server uses about 400MB for general system overhead and various background processes like my system-level backup service. That means on a “clean start” my server should show about 7000MB available for web work. I can verify that by stopping Apache and running free -m after the system “rests” for a few minutes to clear caches and other stuff.

Since I will have 7000MB available for web stuff I can determine that my current WordPress configuration, PHP setup, and other variables will come out to about 87MB being used for each web session. That means I can fit about 80 web processes into memory at one time before all hell breaks loose.

Since I don’t like to exhaust memory and I’m a big fan of the 80/20 rule, I set my maximum web processed to 64. 7000MB / 87MB = 80 * .8 = 64.

That is where you want to set your ServerLimit and MaxRequestWorkers.

MaxConnectionsPerChild

This determines how long those workers are going to “live” before they die off. Any worker will accept a request to send something out to your site visitor. When it is done it doesn’t go away. Instead is tells Apache “hey, I’m ready for more work”. However every-so-often one of the things that is requested breaks. A bad script in PHP may be leaking memory, for example. As a safety valve Apache provides the MaxConnectionsPerChild directive. This tells Apache that after this child has served this many objects to die. Apache will start a new process to replace it. This ensures and memory “cruft” that is built up is cleared out should something go wrong.

Set this number too low and you server spends valuable time killing and creating Apache processes. You don’t want that. Set it too high and you run the risk of “memory cruft” building up and eventually having Apache kill your server with out-of-memory issues. Most system admins try to set this to a value that has it reset once every 24 hours. This is hard to calculate unless you know your average objects requested every day, how many processes served those objects, and other factors like HTTP versus HTTP2 can come into play. Not too mention fluctuations like weekend versus weekday load. Most system admins target 1000 requests. For my server load I am guessing 2400 requests is a good value, especially since I’ve left some extra room for memory “cruft”.

Posted on

Fixing VVV svn cleanup Invalid cross-device link messages

Ran into a unique situation while updating my VVV box after  a weekend of WordPress Core and plugin development at WordCamp US this past weekend.   Today, after the formal release of WordPress 4.4 I needed to update the code in my WordPress trunk directory on the VVV box.  Since I have other things in progress I didn’t want to take the time to reprovision the entire box.  Though, as it turn out, that would have been faster.

The issue was when I tried to do the svn up command to update the /srv/www/wordpress-trunk directory and make sure I was on the latest code.   The command failed, insisting that a previous operation was incomplete.  Not surprising since the connectivity at the conference was less-than-consistent.    svn kindly suggest I run svn cleanup.  Which I did.  And was promptly met with an “invalid device cross-link” error when it tried to restore hello.php to the plugin directory.

The problem is that I develop plugins for a living.   As such I have followed the typical VVV setup and have linked my local plugin source code directory to the vvv plugin directory for each of the different source directories on that box.    I created the suggested Customfile on my host system and mapped the different directory paths.     On the guest box, however, the system sees this mapping as a separate drive.  Which it is.  And, quite honestly I’m glad they have some security in place to protect this.  Otherwise a rogue app brought in via the Vagrant guest could start writing stuff to your host drive.   I can think of more than one way to do really bad things if that was left wide-open as a two-way read-write channel.

VVV Customfile Cross Device Maker
VVV Customfile Cross Device Maker

The solution?

Comment out the mapping in Customfile on the host server.  Go to your vvv directory and find that Customfile.  Throw a hashtag (or pound sign for us old guys) in front of the directory paths you are trying to update with svn.  In my case wordpress-trunk.

Run the vagrant reload command so you don’t pull down and provision a whole new box, but DO break the linkage to the host directory and guest directory.

Go run your svn cleanup and update on the host to fetch the latest WP code.

Go back to the host, kill the hashtag, and reload.

 

Hope that saves you an extra 20 minutes surfing Google, or your favorite search service, for the answer.

 

Posted on

WordPress 4.4 Is Out With Store Locator Plus Contributions

WordPress 4.4 was just released today and the most important thing to note with the new release is that I am now officially a core contributor.   That’s right!  Way down in the list of 400+ people that contributed you’ll find my charlestonsw user name, listed as “Store Locator Plus”, in the credits.   Woot!    After that, there isn’t really much to report in the new 4.4 update.

Store Locator Plus is an official contributor to WP 4.4.
Store Locator Plus is an official contributor to WP 4.4.

 

I mean, sure, they added things like support for responsive images and started the first iteration of the WordPress REST API as part of the core product.  They released the 2016 theme.  And they made it so that your WordPress site can be an embed in another WordPress site.   But really, what’s more important than my 2-line patch in Core?

REST API

OK, maybe the REST API is important.   Why?  Because I hope to deploy Store Locator Plus endpoints in the next release of SLP coming this month.    For those of you that are not tech-nerds, why is this important?  Because it makes your Store Locator Plus location data globally accessible.    What does that mean?   Other tech-nerds and start creating robust web applications, mobile applications, and just-about-any-other-type of applications that fetch your location data direct from your Store Locator Plus installation whether or not they are using WordPress.   Yes, the data can be protected with user authentication to prevent third-party apps from stealing your data.    For those apps that are authenticated it means Store Locator Plus will be far more accessible in 2016.

What does this mean for people not creating mobile apps or pulling up location data from the Python-powered super-app?   A better user experience.   This new tool kit means that form posts and page loads can be phased out over time with new interfaces that feel like real-time interaction throughout the plugin.    Adding and editing locations.    Getting an infinite scrolling list of locations without pagination.   User interface elements that bring in location content on pages, posts, and even the mapping page.     Think of it as being similar to how the current “search for locations near this zip code” action where the page doesn’t refresh completely but just populates the list and markers.    But EVERYWHERE.

It will be a long slow process, but now that the REST API is official it can start to be deployed in places that were far more difficult to “hook into” in the past.

What is the first thing to roll out?

Most likely a new WooCommerce to Store Locator Plus plugin that lets you associate products with specific locations.   That code is already underway and barring any issues with testing now that the official WordPress 4.4 is out, it should roll out later this month in its first FREE version 1.0 release.

Embeds

What are embeds?   Why is it cool?   Well, it is not something that will likely be leveraged by Store Locator Plus but it is still cool enough to talk about.     What this does is allow you to reference another WordPress-based article from another site.  In the past you would get the content but it would be forced into your overall theme on your site.    With the new embed feature the remote WordPress site will send along ITS formatting data and your site will understand that and keep the original site formatting withing a tidy little viewing area for the article snippet on your site.   It retains the original user interface from the source article without messing up your site so things look better all-around.    No extra work required.    That’s a win for everyone.

Embed WordPress In WordPress
Embed WordPress In WordPress

Other Updates

There are a number of other improvements; some of which I wish had come out a year ago like term meta. I wrote my own 2 years ago and now have to think about replacing it with the WP Core version.   There is also  a new theme, lots of bug fixes, and other improvements built into WP 4.4.  Along with the REST API update , which is a great step forward into the current state of open and shared data in this new “Internet of Things” and “open everything” world, there are plenty of good reasons to update to WordPress 4.4.   Not too mention millions of websites will be running a piece of code I wrote.   <insert Doctor Evil laugh here>

Posted on

Boosting WordPress Site Performance : Upgrade PHP

As with every single WordCamp I’ve attended there is something new to be learned no matter how much of a veteran you are.   My 5th WordCamp at WordCamp US 2015 was no different.    There are a lot of things I will be adding to my system admin and my development tool belt after the past 48 hours in Philadelphia.

Today’s update that was just employed on the Store Locator Plus website:   Upgrading PHP.

Turns out that many web hosting packages and server images, including the Amazon Linux Image, run VERY OLD versions of PHP.    I knew that.   What I didn’t know was the PERFORMANCE GAINS of upgrading even a minor version of PHP.    PHP 5.6 is about 25% faster than PHP 5.3.    PHP 5.3 was the version I was running on this site until midnight.

WP Performance On PHP
WP Performance on PHP. Source: http://talks.php.net/fluent15#/wpbench

The upgrade process?  A few dozen command-line commands, testing the site, and restoring the name server configurations from the Apache config file which the upgrade process auto-saved for me.  EASY.

What about PHP 7?   That is 2-3x faster.  Not 2%.  100 – 200%.   WOW!    As soon as Amazon releases the install packages for their RHEL derivative OS it will be time to upgrade.

 

If you are not sure what version your web server is running (it can be different than command line on you server) you can find that info in the Store Locator Plus info tab.

SLP PHP Info
SLP PHP Info

The take-away?   If you are not running PHP 5.6, the latest release of PHP prior to PHP 7, get on it.  One of the main components of your WordPress stack will be running a lot faster, have more bug fixes, security patches, and more.

Posted on

Increase In WordPress Malware Detected by Sucuri

If you are running your web presence on WordPress you will want to know about this. The method used to get the JavaScript code onto your site and redirect to a malware installer is not yet know. The fingerprints, however, are easily detectable. Share this article with your site or system admin so they can scan your WordPress install and remove the malware if necessary.

WordPress Malware – Active VisitorTracker Campaign – Sucuri Blog

We are seeing a large number of WordPress sites compromised with the “visitorTracker_isMob” malware code. This campaign started 15 days ago, but only in the last few days have we started to see it gain traction; really affecting a large number of sites. Here is a quick snapshot of what we’re seeing with the infection rates.WP Malware Sucuri 2015-09-18_08-29-02

Read More at: https://blog.sucuri.net/2015/09/wordpress-malware-active-visitortracker-campaign.html

Posted on

WordPress Database Error MySQL Server Has Gone Away 4.3 Cron

For nearly a week now my WordPress site has been running extremely slowly.   My initial thought was that the simultaneous release of a major update to all of the Store Locator Plus add-on packs coinciding with the WordPress 4.3 release was the culprit.    My CPU was maxing out and I was getting hourly warnings of system overloads.   A brief pause over the past weekend and I quickly upgraded my AWS instance to something twice as big.   Something that could handle 190 simultaneous web connections.   That should do it.

Within days the server was at a crawl again.  No CPU resource errors but pages were loading as slow as molasses.

I dug deeper.   The RDS instance was not even breathing hard.  25% average CPU and 60% average RAM consumption.   Only a couple of active connections at any given time.    Cache seems to be working well.

Checked my Apache profile.  No issues there, but I did tweak the spare servers to allow 40 instant connections with no delay.

Then I re-checked the log files I had looked at last week.   There were THOUSANDS of entries like this (truncated here, but also truncated mid-packet in the log files):

[Sun Aug 30 03:09:19 2015] [error] [client 192.88.134.3] WordPress database error MySQL server has gone away for query UPDATE `wp_options` SET `option_value` = ‘a:150:{i:1440663673;a:1:{s:26:\\”action_scheduler_run_queue\\”;a:1:{s:32:\\”40cd750
bba9870f18aada2478b24840a\\”;a:3:{s:8:\\”schedule\\”;s:12:\\”every_minute\\”;s:4:\\”args\\”;a:0:{}s:8:\\”interval\\”;i:60;}}}i:1440663761;a:1:{s:18:\\”vp_scan_next_batch\\”;a:1:{s:32:\\”40cd750bba9870f18aada2478b24840a\\”;a:3:{s:8:\\”schedule\\
“;s:21:

NOT GOOD.  That was NOT there last time.   Some forensic research indicates the MySQL connection was dying, triggering a log file overload, which obliterated working RAM and CPU on the web server and the log was never written.  Upgrading the server gave enough breathing room on the web server to log the DB error.

Turns out SOMETHING is trying to update the wp_options table on a regular basis.    I’m not sure if it was because it could not write the original packet, but it looks like this data I/O request was running every minute and failing.   For nearly TWO WEEKS now.    Tons of CPU, memory, and disk I/O on the web server and giving the DB server a little extra work along the way.

The culprit?

This wp_options update is exceeding the default packet size for a MySQL request.  By default MySQL servers prevent packets over 16MiB in size to prevent injection attacks or malformed SQL commands.    Something wants to write something a lot bigger than that for some reason.  As I later learned it it a bug in WordPress 4.3 core which already has a patch “waiting in the wings”.

The Quick fix?

Easy?   Update max_allowed_packet_size in the my.cnf file.   On an Amazon RDS server this is easily done by editing your parameter group and changing that setting on the RDS server.    32MiB should suffice.

The REAL fix…

After some digging it turns out the option name ‘cron’ has THOUSANDS of entries due to a but in WordPress 4.3.

You can read about the bug here:

https://core.trac.wordpress.org/ticket/33463

To employ the fix you will need to hack WordPress core files, or wait for 4.3.01 to be released.

This is the main file you need to fix.  If this doesn’t make any sense to you, DO NOT SCREW WITH IT.  You can break your WordPress install very quickly:

trunk/src/wp-includes/taxonomy.php

r33619 r33646
4446 4446 function _wp_check_for_scheduled_split_terms() {
4447 4447     if ( ! get_option( ‘finished_splitting_shared_terms’ ) && ! wp_next_scheduled( ‘wp_batch_split_terms’ ) ) {
4448         wp_schedule_single_event( ‘wp_batch_split_terms’, time() + MINUTE_IN_SECONDS );
4448         wp_schedule_single_event( time() + MINUTE_IN_SECONDS, ‘wp_batch_split_terms’ );
4449 4449     }
4450 4450 }

You can then clear out the over-sized ‘cron’ options setting with this code:

$cron = get_option("cron");
unset($cron["wp_batch_split_terms"]);
update_option("cron", $cron);

Posted on

Locator Styles Update SLP 4.3.03

SLP 4.3.03 Genesis Plugin Style

Update 4.3.03 was released for Store Locator Plus today.   The update includes a patch to the plugin styles (formerly known as themes) and simplifies the process of applying those styles.     Shortcodes that were appearing in the results for some plugin styles has been fixed.   The directions link has also been fixed.

Change Log

Posted on

VVV For WordPress Development

Banner Vagrant Cloud WP Dev Kit Box

Now that 4.3 has been released I am taking a few days to reconfigure my production environment for WordPress plugin development. After a number of issues running the self-contained GUI development environment that included WordPress core, full plugin development, and all of my supporting infrastructure including phpStorm, SmartGit, and a series of Grunt scripts in an all-in-one Vagrant-based Virtualbox, I decided to try something new. Losing 20 minutes every few days because the self-contained GUI in Virtualbox could not sync between guest and host was too much. Something in the Virtualbox or CentOS 7 upgrades over the past year broke something fundamental in GUI I/O and I’ve been unable to track it down. Time for a change.

My change? Learning Varying Vagrant Vagrants. For those that are not familiar with VVV for WordPress development you may want to check it out here: https://github.com/Varying-Vagrant-Vagrants/VVV.

What is VVV?

VVV is a virtual development environment for WordPress.    It spins up a headless (no GUI interface) Virtualbox that contains three separate versions of WordPress (stable, dev, and trunk) as well as a myriad of tools like phpMyAdmin.   All of the settings are in place to allow your local system, my OS/X desktop for my setup, to interact with the local WordPress install from your preferred web browser.

The upside is there is a lot of community support , articles, and various tools-and-trick available to you for doing almost anything you want.    A lot of the “cool dev tricks” I never had fully working, like interactive XDebug support in phpStorm, are readily available.     It is also super-easy to switch between WordPress releases which is cool if you are sending core patches or need to test on the upcoming major release.

The downside is that you need to setup all of your development tools locally on your desktop.   Guess what happens if your computer dies?   Yup, another few hours of setting it up again.   With my prior custom self-contained virtual environment I only need to save my Virtualbox, usually by creating a Vagrant image, any time I made notable changes to my tool kit; by doing so I could restore it easily to ANY desktop ANYWHERE in the world and have EXACTLY the same environment in no more time than it takes to spin up a VVV based box.

In short, VVV is a virtual machine store on your local desktop with several WordPress installs ready-and-waiting behind your browser screen.

My Startup Tricks

I develop a number of WordPress plugins, so having full development tools and my source code are key to productivity.  Here are some things I needed to tweak on the default VVV setup to get going.

Linking Plugin Source

I am primarily developing plugins and I want them on all of the WordPress installs provided by VVV.  I can “take over” a VVV server-based directory with a local directory my mapping the local directory to the destination with a Vagrant Customfile.    Go to the base location where you placed your VVV install, you will know you are in the right place as it has the Vagrantfile for the VVV box, and create a new file named “Customfile”.

Here is my mapping entries to take over the plugin directory on all 3 WordPress installs that come with VVV:


config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-default/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-develop/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

config.vm.synced_folder "/Users/lancecleveland/Store Locator Plus/plugin_code", "/srv/www/wordpress-trunk/wp-content/plugins", :owner => "www-data", :mount_options => [ "dmode=775", "fmode=774" ]

Configuring XDebug

phpStorm comes with an XDebug listener.  This allows you to set breaks in your PHP code files, inspect variables in real-time, and do a lot of other things that are much more efficient than var_dump or print_r or die littered throughout the code.     The are a number of articles and videos on using XDebug with phpStorm.  Check it out, it is a great debugging tool.   For now, how to enable it with VVV:

Turning on XDebug is easy with VVV.

Go to the VVV install directory.

Enter Vagrant via SSH: vagrant ssh

Turn on Xdebug from the SSH command line on the virtual machine: xdebug_on

That’s it, I can now use my  local phpStorm tool to debug my VVV files.

Here is THE XDebug + VVV + phpStorm video to watch to do this.

Useful Meta

With VVV installed these URLs should work in your browser.

Users and passwords:

  • For the WP installs:  wp / wp
  • For WP Admin Users: admin / password
  • MySQL Root: root / root
    • Default DB Name: wordpress_default
    • Trunk DB Name: wordpress_trunk
    • Develop DB Name: wordpress_develop

Paths:

  • Local directories (relative to Vagrant install): ./www
  • Server-Side directories: /srv/www
Posted on

Store Locator Plus 4.3

SLP 4.3 Default Map

Store Locator Plus 4.3 was published tonight.  If you are using a Store Locator Plus add-on pack you will want to upgrade the add-on to version 4.3 after upgrading the base plugin.

Updated Admin User Interface

The revised admin user interface leverages the WordPress Dashboard styling and interface elements.   Settings boxes can be collapsed and expanded, the slider boxes are gone having been replaced with standard checkbox elements, and the CSS styling is now consistent across all add-on packs.    The new interface is designed to work more closely with the built-in WordPress responsive design elements.

Update JavaScript Processor

The JavaScript engine that drives all interactions with the locations map has been updated with a new callback system that works much like the WordPress hooks-and-filters.   For the non-techie people out there, that means it is going to be a LOT easier for future add-on packs to add very cool interactive map features without requiring full system updates.    Add-on packs can now change how the interface works without having to “hack” the base plugin.  For the techies, the AJAX processor now includes full raw location data in addition to massaged data.    New shortcode options make it easier to get exactly what you need into results and map info bubbles.

Faster Manage Locations

Further refinements to the Manage Locations interface improves performance.  Version 4.3  simplifies the codebase to make it easier to add more advanced features in future releases.  Update JavaScript libraries improve performance by eliminating server queries for tables that list all locations on a single page.   A single “expanded view” mode means less data I/O processing while rendering the screen.    Admin users can selectively hide columns on the manage locations interface, with different admin logins having their own column settings saved between sessions.

SLP 4.3 Locations Manage
SLP 4.3 Locations Manage

 

SLP 4.3 Locations Edit
SLP 4.3 Locations Edit

Better Admin Performance

Admin pages for Store Locator Plus have reduced database I/O calls to the WordPress options table.   Logic changes eliminated nearly 60 extra data I/O calls when loading the Experience tab.   On the info tab the server based news feed and current plugin versions as well as update information for installed plugins is cached, significantly increasing performance when checking plugin information.

SLP 4.3 Experience Search Settings
SLP 4.3 Experience Search Settings

Better WPML Support

The WPML engine in Store Locator Plus has been updated to work with the newer WPML 3.2 filters while retaining legacy support for older versions of WPML.   All base plugin strings are pre-registered when Store Locator Plus loads into memory.   Most text in the application now uses gettext or WPML data I/O operations which should make the entire experience far easier for international users and sets the foundation for faster turnaround for polyglot related issues in the future.

Improved Settings Upgrades

The entire settings upgrade system has been rewritten ensuring more consistent transfer of legacy settings when upgrading, whether upgrading from one version back or 10 versions back.   “Lost settings” during an upgrade will now be a thing of the past.

Patches And Fixes

A number of minor patches and updates were made in 4.3 including apostrophe search on manage locations, admin page styling mishaps from various add-ons, extended data fields not always registering with the main plugin, fixes to several shortcode attributes.

Change Log

Posted on

Store Locator Plus 4.3 for WordPress Is Imminent

SLP Version 4_3

Right on the heels of the WordPress 4.3 update, Store Locator Plus 4.3 has passed testing and is ready to be released to the general public. Normally I would suggest updating to the latest patch release of WordPress immediately prior to upgrading your Store Locator Plus installation. As fate would have it, WordPress Core pressed the publish button a touch faster than we did. Since WordPress 4.3 is “fresh out of the oven” I recommend upgrading to WordPress 4.3, then TESTING your site thoroughly, or at least testing all of your Store Locator Plus functionality then upgrading to Store Locator Plus AFTER you have completed full testing.

Backup Your Site

WordPress tells you to do it before upgrading to 4.3.

I’m telling you to do it before upgrading to 4.3.

BACKUP YOUR WORDPRESS SITE.

What’s that?  You don’t have a backup?   Go spend $9 on VaultPress now.  Wait a few hours for the backup to complete.  THEN upgrade WordPress and Store Locator Plus to 4.3.

Upgrade ALL Components

When upgrading to Store Locator Plus 4.3 you should IMMEDIATELY upgrade all of your premium Store Locator Plus add-on packs. Every single add-on pack will need to be updated for cosmetic reasons. Some add-on packs will need to be updated to restore functionality that appears to go “missing” as there are significant changes to the underlying communications engine within Store Locator Plus. Your data and settings don’t go away, but some settings for some add-on packs will not function properly until your entire Store Locator Plus plugin stack is updated to version 4.3.x.

Don’t Panic

We have spent nearly a month testing, patching, and re-testing SLP 4.3.    We have kept up with the latest WordPress development releases right up through the production release of WordPress 4.3 that came out tonight.   A handful of customers have been installing and testing Store Locator Plus 4.3 and the related add-on packs and have helped us ferret out some of the bugs in the new release.    Despite hundreds of personal invitations that

Reporting Plugin Versions
Reporting Plugin Versions

were sent out to long-time customers of SLP,  we had far less people testing version 4.3 than we had hoped.

 

That means there are likely to be some hiccups in the 4.3 release that have not been caught.    Don’t panic.    Post your issue in the forum and be sure to post ALL YOUR SLP ADD ON PACK VERSIONS by copying the version text off your Info / Plugin Environment tab into your post.   If you can, provide a screen shot of the version like the one above.   Windows and OS/X have screen capture utilities built in, or try SnagIt by TechSmith. Provide a site URL and a clear description of what is wrong and what you expect to happen.   DeBaat, CiCi, and I will address any new issues as quickly as we can and issue the 4.3.01 patches as necessary.

 

 

Posted on

Store Locator Plus 4.3 Release Schedule

4.3 RC Status Aug 6 AM

Store Locator Plus 4.3 is expected to be released into production during the week of August 17th along with 4.3 versions of all add-on packs.

4.3 RC Status Aug 6 AM
4.3 RC Status Aug 6 AM

Store Locator Plus is now in Release Candidate status.  You can download the prerelease near-production-ready version from the StoreLocatorPlus.com website.   The prerelease version is available at no cost from the store.  If you’ve already added the prerelease version to your account you can login and download; no need to re-purchase.

Most add-on packs are now in RC status as well.   If you have purchased the production version of an add-on pack you can download the prerelease version by logging in to you StoreLocatorPlus.com account.

The more people that can test version 4.3 of the Store Locator Plus plugin and add-on packs the faster it can be released to production.    Prerelease, including RC versions, of the plugin should not be used on a production system without first testing your environment on a staging (testing) copy of your site.  Companies like WP Engine make creating staging copies of your live site very easy.  If you do not employ staging sites as part of your website management strategy you really should consider switching to a hosting company that supports easy site cloning for testing purposes.