I've been busy developing a new module (which I have absolutely loved doing... I must get out more ;-)). However stuck on one of the last parts.

My custom module correctly creates the custom content type it needs, and that all works ok. I just need to know how to create a twig template that can stylise the content type. Note that I've already created a twig template to do this, which lives in the theme I am using, however I need the styling to live in my module somehow!

I created this twig template, and it worked fine to stylise the content type:
whatever_theme/templates/field--node--jssor-content-type.html.twig

However when I install my module on a blank system, this template file doesn't get copied over (which would be bad anyway, as it would be foolish to copy it to every conceivable theme that someone is using, and every subsequent them they install and enable). Therefore it's almost certainly better if my custom module somehow overrides the styling of this new content type, itself.

Any ideas how to do this? Thanks!

I looked at the function-based hooks, but they seemed to apply only to themes from what I saw.

Comments

CatsFromStonehenge’s picture

p.s. I didn't mean this
https://www.drupal.org/docs/8/theming/twig/create-custom-twig-templates-...

This only seems to stylise content generated by the module itself, whereas I need to stylise the content type on it's own URL, e.g. /my_website/node/117

The above URL is not created by my module, so the module can't stylise it directly. However I need to at least have the installation of the module get the styling of this content type set up. This is because the default rendering is awful for the end user in this particular case, even though this isn't normally such a big problem.

CatsFromStonehenge’s picture

The discussion here, seems to be the closest people have got to implementing this:
https://www.drupal.org/node/2499827

Jaypan’s picture

Using a default for content types in Drupal 7 and 8 is probably not the best idea. It hard-codes presentation to the node type, which can cause problems when trying re-order fields through the 'manage display' interface for the fields.

In general, templating nodes should be left to the theme, not something that should be handled by the module. If you have any elements that need to be grouped together or something, you'd be better extending them as pseudo fields in hook_entity_extra_field_info(). This way site builders can re-order fields as they want through the admin interface, then after the fact they can provide a specific node template if they want/need.

CatsFromStonehenge’s picture

Thanks!

The issue is that I'm creating a slider module (trying to make an easy to use one).

I made it so the images for the slides are built as lists of images. I created a content type, that was therefore specified a list of images. I then created a custom block which could reference all these content types. In essence, I thought this was the write place to put the content for the slides. The user interface is all defaulted to making adding and re-ordering images easy.

I initially tried coding it so that people could add a list of images within the block's admin panel (via my module). However I was started to re-invent the wheel... as I ended up trying to re-write some functionality that added content (the images). It still feels right to add the slide images under content.

The reason I wanted to be able to style the content type associated with the module, is because the content type has more to do with the module, than any theme. Basically if you add images to a list of images, then it appears as a list of images, and not a slide. It makes more sense to the user if the content type is displayed as a slide, that can then be added to the slider block.

So it's one of those situations, where I'm trying to get the best trade-offs. To make a good experience for the end-user, I really need to achieve what I originally said. Not doing that, causes other problems elsewhere. The way I mentioned is certainly the best way after weighing up all the options I know.

However I do understand what you're saying. You said 'not something that should be handled by the module'... however the content type, displayed by default themes, makes the content type look confusing to the end user. So something needs to happen. This is one of those situations where I'm currently fighting against the limitations of Drupal. However, knowing Drupal, there'll be a magical way to do it! Which is why I love it... I just need to keep going / learning. Thanks for your input. Hugely appreciated. I'll have a muse over what you've said in more detail.

CatsFromStonehenge’s picture

Hi again

The truth is that your way is probably correct on balance (good introduction on pseudo fields for me here: https://www.webomelette.com/creating-pseudo-fields-drupal-8).

Sometimes I temporarily resist a good idea, because I've put so much work into the slightly wrong solution! However, after reading I think you're right.

The clue, is that I don't want to display the content type, or want to modify the display of it quite a lot. Content types should only really be used, if there display only needs tweaking (via CSS etc), however a slider is more than tweaking... it's a complete functional change. Therefore the block idea is right, but putting the content as a content type is probably wrong. Even though the user interface was pretty perfect. It was possible to create a list of slides in that single content type, and then choose from the different lists of slides (as a select menu) in the block admin panel.

I'm still slightly torn though, as the slider images ARE content. Should content be edited outside the content area? My head is spinning today, so probably not a good day to work on this.