ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Define constants for easy development

November 23, 2018 · 20:43 · Nodws

No need to remember long paths or infinitely add ../../../

//Get theme dir
define('td', get_bloginfo('template_directory').'/' );
//Get home dir
define('hd', esc_url(home_url( '/' )));
//Get temes path
define('tp', get_template_directory('').'/');
//Get home path
define('hp', get_home_path());

+1 more
Difficulty: Moderate
Request: Add feature
  • //Get home path
    define('hp', ABSPATH);
Code Potent

I use this technique in my plugins for super-fast path completions in my IDE, so I'm definitely giving this an upvote. But, a few things... Constants should:

1) be ALL_CAPS separated by underscores
2) be semantic and meaningful, without acronyms
3) omit trailing slashes (more efficient to add than subtract a slash at runtime)

I'd also like to see const used over define(), where feasible.

This is how I implement constants for plugins:

James Nylen

If ABSPATH is too long to type, then you need to get an editor that supports code completion.

Daniele Scasciafratte

I agree with James, there are already functions for them and you can do as you want in your theme/plugin like variables in your classes.

Mike Schinkel

On one hand I would really like to see a robust set of standard predefined values in ClassicPress.

When I was knew to WordPress I was already a professional programmer but a lot of my learning time was learning where to find all these values, and I think having them predefined would be a huge benefit for learning and code consistency across developers (which I happen to think is next to godliness.)

That said, PHP constants are a nightmare for unit testing and code organization, and I know that @nylen had said he'd like to move away from PHP constants and provide standard values in a different manner.

So my vote is "No" for constants but "Yes" for these type of values predefined in some standard way.

James Nylen

> learning and code consistency across developers (which I happen to think is next to godliness.)

This is a fair point. You are hinting at a larger API re-imagining here, and defining variables like td, hd, tp, hp is not an improvement in this regard.

Good names are meaningful without being too long, and they are internally consistent across the application. This is very hard to achieve - it usually takes thinking of a system as a whole rather than evolving it piece-by-piece as needed.

See also:

Mike Schinkel

@nylen - Absolutely. Completely agree with all those points.

Pedro de Carvalho

i have to say those names are meaningless. If any to be added, i would prefer them being instantiated with lower level code. Otherwise, devs will just not use it if they have faster calls.