Tag Archives: PHP

Mastering the use of PHP conditionals

No set of control structures is more pervasive in programming than if, elseif and else. With a few exceptions, you’ll use at least one per function or method that you write. There’s just no way around it.

But conditionals (that’s what we call these control structures) fit in the “easy to learn, hard to master” category. In fact, they’re so easy to use that you can develop some bad habits around them. (This is also a problem with loops.) This can lead to code that’s complex and hard to read or even test.

That said, it’s possible to develop good programming habits with conditionals. This is what this article will try to help you with. We’ll go over some programming techniques that can help make conditionals more manageable.

Continue reading Mastering the use of PHP conditionals

PHP strings and how to format them

Strings have always been an integral part of the programming world. We use them so much because they do something that’s almost impossible to do with other data types. They allow our code to communicate with others.

The definition of “others” is quite wide in this context. Others can be as straightforward as someone using your WordPress plugin. But it can also be more abstract like a browser reading HTML code generated by PHP. They are both a third party who interacts with strings generated by your code.

Sometimes, these strings are simple and used as is. But more often than not, these strings need to be dynamic. They need to adapt to what’s going on inside your code.

This latter one is why it’s important to have a good understanding of what you can do with strings in PHP. That’s because there are countless ways that you might want to alter a string. For example, you could have a string change based on certain conditions. Or you could insert one or more variables into it.

For this article, we’re going to focus on how you can format a string. There are a lot of built-in helper functions for strings in PHP. We’ll look at the ones that can help you achieve that goal.

Continue reading PHP strings and how to format them

Using inheritance with WordPress

As a WordPress developer, you’re always looking for ways to better reuse your code between projects. Your time is valuable and you don’t want to reinvent the wheel each time you start a new project.

Object-oriented programming can help you with that. In a previous post, I covered why you should learn it. Now it’s time to take things further by going over the main feature for code reuse. You’ve probably heard about it before. It’s called “inheritance“.

Continue reading Using inheritance with WordPress

The first thing you should learn from object-oriented programming

You’ve decided to learn object-oriented programming, but you don’t know where to start. Object-oriented programming has so many concepts and features. The whole thing can feel overwhelming at times. Let’s help you get started on the right foot.

What’s a great place to start? With the feature that you’ll associate the most with object-oriented programming. It’s called encapsulation. Most modern programming languages support encapsulation using classes.

Continue reading The first thing you should learn from object-oriented programming

Why object-oriented programming is your next step as a WordPress developer

You’re a WordPress developer. You might have a few plugins under your belt or a theme or two. You build WordPress sites for clients or just for yourself. You’ve heard of object-oriented programming, but, each time you look into it, it makes no sense!

You tell yourself object-oriented programming isn’t useful or worth the trouble. The goal of this article is to focus on explaining this value to you. At the end of this article, you should have a clear understanding of why you should learn it.

Continue reading Why object-oriented programming is your next step as a WordPress developer

Single responsibility principle, WordPress and You

For WordPress developers, it can be hard to improve your PHP skills. You lack the resources or tutorials to drive home these concepts. This happened just a few weeks ago when Nathaniel asked for help with his Stack Overflow question.

He was looking for help applying the single responsibility principle with WordPress. I sent him a bunch of replies but closed off saying I needed to write a post about it. This article is a detailed explanation of my thoughts following that conversation.

As WordPress developer, you might have started working with or looking into object-oriented programming. Maybe you even heard of something called SOLID.

As a whole, SOLID can be an intimidating topic. But the single responsibility principle is just one part of it (it’s the ‘S’ in SOLID). That makes it a more manageable topic to discuss and help you with.

At the end of this article, you should have a better understanding of it. You can also use the provided code samples in your own plugins and themes.

Continue reading Single responsibility principle, WordPress and You

Making you proud

So yesterday I wrote about my first day doing Justin Jackson’s growing an email list to 1,000 class and the struggle of first time bootstrappers to build an audience.

The class continues

Today, we have to evaluate who are target audience should be. I think it’s pretty common for most bloggers to start writing about anything. I started talking about health and business topics because that’s what I was working on at the time. The content was also mostly educational. It didn’t help the reader in any way unless you just wanted to learn about health behaviour! By the end of the first iteration of Helthe, it was obvious I didn’t feel like writing about it. You should be passionate about what you write about!

