As WPeC has grown over the years the visitor profile mechanism has evolved. This is my best recollection of the progression.

What are customer or visitor profiles?

It’s where the web site stores things like what items are in your cart, what categories you have selected to view, and anything else the site needs to remember about a shopper as they progress through your e-commerce site.

In the olden days..

Prior to sometime around WPeC release 3.8.9 (or even earlier ?) visitor profiles were stored using data connected to PHP sessions. This means that the customer data was essentially a cookie. This approach, although widely used has some drawbacks. Most notably, PHP sessions don’t work the same everywhere and they are being discontinued.

WPeC stopped using PHP sessions

Sometime around release 3.8.10(?) using sessions was discontinued and the information that connected a visitor to their profile data was put into a cookie.  The PHP session dependency was eliminated and WPeC put the identifier that connected a visitor to their profile information into a cookie.  This replicates the process used by WordPress to connect a user to their user profile.  It’s very secure and has none of the issues related to how a web site is handling PHP sessions.

What’s in the WPeC visitor ID cookie?

Same type of content that WordPress puts in the cookie it sets when a user logs in to a WordPress site. Just a randomly generated number and a magic string that only the specific server that created it knows how to validate.  This means that there in’t any useful personally identifiable or information that can be stolen from the cookie. And stealing the cookie doesn’t help someone spoof another user.

So where is the data that is connected to the visitor id cookie stored?

Until around WPeC 3.8.12(?) the visitor profile was stored in a WPeC general meta data table.  Functionally this worked really well and made WPeC a very secure commerce platform.

Upsides to storing the data in the database:

• Private data is being protected very well, unlike trying to encrypt it and store it in a cookie where it could be stolen and hacked.
• Web page delivery is a little smaller and quicker because there isn’t a big blob of hidden data being sent with every page view and background (AJAX) request.

There is a downside to this method…

• The downside to this is every page view would have to get the visitor’s data from the meta table, and perhaps update it, on every page view.

WPeC team started looking to improve performance…

The discussions of the best way to improve the performance of the WPeC visitor meta are still available on GitHub and can be reviewed if anyone is interested.   But here is our summary: Three possible solutions we identified

• Implement a caching mechanism for the WPeC meta table being used to store visitor and other information
• Use WordPress to store visitor profile information in an existing data type get the benefits of WordPress’ built in data management and data caching
• Use WordPress to store visitor profile information in new data type get the benefits of WordPress’ built in data management and data caching

Which of the alternatives was selected?

The WPeC development team implemented and unit tested all three solutions! Not a small amount of work. As each solution was ready it was merged into a WPeC test build and evaluated.  My recollection of the evaluation of each potential solution is as follows

	Advantages	Disadvantages
Common WPeC meta table with custom caching	No database changes	Determining which data should be cached would be difficult Caching all data could increase memory usage Several thousand lines of special purpose code would have to be thoroughly tested and maintained
Existing WordPress data type with built-in WordPress caching	WPeC visitor meta data becomes very tightly integrated with WordPress user meta data and gives a convenient complete view of a user. No database changes Caching is automatic and very robust Transitioning from anonymous visitor to registered user very quick and efficient Only a small amount of code that has to be tested and maintained	WPeC visitor meta data becomes very tightly integrated with WordPress user meta data and has to play nicely
New WordPress data type with built-in WordPress caching	Caching is automatic and very robust Only several hundred lines of code to test and maintain	New database tables that need to be initialized and maintained. Not tightly integrated with WordPress users

 

A little not about collaborative open-source development…

Open source development isn’t a democracy, nor is it a dictatorship. The best analogy I can think of it is most like when you where a kid and you got together with all the other kids in the neighborhood to do something together.  If you decided to go fishing as a group, the kid with the most knowledge of fishing exerts more influence on where you go and how you fish. If you decide to play video games, the kid with the best console and selection of games is whose house you go to, and he exerts a little more influence on which game you play. If you want to play hockey, the kid with the pond in their yard is likely to have a little more of a say. When a new kid moves into the neighborhood, even though everyone listens to the new kid, sometimes he is a little less equal among equals. So if the group decides to go skating, but the new kid says I pretty sure the ice isn’t thick enough and we’ll end up getting wet.  Everyone in the group says that the ice is fine, we were on it yesterday. When you go skating and it turns out the ice in one spot of the pond was too thin, everybody in the group gets wet. If you’re a kid you have a few choices.  You can beat up the kid who owns the pond.  If you thought the ice was thin you can say I told you so, then you get beat up (deservedly so) . You can say as a group, that really sucked, but we aren’t going to a funeral so we’ll get over it. Let’s go over to the kids house with video games and warm up, Then smile and decide as a group that maybe next time we should measure the ice in a few more places when there is some doubt on if we are doing something dangerous.

The discussion…

