Category: Articles (Page 92 of 258)

If you’ve worked with WordPress for any length of time especially when it comes to using some type of Ajax functionality, then you’ve likely heard the phrase “use WordPress as a proxy” at some point.

And even if you haven’t the odds that you’ve actually done it are pretty high.

Though I think that, as time moves forward, we’re going to eventually see the REST API replace the traditional ways that we’ve used Ajax but that’s likely a different story for another time.

So what does it mean to use WordPress as a proxy whenever you’re working with Ajax requests? It requires a little bit of understanding cross-site requests, how routing a request through WordPress works, and then parsing the response.

Continue reading

Up until the last year, one of the ways that I’ve scoped milestones is based heavily on the perspective of how I or my team and I were to be working the project.

There’s a problem with this approach, though: For those of us who try to include client feedback throughout the development process, it’s not as easy for them to take the jargon we use and still have them make sense of it.

To that end, I’ve started scoping WordPress project milestones a little bit differently so they are a bit more customer-friendly all the while still making sense to how a team of developers can accomplish what’s necessary to make sure things are functionality.

Continue reading

I just finished a feature for a project that uses a combination of custom post types, data imports, and updating existing posts when deleting a user (or set of users).

There’s one problem, though:

Say have you have a post that’s currently published (that is, it’s ‘post_status’ is set to ‘publish’) but, when you update the post via wp_update_post, its post_status attribute is set to ‘future.’

In order words, whenever you programmatically update a post, the status of the post is set to ‘Scheduled’ (according to the UI) and ‘future’ (according to the database column).

So what gives?

Continue reading

If you’re running a business that focuses both on developing solutions from the ground-up or that focuses on implementing a custom solution in the context of pre-existing projects (or maybe both), then you’ve likely – at some point – been in the situation of inheriting WordPress projects.

Tackling projects from either handle brings its set of challenges – most of them welcome  – but it seems to be far more common place for people to complain about working with a pre-existing codebase.

It’s not that I don’t get that feeling, but I do think there’s a level of immaturity in doing that. On the one hand, yes some codebases are outright terrible. But then some codebases aren’t that bad. In fact, I’d argue they are just a little bit different from how you’d develop it.

This is a case in which standards come into play, but I digress on this for now.

So let’s say you’re inheriting WordPress projects and you’re not particularly stoked about the codebase with which you’re working. How is it that you can still enjoy the work that you’re doing without feeling like you need to critique every aspect of whatever it is with which you’re dealing?

Continue reading