One of the more common PHP functions developers use in order to make remote requests is file_get_contents. The function makes it easy to send requests to another URL and then handle the response.
It’s especially handy if you need to make an Ajax request to another site but aren’t allowed to do so from the client-side because of cross-site-scripting.
That said, cURL is often a better option than file_get_contents because it gives you far more control over the options that are set when setting up the request to be made. file_get_contents simply doesn’t do that. Instead, it provides enough options for making simple GET requests.
For these reasons, it’s often a good idea to use cURL when you need to provide a more fine-tuned request. Even more so, it’s helpful to have all of the functionality wrapped up in a utility function you can drop in your project whenever you need it.
jQuery since its included as part of core as is the choice library for the front-end
Backbone since its also included as part of core and is used in features like the Media Uploader
Anyway, one of the things I’ve stumbled across when writing my own code or in performing code audits is the way in which some developers attempt to get values of multiple elements in jQuery. Though there are some ways that work, there are always some options better than others.
A little over a week ago, I shared a post about one way I try to work well with designers when working with WordPress. That is, I talked about how of stubbing out files they may need in order to get their work done.
As mentioned in the post:
There are plenty of tips that can be shared and I’ll probably share more in the future.
So I thought I’d try to make this a regular thing by continuing to share some of the things I’ve learned – both what to do and what not to do – when partnering with designers or I’ve learned when simply working alone or with others on WordPress projects.
And one of the things I’ve found to be helpful is to provide helper functions when needing to call into more complicated functionality.
If you’re a developer working in WordPress, then odds are you’ve spent time working with designers. Assuming you’re working with a good designer, it can be a lot of fun.
I think we’ve all had our share of experiences both good and bad (and luckily I’m at a point where I’m working with some really great designers), but I think there are things we – as developers – can do to help make our designers jobs a little bit easier.
This is a follow-up post to one that I originally wrote in December 2012. Be sure to read it, as well!
Months ago, I wrote a post on some of my preferred HTML Code Styles during which I shared two specific things that I do whenever I am writing markup.
Specifically, I do the following things:
Comment Terminating Tags
Underscore Class Names
When it comes to writing code, there are always going to be standards – well, at least there should be – that depend on the proverbial sandbox in which we’re playing.
These standards will outline certain things that we should do, but there are always bound to be gray areas. Case in point: I know people have often commented (no pun intended) that they aren’t a fan of the way that I terminate certain closing blocks with comments such as `// end if` or `// end while` or `// end class`.
Which is completely fine – to me, that’s an example of a gray area that gives us, as developers, room for implementing our own unique styles. But then there are others that really should be reconsidered.
And that’s what I’ve had to do with some of my markup styles.