Over a period of a number of days, maybe weeks, a public discussion took place on which was the best solution.

Integration testing

All the solutions where functionally very good, at PyeBrook even went as far as to try each of them on WPeC sites we manage. One site was small, having about 10 products and several hundred visitors per day.   The other somewhat large, having 130,000+ products and thousands of visitors per day.  All of the solutions worked, but WordPress user table problem was observed on one of the sites and reported back to the community.  The WordPress User problem was addressed in a change to the implementation, and it appeared to address the issue more than adequately in all known test cases.

The Common WPeC meta option was eliminated first because it had the most custom code, highest potential memory footprint, the highest maintenance burden over time, and biggest pre-release testing requirement.

The choice between the other two options seemed to boil down to:

• It would be best to use existing WordPress data type with built-in WordPress caching because it is tightly integrated with WordPress, therefore less new code,  so it is lower risk and lower maintenance burden
• It would be best to use new WordPress data type with built-in WordPress caching is lower risk because it is independent of all other WordPress functions even though it is more code to test and maintain.

The public discussion happened. The advocates for using the existing WordPress data type table made a really good case. They reasonably believed based on the work they did to address the reported issue, that the problem was behind them.  And that the tight integration with WordPress was an advantage. The people who advocated for the new WordPress data type with built-in WordPress caching were not convinced that the solution to the issue was adequate, but they could not create additional tests that showed the problem, nor could they sway the group that the tight integration with WordPress was a disadvantage.

The decision was made, release 3.8.13 was published…

Over the next weeks a significant number of sites started having issues, and it became obvious that the suspicions that there might be scenarios where the user flooding problem would surface turned out to be true.

Knowing what we know now back then the group would make a different choice.  Knowing what we knew then now I’m not sure we would make a different choice,

Just remember the kids playing hockey who went swimming, Not going to a funeral, went to someone house warmed up, had some hot cocoa, played some video games. Next time they go skating if they aren’t sure the will measure before they skate.

Where are we now?

In the pending 3.8.14 The visitor meta infrastructure uses an independent data type.  The API and performance have been greatly improved beyond what they were at the time of the 3.8.13 release. All we are waiting for is the last remaining issues designated for release to be finished and tested.

If you can help fix a bug, or even more importantly test any the hundreds of enhancements and fixes that are coming in the 3.8.14 release jump over to GitHub and give it a go.

Stop reading now if you don’t appreciate editorializing!!!

It’s very disappointing to read in some of the forums the posts, even though they are from a very small subset of the WPeC community that are critical of the character, commitment or intent of the WP-e-Commerce development community. The WP-e-Commerce community also includes Instinct who has committed resources (in case you self-righteous trolls don’t understand resources means money and paid personnel work time ) to make this product possible.

I wish more people would respond to the trolls or anyone who tries to make anyone in the WP-e-Commerce community ( developer, user or corporate sponsor) feel bad about their role or contribution.

Don’t fall for the switch to something else because it will be better BS.  The trolls who portend to advocate this never switch.  In any case after a serious issue like this I am reminded of one of my two favorite business anecdotes. The Thomas Watson story..

“Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?”

Well you have just paid with the stress and the headache of having to deal with the issue. Why switch now when you and the development team have learned something really important. And the benefits of those lessons are right around the corner.

If you trolls want to take your shot at me point go ahead. Point me to another e-Commerce solution that can do better than this:

• Free
• Can run any of my clients sites including a 150,000 product web site on a $50 per month VPS with page load times less than 2 seconds.
• Big community of quality developers where we and our clients can find both free and paid support in any region of the world
• Plethora of free and paid plugins.
• Robust API so we can create custom plugins without roto-tilling the core code and having to retest the world
• Open source so I can integrate any other solution I choose when the need arises

 

Right now, I’m going to go back and fix and test a few more issues that are in the WPeC GitHub repository.  If time allows, as the 3.8.14 release gets closer, I will try to follow-up with some information on the WPeC customer/visitor meta API and some of the really cool stuff you can do with it.

If you are doing development locally and like to make lots of commits as you code and test and test you know that pushing a branch with all those commits can sometimes m amke it hard for reviewers to understand what has changed and why.

Wouldn’t it be great if you could compress all of your smaller commits together but still preserve the comments you entered with each commit? It looks like it can be done!

Found this little tip here http://stackoverflow.com/questions/5189560/how-can-i-squash-my-last-x-commits-together-using-git.

# Reset the current branch to the commit just before the last 12:
git reset --hard HEAD~12

# HEAD@{1} is where the branch was just before the previous command.
# This command sets the state of the index to be as it would just
# after a merge from that commit:
git merge --squash HEAD@{1}

# Commit those squashed changes.  The commit message will be helpfully
# prepopulated with the commit messages of all the squashed commits:
git commit