Author: Tom (Page 276 of 428)

Two Solutions for “JavaScript Reference Error Is Not Defined”

April 17, 2014 / Tom / 0 Comments

If you’re working on any type of web site or web application that has any other dependencies either for its front-end framework – such as Bootstrap and Foundation – or from the site’s foundation – such as Rails or WordPress – there’s a chance that your own JavaScript sources may result in the following:

Reference Error [variable] is not defined.

In some cases, this can be simply referring to a variable that isn’t defined (perhaps the most popular is when jQuery’s $ function has been dereferenced and you’re trying to use $) and simply needs a definition.

But, in other cases, there are times where it may not be as simple.

A Dilemma: Hiding Elements with The WordPress Theme Customizer

April 16, 2014 / Tom / 0 Comments

When it comes to working with the WordPress Theme Customizer, one of the options that you’re likely to see in other themes (or that you’re likely to introduce in your own themes) is an option that is responsible for toggling the visibility of an element.

For example, if a text box is empty, you may want to hide an element. Or, more simply, perhaps a user will need to click on an checkbox to toggle whether or not to display an element.

But this presents a dilemma: Either we can send all of the information to the browser and control its visibility using a class name, or we can send less code to the browser but lose a smooth user experience when using the Theme Customizer.

Steps To Writing Clean WordPress Code

April 15, 2014 / Tom / 0 Comments

I’d like to think that one of the things that most good developers continually strive for is writing the cleanest, most maintainable code possible.

Personally, I don’t know if there is an actual point at which you reach it – it’s the whole journey-not-a-destination thing – but that doesn’t mean that we shouldn’t continually aim to get better at what we do. In our case, that’s writing clean WordPress code.

The thing is, there’s only so far you can get on your own. You can read a number of books, follow the advice of some high profile programmers, and read as much of the “academic” material that you can get your hands on – and I think all of the above is great – but, at the same time, it only goes so far.

To that end, I think it’s worth seeking out other people in your same field to help provide some level of mentorship on how it relates to writing clean code because here’s the thing:

As much material as we can read written by other people, nothing beats interacting with those who are writing code in the same language(s) for the same APIs under the same coding standards and who are farther along than you in experience.

How To Define a New WordPress Cron Schedule

April 14, 2014 / Tom / 0 Comments

Last year, I shared how to properly setup a WordPress cron job in which I walked through the process of defining a cron job in the operating system so that a job fires as a true scheduled task (rather than the faux tasks that WordPress provides).

This isn’t to say that the native WordPress scheduled tasks are bad – they just may not work as expected for those who are used to native cron jobs.

Another limitation of the the WordPress scheduling system is that it defines only a handful of intervals in which your tasks may run. These include:

`hourly`
`daily`
`twicedaily`

And these are fine for a lot of tasks, but if you’re looking to define a new WordPress cron schedule, you’ll need to define a custom filter.

The Importance of Using Domain Language in WordPress

April 11, 2014 / Tom / 0 Comments

In building software – especially at the enterprise level – one phrase that’s used to describe the work that goes into understanding what all needs to make up an application is that of the “problem space” or the “problem domain.”

This is important because part of the process of understanding the problem domain is learning the language, the terminology, and the concepts that go into building an application.

For example, say you’re building a job board. You’re likely to have something like:

Job Posts
Resumes
Recruiters
Employers
Employees
Candidates
…and so on

These ideas are then taken and ultimately converted into code.

Sometimes, developers will use the terminology associated with the problem domain (and this is part of domain-driven design) in their code; other times, the problem may get solved but the code may not completely reflect the problem space at the code level.

At any rate, one of the things that I see – as designers and/or developers – doing is using terminology that is more frequently associated with how we view WordPress than how users do.