Using Constants and Input Fields to Store User Information

One of the advantages of using wp-config.php is how it allows us to add configuration options for our theme or plugin in a central place accessible throughout the entire site or web application; but using wp-config.php assumes a level of technical prowess some don’t have or some don’t want.

Developers, engineers, and the like are used to working with the file to configure all sorts of things:

• Database connection configuration
• Debug configuration
• Security keys
• Site options
• And much more

Option pages, on the other hand, are great if you’re a user who wants to add configuration without having to read any code. Assume for a moment that you’re building something tailored for both the developer-types and those who are used to filling out options pages, clicking buttons, and setting values in text fields. The latter is obviously the more common approach among most users. It’s often easier, if implemented correctly, but what if you want to support both?

Using Constants and Input Fields

Given the situation outlined above, there are a couple of architectural design decisions to make:

1. Determine what takes priority. Is it the values set in WordPress’ configuration file or the values set in the options page?
2. If there are values set in the wp-config.php file, do you automatically populate the options page with those values?
3. How do you store these options in a way that’s universally readable regardless of how they are defined?

Let’s look at each of these before arriving at a final solution.

Universally Acceptable Values

In most cases, we’re going to want to access to the values throughout the site in such a way that we can easily read them using the WordPress API. Having values that can defined by constants or defined by form values implies that there are two places from which to read the input. But why? Centralize the data in a single place, thus making it easily accessible.

To do this, I recommend using the options table. (Yes, you could go with transients, but that’s outside the scope of this article and has technical implications that aren’t relevant to the point I’m trying to make.) If users can define values in both constants and forms, how do we get them into the options table? Specifically, how do we get constants defined in a file into the database that can be read on the frontend and in the administration area of the site?

Let’s start with constants. PHP offers a function called get_defined_constants and it accepts a boolean as an argument such that you can have it organize the constants defined in the application by unique IDs. In the case of WordPress, all user-defined constants look something like this:

From there, we can then determine if the given constant is set and, if so, save it to the options table.

1. This allows us to store the constants in a place that’s readable throughout the site.
2. It also allows us to override the options either via input forms or constants (depending on what you choose).

Here’s a function that does just that:

First, it forces the incoming constant to be uppercased since that’s how constants should be defined. Secondly, the reads user-defined constants into an array. After that, if the constant is defined and it’s set in the $constants['user'] array, then it will write it to the options table.

The full function looks like this:

So this covers the case of making our constants universally acceptable. That is, it reads them, writes them to the database, and then allows us to access them through the get_option function.

But what about working with form fields in a settings page?

Populating the Options Page with Constant Values

This particular section of the article assumes you’ve followed everything above. That is, if something is defined in the constants and it is written in the options table, then it will be accessible in the options page.

This article isn’t focused on writing an options page; so I’m assuming you have familiarity with how they are created through something like:

• add_menu_page
• add_submenu_page
• add_options_page

I’m also assuming that you have a view of sorts set up to read a value. Additionally, let’s assume for a moment that we have a constant, as defined earlier, such as WDS_HOMEPAGE_URL with the value of https://webdevstudios.com. From the function above, we know that if the constant is set and as a value, it will be written into the database using a key such as wds_homepage_url.

This means we can easily access it using the Options API by simply calling get_option( 'acme-homepage-url' ); so our form field may look something like this (assuming you’re using an input element and proper escaping functions):

Thus, if a constant is set, then the value will be added to the input field’s value attribute. Otherwise, it will be empty.

Working with Input Field Values

If, on the other hand, constants aren’t defined and you want to allow the user to specify the options using an administration screen, then you’ll need to implement functionality that will do the following:

1. Enforce security around the page using nonce values and permissions
2. Sanitize the information and serialize it properly
3. Delete the option if it’s an empty string (as we don’t want to clutter the database with empty values)
4. Reload the page once the serialization has happened which should, in turn, also show the value that was just saved

To do this, let’s first add an options page that will introduce the field. This should add a submenu item to the Settings menu that renders a page titled “Theme Settings.”

Next, we’ll need a function that will render the page. This is as easy an calling require_once on a single file (as it’s a good idea to keep templates separate from backend logic):

After that, we’ll populate a basic options page that includes a form element, the input field, and two native WordPress API functions that will allow us to enforce security and save the values. This includes wp_nonce_field and submit_button.

An Important Note

There’s a very important distinction to make here, though, and it should not be missed:

If the value of the option is defined in a constant, it will automatically populate the value of the input field. 

Furthermore, if the constant is defined, it will overwrite whatever you attempt to save. So, in this example, you opt to go with the constants or you opt to go with the input field on the settings page.

Back to Work

From here, we have to:

• Validate the nonce and make sure the user has the proper permissions
• Save (or delete) the data

This can all be achieved through the following functions:

After all of that, we’ll redirect the user back to the page that will include the option they just created.

Note here that although the gist of what we’re doing is captured and described, there are a few functions that I recommend you fully understand not just for this work but for future work, too. These include:

• filter_input
• sanitize_text_field
• wp_unslash
• wp_safe_redirect

Each of these can serve you well in your custom backend WordPress development.

Conclusion

When you’re faced with working with user-defined constants and with user-defined input both of which are stored as values in the database, there are considerations to be made, some of which are outlined in this article. For example:

1. What are you going to prioritize—constants or user input?
2. Will the user input override the constants or, as long as constants are present, will the form be available for use?
3. If the latter is the case, what happens to the constant values defined in wp-config.php?

I’m not attempting to provide a solution on how you should prioritize these things but how to work with each of these methods of input such that you’re enabled to make a decision for your own project. Ultimately, that’s a call that you or you and your team will have to make. But the ability to offer constants for more technical users and form input for other users is not something that has to be a competing goal.

And that’s the goal of what’s outlined above.