A lot of the advice given is similar to what I had discussed when I started the PHP App Challenge. You should focus on your competitive advantage and the groups you are already part of that have money to spend (important!). I am very involved with WordPress, but I see myself as a PHP programmer more than just a WordPress programmer. So I want to write to programmers, but specifically those that work with PHP.

Another fortuitous discussion

For our homework, we had to come up with a statement to describe our audience and why were choosing them. I was struggling with the why, but then me and Justin started a discussion in the JFDI chatroom where we discussed PHP as a whole. This led to some great insight.

It started with me asking whether I could target programmers and still talk about products. He commented how there isn’t anyone talking about products using PHP or building products with PHP. I actually learned that Mailchimp is built entirely with PHP. This moved on, as it always does, to discuss how PHP is the second-rate citizen of the web. This has been mentioned many times on this blog already and it’s even the key reason I started Helthe.

To make PHP devs proud to be PHP devs

That line came from Justin, but it’s a great cause that any PHP dev can relate too. And just like that, I had my why. It’s a great why too. I can’t think of a week where I didn’t see this come up in conversation either in person or on the web.

I think it is partially why the community strives to do so much. There are so many cool projects going on and great developers working on them. I would say in the past 3 years, there has never been a day where I am not proud to be a PHP dev.

So following this new yet not so new insight, I finalized my homework statement for day 2.

“My name is Carl Alexander. The audience I am choosing is programmers who are using PHP, because PHP is awesome and we should be proud of using it.”

So things are shaping up

There’s a bit more of a mission statement around what this mailing list is going to be about. If you’ve liked what I have been writing, you can subscribe to my mailing list here! You can also keep checking the blog every day if that’s your thing!

Why it is only PHP

Looking for an update on what I did yesterday? Well I did NOTHING. I felt quite bad about it, but if there’s something my gym habit has taught me is that you can’t be perfect every day. But today I was ready to get things done!

It is worth noting that it is the last day to work on your roadmap for Week of Hustle. Tomorrow, you have to ship things out so I was determined to get through the rest of it.

A week ago by the campfire

Last sunday following the publication of my roadmap, I had a discussion in the JFDI campfire chat room with Andy Parkinson about Helthe and what the service was. The important part of the conversation is found below.

Campfire ChatThe main takeaway that I took is that I needed to really double down on what it meant to the user to have a solution for PHP. The other popular languages at the moment tend to have one dominant framework (Django for Python and Rails for Ruby), but that’s not the case for PHP and that needs to be better explained.

PHP is 80% of the web

PHP is so prevalent for many reasons, but the important point is that PHP is represented by more than just a framework. It is used to run web dominant CMSes and E-Commerce platforms as well as various frameworks so it’s not realistic to expect one PHP library to be adequate for each. I definitely don’t believe it is. And that’s where I draw my line.

WordPress is the best example of that. I already did an exhaustive analysis of WordPress errors and how they are handled. A regular PHP library would only capture a fraction of the problems that could happen within a WordPress installation. It’s especially complex because WordPress is so defensive in its way of handling problems.

I don’t have an issue with that per say because it makes WordPress very user-friendly which is one of its core values. It does, however, put an increased burden on the programmer who is looking for the cause of problems. This can lead to dangerous practices like cowboy coding because it’s just so hard to know what is going on at times.

We meet again copywriting

With all these ideas swirling in my head, I set to work modifying my marketing site copy.

Now I have a confession to make, whenever I have to do copywriting, I want to go hide somewhere and forget about it. It’s one of the many skills I need to build, but it’s definitely the one that makes me feel the clumsiest. I feel like Fry (Futurama) trying to play the holophor for Leela.

You have well constructed ideas in your head, but you have to put them out there and hope they get shared properly.

Before
Before Screenshot

I wanted to modify the section that discussed the more PHP centric benefits for the user to be more descriptive and explain some of the  issues I brought up earlier in the post. After 4 hours, I got a result I was satisfied with.

After Screenshot
After Screenshot

I do actually think it is an improvement over the old version. I didn’t add the logos because I couldn’t make them look good on the page with the responsive layout so I kept them out. I am curious to know if logos are something you would consider important so let me know in the comments.

