Activating ithemes plugin creates generates an error

bedrock
1

Hi there,

Recently, I have faced an issue when activating ithemes plugin which generates the following
Got error 'PHP message: PHP Fatal error: Uncaught Roots\\WPConfig\\Exceptions\\ConstantAlreadyDefinedException: Aborted trying to redefine constant 'DISALLOW_FILE_EDIT'.define(‘DISALLOW_FILE_EDIT’, …) has already been occurred elsewhere.

This could be solved by editing config/application.php and commenting or deleting line 102 but I am not sure if it’s the right way for future updates of bedrock.
Maybe adding a check in that file would be better and author’s plugin should also do the same.

What do you guys recommend ?

Regards

2

I encountered the same problem a few times. I guess it makes sense to remove that line if you already know that you are going to use i-themes (which does the same thing)

By the way, you may also want to look at this post: Roots updates from March, Bud is 30% faster. It mentions wp secure all an alternative to plugins such as ithemes. I haven’t tried it myself though.

3

I agree with you but the only thing that concerns me is that I will have to do it everytime I create a project.
To avoid that, I created a fork and I will remove this line inside my fork.

4

I am not sure why these settings are kinda forced on production. It would think it makes more sense to change these lines in application.php:

// Disable the plugin and theme file editor in the admin
Config::define('DISALLOW_FILE_EDIT', true);
// Disable plugin and theme updates and installation from the admin
Config::define('DISALLOW_FILE_MODS', true);

to:

Config::define('DISALLOW_FILE_EDIT', env('DISALLOW_FILE_EDIT') ?: true);
Config::define('DISALLOW_FILE_MODS',  env('DISALLOW_FILE_MODS') ?: true);

so you can control the behaviour from your .env files

But maybe there is a reason for not doing so

5

This is also possible to do it this way even if this is already changeable in environment config file like production.php.
I try to keep as much as possible the sensitive data such as password in .env file and put the rest in environment config file.
In this case, the issue is happening because of ithemes plugin which tries to define a constant that already exists even if I believe that both sides should check before trying to define a constant

6

I use iThemes too, and I always thought that the WordPress wp-config.php wasn’t applied yet when the config::apply() was run. So while roots/wp-config helps prevent issues with double defines it was missing the one added by iThemes.

I removed the line in my applications.php too.

But reading through your error it got me looking, the exception thrown is Roots\\WPConfig\\Exceptions\\ConstantAlreadyDefinedException which means that it WAS defined already when roots/wp-config had applied the config map.

this makes me think we might be able to catch and ignore the exception when it is coming from ithemes. no?

7

I also have this problem on my projects and fixed it by defining it like this in my application.php:

if (!defined('DISALLOW_FILE_EDIT')) {
	Config::define('DISALLOW_FILE_EDIT', true);
}
8

But doesn’t iThemes add it (sometimes randomly) into the wp-config.php in the web folder?

They don’t use an if(!defined... but I think they should.

I think it adds it on configuration changes, activation, and maybe updates.

9

Yes it does, so instead of using the DISALLOW_FILE_EDIT in application.php, it will use the one added by iThemes in wp-config.php, but that way at least your site won’t break :slight_smile:

10

That’s also another solution to solve this issue and I believe that this check should also be done for other constant defined in application.php maybe like DISALLOW_FILE_MOD.
I personally commented out the line.

Should an issue be raised on github for this ?