Setting up a test environment to use a Braintree sandbox account is pretty straightforward and is well documented.
However, once done there are no visual flags within the Settings → Payments → Braintree screen to indicate that one is indeed in “sandbox mode” (or the reverse, that one is in production mode). Occasionally, though, there can be a need to quickly confirm that this is the case and, when that happens, there are a couple of easy things you can do:
wp option get wc_braintree_auth_environmentwill return sandbox if you are using the Braintree sandbox.
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.
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 .
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).