I did a small modification to the FAQ to say that the deadline had passed, but I was still working on it.

This goes up tomorrow

I’ll be pushing all this out tomorrow, but will be keeping the work I did on the account creation and API disabled. I’ll be writing up my thoughts on the experience as well.

Keep up with my progress

I have been bad and haven’t sent emails everyday as I should, this is the next thing I want to spend time tackling. I’ll be sending a detailed recap at the end of the project to my mailing list. You can subscribe here. You will also get all the info when things are ready for testing.

A plugin for a rainy day

Moving ahead from our last post, I want to present the beta version of the Helthe WordPress Error Monitoring plugin (available here). The overall goal of the plugin is to offer relevant error monitoring for your production WordPress site.

A debugging tale

When debugging WordPress (or any other programming problem for that matter), what do you usually do? You start using your badass Google-fu to find a solution and, when that fails, you post on support forums, WordPress Answers (Stack Overflow) or another medium, but I am getting ahead of myself.

Before that you need to know what to look for and that’s usually where the problem lies especially with WordPress. Unless you’re dealing with a fatal error (White Screen of Death), WordPress is generally pretty silent about issues. This is by design.

Great experience for the users. Hell for supporting them.

This is plugin is a serious attempt at helping you with that. I have already done a good effort to capture a lot of the known errors (and some new ones as well), but having you use it will help me find additional ways to help you (and find bugs) when you need it the most.

What are you getting?

I don’t plan on doing a feature by feature explanation, but I wanted to highlight a few things that I hope you will find useful.

Leveraging existing plugins

The first thing I did is consolidate some of the good stuff from the Core Control plugin and Deprecated Log Notices which do not seem to be actively worked on anymore. Those were the two plugins I knew that helped for specific problems (let me know if you know others!).

With this, you’ll know if you’re using deprecated functions or calling functions wrong. However, the more interesting element is tracking errors from the HTTP API. Without diving to deep into it, the HTTP API is used by WordPress to handle communications with other web services. This includes wp-cron and errors with the API can be one of the reasons why your cron tasks (like schedule posts) do not run.

Termination Errors

This has the potential to be very useful. Have you ever had AJAX errors with WordPress? Those can be really annoying to solve since you can’t see the output. Well now, anytime WordPress terminates with an error, it will get logged in your error log. I haven’t seen anything like this before so I am hoping that this turns out to be very useful for you.

Image Editor Errors

Another common problem you can encounter is the image editor not working because you’re missing libraries for example. This is a scenario where you really won’t know unless you spend quite a bit of time poking around.

Admin Bar Support

Wondering if there were errors when your page rendered, you’ll be able to see all the errors that were logged by the plugin in the admin bar. This is just for site administrators.

And more!

There’s quite a few more things already under the hood and, as far as I know, there’s nothing another error plugin does that isn’t covered with this current beta version. I am not satisfied yet though. The same way you think of Akismet as your default spam solution, I  want this to be a must-have for any serious WordPress professional.

I can’t do that without your help and feedback. Try it out and create issues whenever you have a production (or even development) problem that wasn’t caught by the plugin and caused you serious pain.

This is available to you for free

You won’t need to sign up for anything and you will get all the errors logged in the PHP error log. I think for this to be truly great for the community, all the features need to be available to everyone.

Where do Helthe fit in this?

Right now the plugin only writes to the PHP error log. When Helthe gets closer to the beta phase, there will be an option to add an API key that will let errors be sent to the service. The purpose of Helthe is to make error monitoring and management more convenient for you so if you’re ok with looking through your error logs then you won’t need anything else to be functional.

As always, feel free to leave a comment below or discuss on Hacker News.

P.S. If you’d like to keep up to date with my progress with Helthe, leave your email below!

[mailchimpsf_form]

Diving into WordPress errors

I would say that the most uncertain aspect of Helthe has been if it could do an amazing job monitoring WordPress errors. In the past, finding out what a problem was in WordPress has been a very frustrating (even table-flipping) experience for myself and a lot of people I have asked about it. So I set out to test and work on this critical assumption.

Can we have good error monitoring in WordPress? Is it already available? Here are my findings after 2 weeks.

What can you get right now?

