I’m a software developer based on beautiful Vancouver Island with a particular interest in web-based open source software like WordPress. I’ve helped to build, test, manage and support a diverse range of online projects and, when the mood takes me, I share thoughts, tools, links and whatever else might take my fancy right here on my blog.
Often, when setting up repositories on Ubuntu and related distros, you will need to know the release codename. In general, you can grab this using:
This is great, except the codename you receive if you use this under Linux Mint (let’s say “sylvia”) may not match the codename you would receive if you used the same command under a stock Ubuntu install (let’s say “xenial”) and oftentimes it’s the upstream codename (“xenial” in my example) that you will need.
The information is readily available with some search engine-foo, but it can also be found locally within /etc/upstream-release/lsb-release. I wanted a handy one liner for the future, so I added the following line to my .bash_aliases files:
alias upstream-lsb="grep DISTRIB_CODENAME /etc/upstream-release/lsb-release | grep -o --colour=never \"[a-z-]*$\""
With that in place (don’t forget to reload it, ie source ~/.bash_aliases or equivalent!) things are a piece of cake. Example of usage:
$ upstream-lsb xenial
Every now and again it’s time to setup a new machine and I wrestle with getting MySQL to observe my custom bind_address and other settings. Which settings file should I override and in which order are they consumed by the MySQL server, anyway?
The output from the above command contains the answer. Aside from some typical help file stuff about various options and switches, it also shows the value of various server variables and contains a section like this example, from which you can learn the order in which MySQL loads .cnf files:
Default options are read from the following files in the given order: /etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf The following groups are read: mysql client
Now I know the order of precedence, as well as the groups that are actually read in.
Nginx all setup and correct? Check! WordPress installed and ready to go? Check! 404 Not Found pages all working as expected? Almost 😐.
If you’re finding that attempts to access some.site/this-page-doesnt-exist bring you to a nicely crafted, theme-generated and possibly witty 404 Not Found page but some.site/some-nonexistent-file.php (note that *.php file extension) takes you to a rather starker looking Nginx-generated 404 page, then you have a few options that include just living with it.
Assuming for consistency’s sake however that the only option you really want to shoot for is to have non-existent *.php files take you a WordPress 404 page then what you’re probably looking for is the error_page directive.
Though Firefox has made a strong comeback over the last few months with its Quantum engine and other initiatives, I remain really stoked by Vivaldi and the sheer potential it offers for a personalized browsing experience through a rich array of options and settings.
A huge amount is configurable, yet it manages to remain a browser that requires very little or no setup work from new users.
Of course, some amount of what Vivaldi offers is achievable with the usual mainstream browsers via various extensions — but it’s also true that a lot of it’s features are not available even with extensions (or at least, due to limits of what extensions can do, cannot be done anything like as tidily).
What really appeals to me, though, given my browser is very much a part of my daily working environment, is just how neatly Vivaldi bundles this stuff up and gives me control: it offers a clean, customizable space I can make my own … and at a high level, a lot of the principles that attract me to Vivaldi seem like things I can take and imbue my own software projects with and I’m going to make it a personal challenge to do just that.
With no particular facts and figures to hand to back this up, I’m going to suggest that most commercial WordPress plugins and themes now employ one of the following funding models:
These are not mutually exclusive and there is an amount of mixing and matching that commonly happens. There are also other strategems, such as a lifetime licensing model — pay once and receive access to support and updates for the entire lifetime of the product.
The Events Calendar is a useful calendaring plugin for WordPress providing a number of default views (list, month and day views) through which visitors can browse published events.
Sometimes those default views are all you need — they are well crafted and look great out of the box in most cases. Other times, in order to make those calendar views really mesh with the active theme (or with other facets of a project), some stylistic changes may need to be made via custom CSS or by altering the HTML output.
That’s great and the process for doing so is pretty well documented, but an alternative approach I wanted to explore was to take an existing view and use it as the foundation for an entirely new view with a look and feel all of its own. In other words, instead of customizing list view (for example) I wanted to leave it as it is and simply use it as the foundation for a new view that would run side-by-side with it and act in a very similar way, but look quite different .
Vivaldi is one of my favourite browsers … in fact, it is my favourite browser.
Though it’s based on some well established technologies the project itself is newer and has had less time to mature than, say, Firefox or Opera – so there are a few rough edges. What it offers though is the potential for near-unbounded customization of the browsing experience and the minor wrinkles that exist are not enough to stop me from being excited and engaged by everything else it offers.
One thing I – and I think a considerable number of users – have been waiting on is support for secure sync (of passwords, bookmarks, etc) and so it was really exciting to hear that progress has been made and sync has landed in a snapshot.
Hit a curious problem lately where PHP was unable to “see” the query args being passed in via the URL … in other words, the $_GET superglobal was mysteriously empty when it should not have been.
In this specific scenario, I was looking at a view generated by a plugin which was designed to return a list of posts. Various query args could be applied to this view in order to filter the list, but in my case – in the context of my local dev environment – it stubbornly refused to do so. The URL looked a lot like this example:
(That arguably unnecessary trailing slash at the end of the path, by the way, is a result of WordPress and its canonical redirect behaviour.)
Event Tickets Plus is a WordPress plugin you can use to sell tickets for events.
Part of its feature set is a natty bit of functionality called Custom Attendee Meta, which lets organizers collect arbitrary bits of data from attendees. For example, it can be used to gather information such as t-shirt sizes or special dietary requirements … and so is incredibly useful for many events.
At time of writing, though, it does not yet allow the site admin to edit the submitted data. So, if Tom Thumb comes along and buys a ticket to an event and incorrectly gives his t-shirt size as medium then sends the site owner an email requesting they update this to extra large, the site owner is out of luck — they’re going to have to come up with some other system for recording this change (unless they poke about and make changes directly within the database, something often best avoided).