Easily one of the most irritating things about WordPress is the continuous attempts to up-sell in the dashboard. Here’s how to get rid of them.
It’s one thing to have a gentle hint, like Updraft Plus saying “hey you can get more features with the pro version” and a dismiss function that makes the reminder go away for a year. It’s more irritating to have something that pops on every login, and even more irritating to see something show up every time you are on the dashboard.
I can tolerate most of these. Sometimes they’re irritating enough that I just switch plugins, especially when they try pushing related plugins you don’t give a damn about. This is one reason why there’s no Yoast on my sites. The SEO Framework is just as capable, a lot less pedantic, and it doesn’t nag. Yet.
But what to do when there’s no alternative and the plugin is persistently nagging? Use your ad blocker to make it go away! Since it has just recently pissed me off, I’m going to use WPCode Lite, an otherwise useful plugin as the prime example. With a recent update, this plugin has elected to add a widget to the post edit page with the title “WPCode Page Scripts”. Cool! That’s a welcome minor convenience. Click on the widget though and what do you get?
Page Scripts is a Pro Feature
That’s nice, but for me it’s not worth subscribing. How do I dismiss this? Surprise, surprise, I can’t. Well, F*ck you, WPCode! I’ll do it myself. Now this takes a little knowledge of HTML and custom AdBlock Plus rules, but the general process goes like this:
Right click on the widget and choose inspect. This will highlight the general area in the code you want.
Look for the highest level element that uniquely identifies your target widget. In my case, inspect took me to a div with the id “advanced-sortables”. We don’t want that. There are a bunch of useful elements on the page that are enclosed by that. Drill down a bit and we find another div with the id “wpcode-metabox-snippets”. That’s the one!
Click on your AdBlock icon.
Click on the gear to get to settings.
Select the advanced tab from the left.
Scroll down to “Your Custom Filters”.
In the box below “My Filter List”, enter this rule, substituting your domain for mine:
ambitonline.com###wpcode-metabox-snippets
You can also leave off the domain if you have multiple sites, but in my experience more specific rules help prevent long periods of “WTF” until your realize that the ad blocker is doing something you didn’t expect.
I’m picking on WPCode here because the arrogance of this has really ticked me off, but you can apply the same method to most other notices like this. At some point, plugin developers will take defensive measures to make this even more difficult and then we’ll have a discussion about writing user scripts in TamperMonkey and it’s kin.
Anyone writing code has probably seen a bunch of references to Docker by now. It’s like this new toy that’s all the rage, but for people like me — where picking up new things takes a crap-load more work than it used to — the general reaction is “I’ll learn that when it’s unavoidable.” Alas, a few weeks back it became unavoidable, and I’m here to report back.
If you’re even mildly inquisitive, a quick scan of Docker says a lot about containers and it’s pretty obvious that a container is some kind of virtual environment, but there’s not much that tells you why you should give a damn. I’m going to try to fix that. I’m not going to describe how to use Docker here, just what it’s for. There’s lots of great resources on making use of it elsewhere.
If you got into development in a time when your workplace had a nice air-conditioned room with raised floors and racks of servers and keyboard/console switches, then this post is for you.
The TL:DR on this is the learning curve here is a lot less than it seems at first, and the flexibility it gives you to set up and change configurations is truly powerful. Invest a few days in learning the basics and you can build, rebuild, and reconfigure virtual server rooms that significantly reduce the amount of time needed to maintain your own local environment. As a common example, if you’ve ever sworn at LAMP/ XAMP / MAMP configurations only to start from scratch or if you’ve tried to get two versions of just about anything running on the same system, then Docker definitely is for you.
There’s a mouthful. There’s two parts to this post. The first part is the story of how I arrived at using Behat, a tool that facilitates Behavioural Driven Design (BDD). The last part is the TL;DR configuration I used to get it working. If you just want to get this configuration going and don’t care about the background, skip down to it. I won’t be hurt.
First an admission: I’m really, really late to the BDD camp, and it kind of pisses me off. If I’d been using this approach for the past 15 years, there’s no question I would have gotten more done in less time.
Is a Test-Driven Design approach effective, even when working on a medium scale personal project? Yes, and here’s why.
I’ve long been an advocate of Unit Testing in software development, having found that even though the work is often tedious, the investment in good tests significantly reduces overall development time. In my experience, the time invested in unit testing pays back by a factor of ten or more.
For my latest as-yet-unreleased project, I decided to try a Test-Driven Design approach. In short, the TDD method requires that you write tests for your code before writing the code. This has some significant benefits from a design/architecture perspective:
It forces the developer to think more about the external interface for a package and less about the implementation details.
It requires a more precise definition of what the inputs and outputs of a functional block are. This can expose flaws in the overall architecture. In the case of my project, I was working on the principle that the module would take one input file and generate an output. While creating the third test case, I realized that I was duplicating content from one input file to the next, that a far better approach would be to break that information into a second, common file that could be used multiple times.
It assures near 100% code coverage for tests. In theory it guarantees 100% code coverage. In practice that’s more difficult. More on that later.
Writing a test for everything forces you to to become a user of your own code. This serves to highlight problems early, before they become deeply embedded in code. When designing something, it’s easy to oversimplify. The only easy part of the “that part will be easy” trap is falling into it. In this project my “easy” trap required no less than three refactorings and a partial re-write before it was actually easy for the user. If I was coding first and testing later, backing out of the initial design would have been much more difficult and required throwing out a significant amount of code. Code is time.
It reduces useless code. I have a distaste for missing functionality. This means that when I write a method to do something, I’m inclined to generate similar methods that do parallel things at the same time. TDD puts an end to that.
It highlights common functionality that may not have been evident in the requirements phase. This makes it easier to spin out that functionality into independent classes early in the implementation.
Software Engineering Purity and Test Structure
Although I’m a strong advocate of automated testing, it turns out I’m far from a purist. Even though there are some clear benefits, I’m not likely to build a suite of mock classes just to isolate a subject class. 100% coverage is always a good thing, but I’ll take 80% coverage, knowing that some abstract class I don’t have an explicit test for got a pretty thorough run through by other tests, metrics be damned.
If tests require some expensive operation to complete, such as accessing a database, then creating a data provider is worth the effort, but doing so purely for the sake of correctness? Not so much.
It’s a little too easy to write code for something obvious, like checking for a null value, without writing a corresponding test. Sticking to Test-Driven Design requires a level of discipline that’s difficult to maintain, particularly when you’re the only developer on a project. Because of this my test suites tend to be a mix of unit tests, integrated tests, and some kind of ugly hybrid between the two, and I’ve decided that I don’t really care. Generating sample output in a bastardized test that ends with assertTrue(true) is still useful. Even though that test always passes, every once in a while the “real world example” test exercises an unexpected pathway and throws an error that would otherwise sneak by. I’ll take that find over purism ten times out of ten.
TDD and Over-engineering
I’m also more relaxed about software engineering principles when it comes to testing. I’m more likely to copy and paste test code than I am to carefully craft a hierarchy of test classes. I may be more relaxed but I’m not lax… as it turns out this project has a bunch of test cases that are common across multiple classes. I initially just copied the first class, with all the cases, which are fairly elaborate. Then I needed to copy them again for a third class. Three is the magic number when you realize you just screwed up. It took a fair bit of effort to go back and decouple the test case generation from the expected results, but there is an immediate payback: tests that exercise more sophisticated features in the latter classes are now automatically passed to their predecessors. If a simpler class can’t handle the new case in a reasonable way, it’s evident immediately.
While I have clearly strayed form a pure Test-Driven Design methodology, starting out with TDD gave my project an obvious lift.
Reducing gold plating and improving the design
On more than one occasion I found that I was inclined to embellish code with things like getters and setters that looked useful but actually had no use case. All the “I should add this” moments were converted to “I need to write a test for this first” and it’s not long before you realize that you don’t need a test because nothing will ever need to use the method in this way. Better yet, it makes you think about how that task would ever be used. The end result of this was twofold.
First, entirely removing functionality that seemed like a good idea early in the design process but in reality was just useless baggage. Second, if the functionality was useful, it was usually in the wrong place. This led to a series of code refactors that extracted that functionality into a conceptually clean solution, either a trait or a stand-alone class, in either case useful in many places. Less code or better code. Both excellent benefits of starting with TDD.
TDD Offers Measurable Progress
When working on a project of significant complexity, particularly when working alone, it’s easy to lose track of where you are. That’s not a problem if you have a client deadline looming in the not too distant future, but when it’s a personal project, and particularly if you’re blessed with a healthy dose of ADD, it’s easy to lose momentum.
For me, loss of momentum is the death of a project. I’ve got a long list of unfinished projects that I thought would take a few weeks when I started, but in fact they needed many months. Nearly all of them died from a momentum deficit.
Test-Driven design, with it’s focus on top level functionality, really helps with that. Even though my current project is perhaps 50% complete, it’s generating useful results. The implementation is partial, but it’s functional, and needless to say it’s tested, well structured, and robust. Instead of substantially complete code that winds up with significant problems when put to actual use, I have working but functionally incomplete code that I expect will be a joy to keep working on. All of these things are giving me enthusiasm for implementing the next level of features.
Conclusions
Even though I have strayed form the TDD methodology as the project progressed, starting with TDD was the best thing I’ve ever done when working on something of significant size.
If I was working in a team, not only would I start with TDD, I’d be far more strict about sticking to it throughout the development cycle. It highlights architectural issues very early in the development process, when it’s far easier to adjust and fix the problem. A dozen minor restructurings when the code base is small is a thousand times easier than rewriting thousands of lines of code after the mistakes have been baked into the project.
It’s hardly an objective measure, but I think this code represents some of the best work I’ve done. My three week project has extended to five months so far, but I’m still excited about it. Best of all it’s still fun. It also has the unexpected benefit of spinning off Configurable, which has proven itself to be very useful in other projects (not to mention that it’s just cool, IMO).
UPDATED 2019-07-22: Netbeans 11.1, released today, incorporates a robust fix for this problem that should survive future changes in PHPUnit.
TL/DR: There’s a one line patch to PHPUnit below that will kludge the kludge and get you running again.
Anyone who has worked with PHPUnit for some time knows that backwards compatibility isn’t exactly a prime consideration. Meanwhile, although Netbeans currently has very good support for PHP, you have to figure that the intersection set between the Java developers working on the project and the people who figure that PHP is anything but a toy language for building simple projects is, well… small. [We’ll just ignore the fact that Facebook, the largest application on the planet, is written in PHP].
So when Netbeans says it offers support for PHPUnit 3.4.0 or higher, it’s okay to expect the integration to be out of date. Rather surprisingly, it’s actually worked right up to PHPUnit 8.1.
But now we have 8.2. Command line parsing has been made more robust, and the extra parameter Netbeans passes in to a kludged custom test when running a single file doesn’t work anymore. [BTW I don’t blame the Netbeans developers for this kludge, it was probably the only solution that worked back in 3.4.0.]
This makes the current Netbeans approach outdated and unworkable. Like many open source projects, this means someone who cares has to go in and do some significant re-work. Don’t hold your breath. I’d give it a go but my Java foo is about 20 years old now. I probably don’t know enough any more to even be dangerous. I think I know a good architectural approach but attempting to implement it would be a recipe for failure.
So what to do? Patch PHPUnit! This is a pain since the patch will have to be reapplied every time PHPUnit is updated, which is frequently. But at least it works.
So here’s the kludge: in the file TextUI/Command.php in the handleArguments array, just change the line that reads
if (isset($this->options[1][1])) {
to
if (isset($this->options[1][1]) && substr($this->options[1][1], 0, 6) != '--run=') {
This ignores the Netbeans-generated argument and everything works as before. Not pretty but it works.
For more information (and a possible fix), follow the Netbeans Issue.
[Ed. Note: this was originally published on a now-defunct site in 2013. Republished (and back-dated) here because seven years later people are still running old versions of Joomla 1.5! Also, Joomla is still a far better CMS than WP. WordPress is like the Microsoft of CMS systems… everyone is using it, but not because it’s the best solution.]
According to W3Techs, as of the beginning of July 2013, 63% of all Joomla sites are running version 1.x. Of these, some 92% are running version 1.5. That works out to a rather large 58% of all Joomla sites running 1.5! The other 5% are mostly version 1.6 and 1.7. [Aside: if your site is one of those 5% please just upgrade now. It’s not going to be that painful and you are a sitting duck for hackers. By “now” I mean stop reading this and go upgrade. Seriously.]
So why is the number so high? There are usually a long list of factors, and most of them are valid. Here are the ones I hear regularly:
Simply porting the site is going to be a lot of work.
We just did our site a few years ago and don’t have the budget for it.
Things we rely upon didn’t make it to 2.5.
We hate change.
The site is outdated; if we’re going to update it we want to redesign it and that’s a big job.
There’s no reason to upgrade (AKA “if it ain’t broke, don’t fix it”).
You’re only telling me I need to upgrade because you want more business.
Every web site is different, so each of the reasons above can be more or less relevant depending on circumstances. At one end of the spectrum is the hobby site that generates no revenue, and doesn’t have much traffic. A site that could be off line for a few weeks or months and not suffer. I’m going to exclude them from this discussion.
For everyone else, the question to ask is “what’s the cost of having my site suddenly go to an ‘under construction’ page?” What’s the monetary value? What’s the value of lost reputation? Take a serious look at your situation and try to come up with a reasonable number. Compare this with the cost of upgrading your site. If the numbers are close, it’s probably a good idea to start budgeting. If the cost is significantly higher than upgrading, find the budget now because it’s time to start planning!
Here’s the key issue: the technologies that Joomla uses, most significantly PHP, are also changing over time. This chart illustrates the problem for Joomla 1.5:
PHP Version
Runs Joomla 1.5?
Status
5.2
Yes
Unsupported, past end-of-life, no updates.
5.3
Yes
End-of-Life cycle started March 2013, critical updates only.
5.4
NO
Supported.
5.5
NO
Supported (available as of June 2013).
To put it clearly: there is no currently supported version of PHP that will run Joomla 1.5! While that shouldn’t be panic-inducing, it is not something to be ignored. There’s a lot of code out there (not just Joomla) that will have problems running under PHP 5.4, and lots of hosting companies will continue to support it, including Abivia. But – and this is a big one – sooner or later your host is going to send out a notice saying that they’re moving to PHP 5.4 or 5.5. Depending on the host, you’re likely to get anywhere between a week to 90 days notice. Even at 90 days, that’s a pretty tight timeline for a mid-range site, particularly if you want to throw in a redesign at the same time.
This problem is made particularly challenging by the fact that the PHP folks chose to stick with the same major version number, even though they made some major changes to the language. There are some hosts who are just now retiring PHP 4. This was made possible because hosts could run PHP 4 in parallel with PHP 5. By not making recent versions PHP 6 and PHP 7, this mechanism is no longer available. If a host wants to support 5.4, they have to drop support for 5.3 at the same time.
So put your finger on the calendar a month from today, whatever day you happen to be reading this. Imagine that at the same moment you’re doing that, you get a notice from your host saying “PHP 5.3 will not longer supported after…” and substitute the date under your finger. If that makes you uncomfortable, then it’s time to start planning your upgrade!
Recent Comments