Would like the ability to enable twig debugging options (normally set in the settings.php) to be in the UI.

Comments

tlattimore’s picture

Where would this config page go? Under admin/config/development/twig maybe?

chrisjlee’s picture

Yeah that seems like that would make the most sense. That would be where i would look first.

tlattimore’s picture

Assigned: Unassigned » tlattimore

I'll take a stab at this.

tlattimore’s picture

Assigned: tlattimore » Unassigned
Issue summary: View changes
Cottser’s picture

Component: system.module » theme system
Issue tags: +Twig
webchick’s picture

Category: Feature request » Task
Priority: Normal » Major

I'd like to promote this to a major task from a feature request. Wanting to customize the look and feel of your site is basically the first or second thing all Drupal folks are going to want to do. Telling people more familiar with markup than PHP who just downloaded a CMS to start digging around in a PHP configuration configuration file and editing it sounds like not a great intro to Drupal 8 theming. ;)

Cottser’s picture

@mdrummond mentioned the idea of putting this somewhere under Appearance, maybe /admin/appearance/settings?

If we think about easing the transition into Drupal theming then exposing this in the UI might make sense. @mdrummond and I chatted briefly about this in IRC and Marc brought up the site builder and their introduction to the theme system.

mortendk’s picture

i know were not supposed to do +1 on issues but this is a + 100 ;)

And yes put it in the theme settings where it belongs :)

forestmars’s picture

This really belongs under config/development/twig, not so much theme settings (imo.)

forestmars’s picture

Also, if we're going to put debug in UI settings, is there a good reason not to just go ahead and include cache and auto-reload?

Cottser’s picture

They are almost never needed so IMO no reason to expose them in the UI. twig_debug includes twig_auto_reload, and I've yet to have a need disable twig_cache.

https://drupal.org/node/1903374

Berdir’s picture

This is a setting. Changing those requires write access to settings.php, something we even verify on hook_requirements() to not have.

So, to make the UI work, you first need to go the file system, make the file writable, then go back to the UI and change the setting. That doesn't make much sense.

=> Instead, why not simply have a UI that displays the current settings and says, go to settings.php to change it? We're doing this now with the file public path too.

Cottser’s picture

That seems quite reasonable to me. Thanks for weighing in @Berdir!

Cottser’s picture

Worth noting that the landscape here has changed somewhat since we have example.settings.local.php which does other helpful things for people working in the theme layer, most notably disabling the render cache.

dawehner’s picture

Now that this is part of the services.yml file it would be at least somehow possible to implement it.

Cottser’s picture

@dawehner - would that be by reading/writing the settings in services.yml or some other way?

Berdir’s picture

I'm not sure how @dawehner sees it, but we can't any better or worse into the services.yml than we did to settings.php. And not sure about the alternative, that would require a ServiceProvider that alters the container and reads those values directly from configuration, but that is a) very ugly at such a low bootstrap level and b) how do you know if it hasn't been overwritten in services.yml and which one wins?

Cottser’s picture

joelpittet’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed
Issue tags: -Needs beta evaluation

Moving to 8.1.x since we are in RC

dawehner’s picture

I'm not sure how @dawehner sees it, but we can't any better or worse into the services.yml than we did to settings.php. And not sure about the alternative, that would require a ServiceProvider that alters the container and reads those values directly from configuration, but that is a) very ugly at such a low bootstrap level and b) how do you know if it hasn't been overwritten in services.yml and which one wins?

Well, they how I see it is to store the data temporarily so it can be accessed during the container rebuild. For example what you could do is to store the configuration is the state subsystem in the form, then trigger a container rebuild and access the information from there.

Well I think you would simply assume that the UI wins, I'm sorry, but this option simply never makes sense in production, so people should do the right things.

joelpittet’s picture

Status: Postponed » Active

Unpostponing, 8.1.x is in sync with 8.0.x

dawehner’s picture

Category: Task » Feature request

IMHO this is a feature.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.