For a couple of projects on which I work, I use Trello almost daily.
Some people find it the end-all, be-all of project management. I can’t say I agree with that statement, but it definitely helps streamline certain workflows (as far as I’m concerned).
But there’s one complaint that I have regarding the application: There’s no way to export the actual list of members for a given board (at least not at the time of this writing). Sure, you can export a board, but what happens when you want to contact all of the users?
There’s no way to export the actual list of members for a given board (at least not at the time of this writing). Sure, you can export a board, but what happens when you want to contact all of the users?
Sure, you can export a board, but what happens when you want to contact all of the users? I mean, I have a list of the users and their email addresses in a separate database, but Trello doesn’t allow me to export that data.
To export Trello board members, I put together a quick script that can run in the console of Chrome (maybe others, but I didn’t test). At the very least, it will return the names of the member so you can find them in your database, assuming you have one.
In the previous post, I started walking through what we need to do to display custom messages in WordPress. This is specifically in the case of when we are opting to use something other than the Settings API.
In the previous post, I covered the following:
- Looking at what happens when you use a safe redirect via one of the available WordPress functions,
- Serializing custom error messages
- Saving them to the database
To follow-up with what was previously covered, I’ll show how to render these messages – regardless of if they are error messages, notices, or success messages – on the administration page.
When working with PHP, there are some great libraries and tools that make it easy for logging notices, warnings, errors, and so on within our code.
For what it’s worth, I think PHP does a pretty good job of doing this on its own, but if you need to write your custom logging code, there are plenty of off-the-shelf libraries that are helpful.
But that’s not the gist of this post. Instead, just as I think it’s important to make sure we’re providing reliable logging information, I think it’s important that we’re able to view said logs, as well.
I’m going to have a significantly longer post (or series of posts) that go more into detail about setting up WP-CLI, proper unit testing of WordPress plugins, and so on.
But for those who are already working on setting all of this up and are hitting a couple of problems with trying to set up a temporary database using some of the provided WP-CLI shell scripts, I wanted to share the solution that I used to resolve this.