Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By adminMN2023 on
Hey,
Need help with a situation.
I don't know what I did wrong.
1 - I loaded Display Suite Module + Extras (it all loads as one)
2 - I *believe* I then clicked "Enable"
Well - the module didn't seem to be working properly, so
3 - I went to the EXTEND page to see if extras was enabled.
4 - Display Suite and it's extras were NOT enabled. They were faded and unchecked. Meaning - they are unable to be enabled.
Can someone tell me what I did wrong?
Thanks!
Comments
It's strange .. normally you
It's strange .. normally you should see the dependencies for a module listed somewhere nearby - which is missing in your screenshot. Most likely not all the dependencies for Display suite module are satisfied. Not sure why that information would be hidden though. So you probably need to install some required modules in order to be able to activate Display suite. How you find out which modules that are I don't know, as something fishy seems to go on in your backend.
I like cookies!
I agree.
I tried to uninstall it and it won't even list as an installed module.
Having never done this before - can I try to manually upload the module folders and see what happens?
Any idea where to look for some back-end discrepancy?
I tried to uninstall it and
Probably means it has never been installed.
Not sure what you mean with that.
I like cookies!
=-=
is https://www.drupal.org/project/layout_plugin included?
Bingo!
As soon as I installed Layout - the Display Suite checkboxes became operable.
Layout for Drupal 8 is an Alpha Release but not Stable nor does it have a shield icon next to the release on it's plugin page.
Rookie question: So should I avoid both Display Suite and Layout because on the insecurity associated with Layout?
I'm not a programmer - so I tend to be more conservative about certain choices.
What would experience or best practices suggest? (just looking for advice as I learn)
Thanks!
Panels & DS both use that
Panels & DS both use that module and both are very well used. It should be more trustworthy than many other modules out there, even without a shield.
Also the number of installations usually gives you a pretty good impression of how well used it is.
I like cookies!
Thanks Stephan! One last question re:DS
I appreciate your advice and appraisal, I didn't think to look at the number of installations - thanks!
The crux of this initial conversation started because I wanted to add H3 tags to field_label. I found a method altering the field.html.twig of the theme, but then I realized I needed to alter that file whenever the theme was upgraded.
Someone suggested Display Suite - hence this post. Which - is akin to bringing a bazooka to a knife fight (might be overkill).
The only reason I like Display suite is because, in my mind until I find out for sure, it removes the formatting from the theme code and puts that control into the DB where it won;t get lost when I upgrade the theme.
Are there other, simpler alternatives I might be overlooking?
Thanks!
I found a method altering the
Normally you use a theme like Bootstrap only as the base theme and create a subtheme of that. Then _normally_ an update of the base theme shouldn't affect your sub theme much. Using a distributed theme directly and changing its code is definitely bad practice. It's as bad as changing the code of a distributed module or core.
I'm a great fan of DS and it's part of every website we build. The obvious alternative is Panels or as you said having lots of template file implementations.
I like cookies!
Commercial theme...
I bought a commercial theme the doesn't work with subthemes. While I would normally pitch a b***h, the author has a good reputation and has been beyond great regarding support understanding I'm a noob. (I do a lot of Joomla and Wordpress work and always create child themes. This is my first foray into Drupal.) I definitely understand where you are coming from, and that's why I am wanting to avoid directly authoring theme files.
I'm still fuzzy on what role Display Suite plays in site building - using it to format pages if the theme does not include a block building tools? I am using native drupal fields and really can't arrange them in my content type. So is that where it would come into play? My fields are just stacked right now.
Display suite is an
Display suite is an abstraction layer above the theme which makes changes very easy for which you normally would either need to write code in your theme.
It also allows you to add any block as a field to the display of an entity, which alone is already very cool. As you can mix content of your node, user, whatever with aggregated lists coming from eg. Views. Other use cases could be: having very specific requirements which CSS classes have to be added to which field or generally being able to dictate the exact HTML output of a field etc.. For each of these tasks you would need to write either code or maybe use Panels.
I like cookies!
Thanks Stefan!
Display suite is an abstraction layer above the theme which makes changes very easy for which you normally would either need to write code in your theme.
Perfect! Thx
The only reason I like
I had a similar need and took a look at Display Suite too. Held off, mostly because it looks complex to administer and another layer I don't need all that much. You might want to look at:
http://www.drupalthemer.org/blog/drupal-8-how-to-ckeditor-custom-styles
It really is an excellent step by step article that will show you how to add styles to ckeditor. I had the same reservation you did ... if I modify the theme then next time Drupal does an update I would overwrite my change. Stefan points out the the approved procedure it to create a derivative theme based on a base theme. I just use Bartik and really didn't want to set up a full derived theme based on it. All the changes I need can be put in one file ... elements.css within Bartik. To avoid overriding my own changes all I do is make a copy of my revised elements.css over in the /themes directory that's at the same "level" as core. When an update comes I just apply it in the fashion I explained in an earlier post replacing the core/themes files with the new Bartik. Elements.css rarely gets changed (as far as I can tell Bartik itself rarely gets changed) but I do a quick compare of /core/bartik/elements.css with my /themes/elements.css and just write my changed version back into the core version unless Bartik has done changes. These are simple files so no complex merging of changes will ever be needed, even if Bartik does add a few.
Drupal's version of ckeditor should have a better way for users to add styles (one that will not be affected by core changes) but it seems to be whistling by the graveyard to suggest changes over in the issues queues so I get by with what I can get by with. (My added styles relate to putting a few flexbox styles in to use for formatting images).
Thanks fkelly. I'm interested
Thanks fkelly. I'm interested to experiment with a "stow-away" style sheet (doing what you did with Bartik). I will have to investigate what my purchased theme does as far as the css structure.
Some of the styling I am dealing with are elements not exposed in the HTML which is why, if I am understanding correctly, the ckeditors custom styles may not help with. But I appreciate new knowledge always.