It seems odd to hard-code these settings, given they are a widely-used UI option that are often disabled during development by site builders who are not necessarily sysads (and do not manage their Aegir installs / site config php).

omega8cc has worked around this in Barracuda / Octopus by conditionally removing the hard-code if "dev" is found anywhere in any of a site's aliases. This is a good workaround, but I think the root problem can probably be removed without any issues.

Comments

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Only cache is hardcoded as enabled in Aegir, while css/js optimization doesn't. This extended hardcoding is used only in Barracuda/Octopus. Also, I disagree with you, at least cache enabled by default and hardcoded is a good idea for any production system and you can still very easily disable it on the site's level with extra included file or at global.inc level.

eft’s picture

eft CreditAttribution: eft commented

The trouble is though that if you set the page cache with a variable in global.inc or local.settings.php then you are still hard-coding the setting.

I agree that it would seem better to deal with the root problem (by removing the line $conf['cache'] = 1; from $AEGIR_HOME/.drush/provision/platform/provision_drupal_settings.tpl.php). Site administrators could still determine whether to institute a policy whereby page cache is hard coded for specific sites (via local.settings.php) or all sites (via global.inc).

Hopefully, the Aegir core dev team can shed some more light on the underlying rationale for the current policy.

adrinux’s picture

adrinux CreditAttribution: adrinux commented

Just a suggestion: how about 'soft' coding it in global.inc? It could be on by default but easily commented out by those that don't like it. Would seem a viable compromise.

I wouldn't want to lose the feature.

But there's potential to do lots of other useful stuff in global.inc, perhaps other features could be added there, commented out by default?

eft’s picture

eft CreditAttribution: eft commented

adrinux: that seems like a good compromise to me

obrienmd’s picture

obrienmd CreditAttribution: obrienmd commented
Title: Stop hard-coding page cache, css and js aggregation » Stop hard-coding page cache

Changing title to be more accurate as per omega8cc / #1. I still don't understand why this needs to be hard-coded, as it's a setting readily available in the Drupal UI. Perhaps a change to the default, but hard-coding it? No need to strong arm (pun intended) a setting like this for a tool with as many use cases as Aegir.

As I assume I will be handily outvoted by smarter/more important people, I think adrinux's suggestion would be a happy medium :)

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Forced settings for cache enabled is (and always was) a good idea and practice for Aegir used as a hosting environment for obvious performance and system stability reasons. You can think it is not that important to hardcode it only when you are the only admin for all hosted sites, but you will learn immediately how critical it is when you will have many hosted sites admins, who will just "forgot" to follow good practices.

Of course there is no difference if this is done in settings.php or global.inc, but since it was always in the settings.php template while global.inc is by default empty and never touched on upgrade, changing the current location of this hardcoded settings would require to not only move it from settings.php template to global.inc but also writing some upgrade path to parse existing global.inc. And probably it could be not enough, because all existing installs with global.inc already used could still overwrite their global.inc and didn't realize they should add hardcoded cache settings there to get the previous default still working.

In my opinion, it is not worth the trouble while caching enabled/hardcoded by default is a good default for production systems. I you don't like it, why not to change it in your global.inc? Currently Aegir will not touch that file, so your custom default there will be permanent.

obrienmd’s picture

obrienmd CreditAttribution: obrienmd commented

Note: I am perfectly happy w/ modifying my global.inc... Playing devil's advocate, with no offense intended:

Should Aegir hard-code disabling the PHP Input Filter module? Lazy and/or less-than-knowledgeable site builders often abuse this with major performance/stability repercussions. Your statement applies quite well: "This doesn't matter too much when you are the only admin for all hosted sites, but you will learn immediately how critical it is when you will have many hosted sites admins, who will just 'forgot' to follow good practices".

Are the majority of Aegir users Drupal shops or major hosting providers? It seems even if you accept the argument that Aegir should be enforcing good practice of something typically handled completely in the Drupal UI, it really only applies to fairly large hosting providers (and Barracuda could solve this problem in a custom global.inc).

One more "you're so very wrong" from omega8cc and I will walk away from this issue with my tail between my legs :)

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

