Tom McFarlin

Software Engineering in WordPress, PHP, and Backend Development

Page 148 of 427

How To Export Trello Board Members

For a couple of projects on which I work, I use Trello almost daily.

Export Trello Board Members

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.

Continue reading

Practical Tips for Refactoring Code

If you’ve worked on a project available to any reasonably sized audience, then you’re no doubt familiar with the bug reports, problems, and issues that can come in after something has gone live.

It’s true that the majority of the work in software comes after the first reason of a release.

Think about it this way:

Once you’ve built the product, released it, and then are responsible for maintaining it, how often do you have to triage issues? Then how frustrated are you that you’re fixing something that wasn’t foreseen earlier during development?

The thing is, this is entirely normal. It’s no less frustrating. But it’s normal. However, there are small, practical things we can do to our code throughout development or during maintenance.

And that’s part of the problem that we often face, isn’t it? There are things we know we can do but the amount of time it takes to do them is often incompatible with our deadlines.

So what can we do?

Continue reading

One Step Towards Dependency Injection in WordPress

Dependency Injection is one of those programmer-y terms that sounds far more complicated than it is.

As defined in Wikipedia:

Dependency injection allows a program design to follow the dependency inversion principle. The client delegates to external code (the injector) the responsibility of providing its dependencies.

The client is not allowed to call the injector code. It is the injecting code that constructs the services and calls the client to inject them. This means the client code does not need to know about the injecting code.

But think about it like this (because if you’ve used object-oriented programming, you’ve no doubt done something like this):

  • You have a class, say Class A that maintains a reference to another class, Class B.
  • In the constructor for Class A, we instantiate Class B and set it equal to a property.

Easy enough, right? Here’s the implication:

Class A now has a dependency on Class B and that dependency is only set during the instantiation process in the constructor of Class A.

On a small scale, this isn’t that big of a deal but as a plugin or an application gets more and more complicated, there are all of these dependencies set in the system without any way to necessarily test them in isolation.

And don’t get me wrong: There should be some cohesion among objects in an application, but the degree to which they are coupled should be small. There are a lot of reasons for this many of which are outside the scope of this post.

To help mitigate this, programmers have created all kinds of strategies to make sure that our classes can be small and focused and tested in isolation all the while working with other parts of the system.

And one of the most popular ways to do this is through dependency injection. But what does dependency injection in WordPress look like (and is it any different than in other applications)?

Continue reading

Understanding WordPress Hooks

WordPress hooks are arguably the foundational topic that developers need to learn and understand when it comes to building more advanced functionality for WordPress.

WordPress Hooks

Yes, you can build an entire theme primarily with markup, styles, and JavaScript. Though you may need a few server-side functions in PHP, it’s easy to find things like this in the WordPress Codex or in Underscores.me.

But if you’re someone who’s new to WordPress or who is ready to take the next step regarding extending the platform or writing a plugin, then it’s important to understand to know what WordPress hooks are, how they work, and what they’re designed to do.

And that’s what I’ve covered in my latest series on Envato.

Continue reading

Your Source Code (“This Could Be Better”)

I’d like to think that one of the struggles many developers feel when shipping code is a sense of “this could be better” before they push whatever button to send their code out into the world.

This Could Be Better: Code Review This

Yeah, okay, code review this.

It doesn’t necessarily matter if this is a hobby project, if this is a project for a corporate job, a freelance job, or if this is something that’s for an open source project. I say that because I think this is something that many of us feel with whatever it is that we release.

It’s a feeling of something is “not quite done” or “if I could just refine this a little bit more.” I know: This isn’t the first time I’ve talked about this before, and it’s likely not going to be the last.

And the feeling is not without merit. Other developers can make us feel like we’re doing something wrong (sometimes we are, sometimes we aren’t). But in our industry, I think there’s more of a spectrum of optimal-to-suboptimal. Though some may not agree, a friend of mine recently said it best:

The software industry is too vast and too fast to keep up with it all. But because it’s now that way, people find their niches and think that it’s the “best” or “only” way to get something done.

The further I get into my career, the more I feel this sense of obligation to make things as pristine as possible before sending it to a client, user, or just out for the world to use.

And though I think this is important, it’s important to make sure that I (and we) are doing this for the right reasons.

An example of a wrong reason might go something like this:

It’s not because it doesn’t meet requirements and it’s not because it doesn’t fulfill what was requested by the client. It’s because how others might perceive the work when they do not have the proper context.

So of course, I don’t think there’s anything wrong with wanting to make your code base or your architecture as robust as possible. We should all strive for that. But I believe that it’s important to contextualize appropriately and adequately scope your sprints, milestones, work or however you group your tasks together.

Continue reading

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