This has the effect of forum translations not working until you go to the admin page and hit submit. There are a few dozen variables like this actually. 27 upon install are set and 75 after visiting the admin page and submitting.

Should we generalize this bug to say that we need to store these defaults in one place, and set all of them once? Also, why are we setting the variables, if we are going to variable_get them later anyway?

-J

CommentFileSizeAuthor
forum_pattern_not_setup.patch761 bytesJacobSingh

Comments

greggles’s picture

I agree, we should generalize this bug to say that we need to store these defaults in one place, and set all of them once.

Setting them on install is a simple solution to the more complex problem of figuring out what the default really should be in the variable_gets. Add1sun contributed that patch about 2+ years ago and it just hasn't been updated since.

JacobSingh’s picture

#145164: DX: Use hook_variable_info to declare variables and defaults

One of the saddest stories in Drupal :) Hopefully will make it in D8.

At any rate, I often build a variable registry in my modules. which sucks, but does the trick. Just something to namespace all my vars and store the defaults in one place.

So pathauto_variable_get('forum_pattern');

function pathauto_variable_get($name, $override = NULL) {
$defaults = pathauto_variable_defaults();
$default = $override ? $override : defaults[$name];
variable_get('pathauto_' . $name, $default);
}

Something like that. I acknowledge the hack-factor, but I think declaring defaults in multiple places and writing them to disk when they don't need to be stored there (like we do currently) is far far worse.

What thinks you?

dave reid’s picture

Status: Needs review » Needs work

[vocabulary:name] token should actually be [term:vocabulary] as per the recent fixes to taxonomy tokens.

dave reid’s picture

Status: Needs work » Closed (duplicate)

I caught this today, but I filed #863980: Stop special-casing the forum vocabulary to fix this problem.