Note: I'm sharing my private opinion only (and some hosting experience) but I don't think or intend to say you are wrong etc. I'm only telling you, that changing this behavior now, when all Aegir installs don't expect it moved from settings.php template to global.inc could cause more problems and complains than it is worth of (unless you will agree to answer them all personally :p) Again, it is just my private opinion only! :)

obrienmd’s picture

obrienmd CreditAttribution: obrienmd commented

I will defer to the more experienced on this one. My opinion is on the record, and I'll happily modify my global.inc for the time being.

:)

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Issue tags: +aegirWTF

I agree this is a policy decision. I would welcome a patch that would let the admin decide, and yes, that could be just dropping the setting from settings.php so that admins (and users!) can set their own policy through global.inc (or the Drupal UI!!!).

This is actually a major Aegir WTF when you can't modify the cache settings within the Drupal install. There's no feedback on why it happens, it just looks like a bug. I don't think it's a good default behavior.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented

Could this just be another option in the site settings form? Have a sensible global default that can be changed also and then just push it through the system to the settings.php.

Everyone wins?

papile’s picture

papile CreditAttribution: papile commented

I disagree too with hard-coding a core Drupal setting and it is an unexpected behavior regardless of the reason why it is done. The site admin should have the opinion of whether they want to allow disabling cache. If you want to be opinionated with your code, you can detect cache is disabled and display a message warning that their server will blow up. Or: The host master can select a setting that they are not allowing sites to be put in uncached mode and give a message to the users that the admin has disabled turning cache off when they attempt to do so. The "dev" contained in host name shutting off cache is a hack and is also not very clear. I understand that the developers think that cache being on is definitely something that is good and I agree. However there are better ways to express that to the user.

vadym.kononenko’s picture

vadym.kononenko CreditAttribution: vadym.kononenko commented

I agree that it is very unexpected behavior. Several our sites had worked wrong with this option, and we couldn't understood whats wrong until I've found this "feature".

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

#11 is a good idea.

Steven Jones’s picture

Steven Jones CreditAttribution: Steven Jones commented

I'm wondering if this is actually part of a bigger: 'Set these variables to these values' module for Aegir, that can set any variables value from the front-end. I say this because I've just pumped 4 variables into our sites, and the code is very repetitive.

I shall think on this one.

obrienmd’s picture

obrienmd CreditAttribution: obrienmd commented

Steven - Yes, very useful idea... Would love to hear what you come up with!

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Argh, no, I don't want to start adding arbitrary fields to form UIs in the frontend to handle these cases.

I tried that once myself and I got shot down (configurable username for uid 1).

I'm not sure I'd reject a patch that did it, but I am 100% convinced that as soon as things like that were present in the site form, we'd have people trying to push in module/theme manager/installer interfaces in about 2.5 minutes.

For the record I agree: this should not be hardcoded in our settings.php template - there is no reason to do so.

Yes, it's a reasonable default. No, it should not be forced on either way.

I don't believe moving this into the global.inc would cause upgrade path woes - this is just a setting in the settings.php after all, and PHP wouldn't really care whether it was in the template or being include()'d.

My opinion:

1) let's move this out of the template, into global.inc, leaving it enabled,
2) comment the code in global.inc + an announcement in the next release notes / on the mailing list + in a 'general Aegirisms' documentation notebook page that it's now moved into global.inc and can be switched off there across all sites,
3) also note that specific sites can reenable/disable it in the settings.php (even though it can be a database/Drupal setting through the admin interface) through their local.settings.php.

In doing so, we won't break the upgrade path, and we hand back control to the users to do what they like with it.

Such a setting in global.inc (with code comments) is likely to have a nice side-effect of making people aware of the purpose of that file and what can be done with it. Anything that takes the mystery out of 'how do I do this with Aegir' or 'why the feck does Aegir do this' will only be a good thing.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

To add to the general 'variable manager' idea for sites, I just want it clear that I don't say not to do it, but that I think we need to stop thinking of the Aegir UI as a penetrating 'bulk changer' tool to manipulate site databases directly.