I started looking through the plugin directory, did some some searching on Google and asked around. The result was some old diagnostic plugins (like Core Control) that do not seem to be supported anymore, but I am pretty sure they still work though.

You also had some error handling libraries (like the one for raygun.io) that would do something with PHP errors/exceptions (like email them to you or send them to their API).

A good start, but hardly what I was looking for. For example, no plugins could tell you if you had no PHP image editing libraries on your server. WordPress won’t give you an error, but you won’t be able to edit images without it. Often requiring you to debug for a few hours locating the issue.

When WordPress has an error, does it make a sound?

WordPress has a very unique philosophy around errors. This isn’t documented anywhere per say, but, if you are interested in reading about it, Nacin and Otto discuss their view on it in this WordPress hacker thread. At the end of the day, everything is a WP_Error and errors are coded defensively.

You will find that no exception are used in the code and that WordPress either has a fatal error (known as the white screen of death) or will fail silently without you being aware of it. The only errors that generally surface are the ones that will impact the user (Access Denied, Could not delete tag, etc.).

Because WordPress uses WP_Errors for everything, you are left to filter which, as a developer, are relevant to you. I asked around if there was documented hooks or filters where important errors might show up. The answer was that no work had been done to document them so I went deep into the core code to check it out.

Diving for answers

I had a tough time getting that answer. There’s no documentation available so I had to go through the code to find all the error handling code myself. If you’re interested in the process, I looked at every is_wp_error call in WordPress (there’s over 300 in 3.6) and then looked at all the functions and objects that were tied to that error check. That’s a lot of core code, but I was able to get a solid grasp of what was going on because of it.

After that I looked at all the wp_die calls (450+ of them in 3.6), this is a bit more tedious, but the idea was to look at what WordPress considered important enough to terminate itself. Often, they were normal reasons, but the goal was to find the error terminations and their cause.

Finally, I did take a look for new WP_Errors, but they ended not as useful as I had hoped. Critical objects do not always handle errors simply returning a new WP_Error. So while I started with this, it ended up the less useful research path.

What does WordPress do with errors?

As Nacin accurately described, there’s roughly 3 informal classification for WP_Errors. After spending a good two weeks looking at all the error code, I would generally agree with the classification given. He doesn’t really explain what WordPress does with each type so I’ll go through them and explain since this is not documented anywhere.

User Notices

These are specific errors that will surface to the user. They are generally the only WP_Errors that make it to a filter. Their purpose is to alert the user and provide feedback when an error relevant to the user occurs. Plugins can hook in and add their own error message as well. However, these errors are superficial and don’t really alert you to problems going on inside WordPress.

Warnings

These are the devious ones. Warnings are errors that do not directly affect the user experience, but prevent non-critical WordPress features from working. Quick examples are failed HTTP requests with the HTTP API and unable to select an image editor, but there’s plenty of others.

The big issue with these errors is that they very rarely make it to a filter. WordPress will simply return from the function and deal with those internally or dismiss them. As a developer or support individual, they are usually the ones you are the most interested in so it’s a real shame you cannot hook into them.

Failures

Failures are errors that need to be dealt with immediate or WordPress will not function. Most of those are found around the update code (plugins, theme and core), you’ll find some around the database code as well. They will either require user intervention or some form of rollback.

So what about the filters and hooks?

Yeah! What about those!? Like I mentioned previously, I wanted to document useful hooks where errors might show up.

I had initially thought I could use the ‘all’ hook (This hook runs for every hook/filter) to check every hook/filter for WP_Errors. You can’t use it that way. Any function using the ‘all’ hook runs before any other hook/filter function regardless of the given priority so if a plugin returns a WP_Error, you would not know. Bummer.

Besides that, there aren’t a lot of hooks or filters that are relevant if you are looking to check for application errors. Like I mentioned previously, WordPress tends to deal with them internally before they even hit a filter.

Where does this leave us?

As a developer, I hope that you have found the information useful so far. It was incredibly useful for me in getting a better sense of what was going internally in WordPress.

So in the next post, I’ll be introducing the Helthe plugin that I have been working on for monitoring WordPress errors and how I dealt with the limitations I have been discussing today.

Feel free to leave a comment below or discuss on Hacker News.

P.S. If you’d like to keep up to date with my progress with Helthe, leave your email below!

[mailchimpsf_form]