Of of the coolest features in the recent 2.5 release of Restrict Content Pro is the new ability to automatically prorate a user's upgrade price. The way this works is if a user purchases a subscription for $10 and then changes his mind and wants the $20 plan instead, he is credited that $10 on the upgrade and the initial price of the new plan is just $10.
Several weeks back I had my world turned upside down when I took the advice of Luke Woodward, my team’s Senior Web Engineer at 10up, to hook up code stepping with Xdebug to help troubleshoot a problem I was working on. Boy was that a good idea! I had been intending to hook this up for a while but had never made it a priority, but now I use it every day as a replacement for conventional debugging tools like ‘var_dump()’ and ‘wp_die()’. Read more
I recently used the built in WordPress protected visibility status in a project where information security was very important. This handy and little used feature does a great job securing content and providing user access on a basic level but has some pretty serious security holes if you hope to use it for anything more advanced. These include:
- The identification cookie is stored in the users browser insecurely
- The identification cookie is stored for 10 days without requiring the user to re-enter the password
- Only the post content is protected, any additional meta on the page will be visible to unauthenticated users
This is a quick post today. I had been struggling for a while with strict warnings popping up all over my projects since I upgraded my Vagrant box to PHP 5.4. Your initial reaction might be to fix the strict warnings, and you would be right except when you can’t.
It seems that a lot of very popular plugins and even WordPress core throw strict errors. The temptation then is to turn off WP_Debug to avoid scrolling through a long list of errors that you can’t fix anyway.
Before you do that, let me introduce you to a better way. Read more
I am neither a command line wiz or a git expert, but learning a few commands in the terminal and learning the basics of Git has changed my workflow forever!
Here is the scenario that I’ve run into more times than I care to count. While working on a new feature for a project you find it necessary to submit a patch that conflicts with the files you are modifying for the new feature. What is the solution? In the past, this meant undoing all the progress on the new feature request so that nothing is accidentally deployed, writing the patch, deploying, and then try to paste in or rewrite all of the work you just undid. This is uncool and very inefficient.
Or how about this: your client requests a new feature that spans several files, but once it is completed decides that the site audience is not ready for it. Now what do you do? There are more features that need to be developed but how do you continue on without trashing the feature that is now on hold?
Let me introduce you to a better way.