Especially realise that just setting variables in the frontend, to get to the backend, would currently have to go via way of a task. It would be faster to just drop it in the backend yourself by way of our APIs/include files.

I'd like to see people make less use of the frontend and more of the backend to handle these things, and people start seeing more that the frontend is only a convenient interface to send instructions to the backend. The frontend is cluttered enough with so much stuff and our site form so slow, I feel it should stick to just being about deploying builds/sites/handling upgrades efficiently and do nothing else.

There are a few exceptions, such as handling backups, and package/schema info for upgrade purposes, which get recorded in the Aegir db: in other words, the frontend UI should only be used when it's required to add/change/remove data from the Aegir db itself. A lot of tasks don't require that (and we don't store a site's current db name in the Aegir db at all). We don't need to store info about what variables exist for our sites, in the Aegir db, so it shouldn't be in the frontend either (in my opinion).

The only time we really mess directly with a site's db is on an upgrade/Migrate, and I think that's a good philosophy to stick to. To quote Adrian, 'we are not a GUI for Drush' :)

eft’s picture

eft CreditAttribution: eft commented

@mig5 - valid points.

With respect to #17 3) we could refer to the Injecting into settings.php documentation page. It might also be worth emphasizing the precedence of each method of configuring site settings ie global.inc > local.settings.php > settings.php (if retained) > drupal site GUI.

sime’s picture

sime
any/any
Location Melbourne
CreditAttribution: sime commented

With this setting, Aegir takes away a Drupal feature. Admins are unable control caching through the UI. There is simply no way to do it.
-- apply it to global.inc in a switch - forces it until someone with ssh can change it - BAD
-- add a local.settings.php - forces it to be on until someone with ssh can change it - BAD
-- remove it from settings.php - that gets rebuilt by Aegir yes? - BAD

If Aegir wants to have a feature to turn on caching for every site, apply the change to the database please. Or put it in the global.inc with instructions on how to disabled and implement site by site caching.

Please don't hard-code conf values. That should be the site-builder's decision. :)

sime’s picture

sime
any/any
Location Melbourne
CreditAttribution: sime commented

Oh, this has been in the code since at least mid-2008

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Component: Code » Documentation
Category: feature » task
Status: Active » Needs work

I've removed the $conf['cache'] = 1 from settings.php in HEAD.

Leaving this open as a Documentation task so that we remember to mention it in the release notes.

obrienmd’s picture

obrienmd CreditAttribution: obrienmd commented

Thanks, mig5!

sime’s picture

sime
any/any
Location Melbourne
CreditAttribution: sime commented

Please note the implication of this change. The next update to Aegir will possibly turn off your anonymous caching for all your sites (the next time settings.php is rewritten). You can solve this in advance by:
-- setting cache = true in global.inc, or
-- setting it in the database(s).

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

(or in the local.settings.php) :)

thanks for the primer! we'll use that

P.S am I the only one who sees the irony of defining a performance tweak TRUE/FALSE in the *database*? :)

sime’s picture

sime
any/any
Location Melbourne
CreditAttribution: sime commented

If you are building a site you often need to turn this feature on and off. Not all website builders, whose sites are managed by aegir, will be (or have ready access to) sysadmins.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Project: Hostmaster (Aegir) » Provision
Version: 6.x-0.4-alpha3 »

This issue belongs to Provision queue, probably.

AntiNSA’s picture

AntiNSA CreditAttribution: AntiNSA commented

So what is the final decision and current status? How do we enable/disable hard coded caches? How can re return cache control to drupal interface?

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The current status and final decision are all stated in the thread, and I have already given you advice on what to do in IRC.

Patch from git and/or use local.settings.php or just the interface in your site.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Title: Stop hard-coding page cache » document that we stopped hard-coding page cache
Priority: Normal » Critical

marking critical as a documentation task so we don't miss it in the relnotes. changing the title too.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs work » Fixed

This has been accounted for in the release notes we're writing now.

Status: Fixed » Closed (fixed)
Issue tags: -aegirWTF

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +aegirWTF

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.

  • Commit d907779 on prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by mig5: 
    #984396 remove hardcoded cache setting to avoid much DrupalDrama