Define constants for easy development

[discobot]

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());

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Nodws

Vote count: 7

Status: open

Tags:

• request-add-feature
• difficulty-moderate

---

Comments

//Get home path
define(‘hp’, ABSPATH);

~ posted by Nodws

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: Path/URL constants for use in WordPress/ClassicPress plugins to speed IDE autocompletion. · GitHub

~ posted by Code Potent

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

~ posted by James Nylen

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.

~ posted by Daniele Scasciafratte

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.

~ posted by Mike Schinkel

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: Issues · ClassicPress/ClassicPress · GitHub

~ posted by James Nylen

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

~ posted by Mike Schinkel

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.

~ posted by Pedro de Carvalho

[viktor]

Based on the comments on this petition it seems that this is not what the core needs. If there is a need to remember long paths or any other large strings, etc. the two good options are:

• Make sure your editor supports auto completion
• Use text expander apps like BeefText for Windows (I personally use that), AutoKey for Linux, Macs I believe have built-in text expansion support.

[joyously]

IMO, the concept of doing things for easy development is questionable.
Whether it’s a constant (please no!) or a variable, it needs to flexible, so the present function calls are best suited for this.
My use case was years ago, when making a child theme for a popular theme, I needed it to define the constants for having no default header image before the theme’s setup function did its thing which triggered the constants for a header image. But I didn’t want to have to redo all the other setup in the function. I ended up filtering the template directory function so it could pick up the child stuff instead of the parent, just for that. If that were in a constant or unfiltered variable, it would never have worked.
This experience influenced me to write a lot of warnings in theme reviews for authors to not define constants for paths and urls, but to use the functions so they could be filtered. (especially important for themes due to child themes)