Guess we can solve the module position dropdown issue in a second step. Should the module dependant CSS code not be in a CSS file which belongs to the module (eg. /media/mod_block/css/default.css)? Otherwise every template has to copy the CSS code from cassiopeia to it's own template.css file, means mod_block would not work out of the box with the templates.

Umm, I guess I don't see the purpose of this. Looking at the code, basically this module uses the loadposition content plugin to "generate" a new module position.

But you still need to publish this module in an existing module position. So why should I even use this block module as a parent for other modules? Why not just put the "child" modules into the regular module position?

Or is this just for styling purposes to "group" modules together? If it is that, then personally I would see this as something for JED and not for core. It's a rather specialised task and complex to explain the use.

Edit: Actually, you can just put {loadposition foo} into a custom HTML module and enable content preparing for that module and it does the same thing. Add some HTML tags with custom class around it and you can style it to your liking.
The longer I look at this the less I understand the purpose.

Guess we can solve the module position dropdown issue in a second step.

That's probably almost impossible. Since it uses a plugin event to create the position. Same as for positions created in an article using the same plugin which don't show in the list as well.

@Bakual I was refering to the implementation of it.

@laoneo An issue there is that the CSS and probably the desired styling classes will vary depending on the template. As I see it the Cassiopeia template in this instance will lead by example in how this module block can be utilized.

@Bakual

Actually, you can just put {loadposition foo} into a custom HTML module and enable content preparing for that module and it does the same thing. Add some HTML tags with custom class around it and you can style it to your liking.

You are kind of proving my point here. This method is far to complex. Creating rows of content is an everyday thing for web designers, it should be a lot easier than what you suggest.

But you still need to publish this module in an existing module position. So why should I even use this block module as a parent for other modules? Why not just put the "child" modules into the regular module position?

The point of this PR is that you can create as many rows of modules as you wish and style each row individually.

I agree that it is not right to put the css in the Cassiopeia template forcing every template designer to
reproduce/copy it just to get core functionality

Core functionality should not depend on using a specific template and template providers shouldnt have to copy something from Cassiopeia just to get the exact same core functionality. They should only have to do something if they want to change it

Can it not go in a system css file (kind of like we do in j3) and then it will be used by default unless it is overridden by the template

I guess as long as the css is easily overridden this might be an idea. There is certain properties that I suspect would quite often have to be overridden by the template (eg. content (wrapper) width and gutter width).

The 'modifier classes' css is relatively bulky so we should either slim it down or keep it in the template css imo.

better to override one or two lines than have to copy hundreds

You are kind of proving my point here. This method is far to complex. Creating rows of content is an everyday thing for web designers, it should be a lot easier than what you suggest.

Umm, it's actually doing the exact same thing. Just in the case of the custom HTML module, you have full control (HTML tags, ids, class and everything can be customised) and know exactly what happens. I don't think this is more complex than having a specific module doing some magic stuff.

The point of this PR is that you can create as many rows of modules as you wish and style each row individually.

It's only the second part that this proposal solves, right? Because creating rows is as simple as publishing multiple modules to the same position, with or without this PR.
The styling can be done already on a per module basis, so it's only the "per row" thing that it adds. And I doubt this really is an everyday issue core has to offer a solution. Beside that it is already possible to do easy.

In the end we create a module which does some limited copy of the custom HTML module, exposing some parameters which also can be written directly into the HTML module.

I don't see the point of it. But if people deem it worth the added CSS, code and maintainer work, go ahead.

@Bakual your method only lets you embed the positions inside an article (or similar)
If i understand this PR correctly then this is at a much higher level and so makes the module available to anything

your method only lets you embed the positions inside an article (or similar)
If i understand this PR correctly then this is at a much higher level and so makes the module available to anything

@brianteeman In an article or a "Custom" (ex "Custom HTML") module, yes.
If you add the following code to a "Custom" module and enable the "Prepare Content" option, it will do EXACTLY the same thing. It doesn't add anything what you can't already do with the Custom module.

<section id="your-block-id" class="module-block your-block-position your-block-class">
	<div class="wrapper">
		{loadposition your-block-position}
	</div>
</section>

Of course it misses the CSS styling that gets added to the template here. So without this PR, you would have to add custom CSS rules if you even need it for your usecase (eg grey background). But those CSS classes could be added somewhere else if that is helpfull.

Yes, you can make it work now. But it's not pretty, and can be borderline difficult to get right unless you really know what you're doing. If there's a way to make it easier, it's worth exploring IMO.

FWIW, we got lucky being able to build the joomla.org homepage with nothing but modules stacked in a row type effect. What you don't see though is that in at least one of those rows we still get into a nesting situation because one row is actually composed of 4 modules (the wrapping custom HTML module plus the nested positions). If we can find a way to make this more elegant, let's do it.

If we can find a way to make this more elegant, let's do it.

Let's take this example. With this proposal, you would change what?
You load the "Block" module instead of the 4 single module positions in your Custom module. In that new Block module you would then define a new position, eg "announcement". And then you assign your 4 existing modules to that new position.

Of course you could as well replace those 4 "loadpositions" calls with a single one {loadposition announcement} and assign the 4 (or more) modules to that new position directly in your Custom module without this PR.

Imho, it would actually complicate things as you add an additional (completely unneeded) loadposition call.

Remember: All this PR does is creating a module which fires a {loadposition custom-position} call. And that's not an analogy, it IS literally all what it does. Plus some CSS in the template for supporting optional custom CSS classes (which could be added regardless of the new module type)

I wouldn't change anything personally because I can write the code required to make this type of layout work (modify my template with these types of style modifiers, write the HTML to make the structure work, etc.). But I'm not the target audience of this feature. This in a way primarily targets people who rely entirely on the UI to be able to build their layouts and aren't writing HTML to make it work.

Umm, it's actually doing the exact same thing.

I am not suggesting that it is not. The end result is exactly the same but the hope is that this module will make for a more manageable and easier workflow. When the current method involves adding extra HTML and CSS by the end user then I feel there is room there for improvement.

When the current method involves adding extra HTML and CSS by the end user then I feel there is room there for improvement.

The HTML is otpional. For the loadposition there is a button. And the style is optional as well (and depends on template).

As said before, if you guys feel it is worth it, go ahead. I just wanted to be sure everyone understands what it does and what not. Personally I don't think it is worth it (maybe for JED, but not in core), but if I'm alone I have no issues with that ?

Page builders handle this quite well where any number of rows can be quickly created and populated… Joomla however does not!

What you're suggesting is easily done with existing modules and/or blog layouts. The only thing you've added is the ability to add some styling from the UI. Perhaps that is the aim.

@Bakual there is already something similar to this called Blank Module on JED: https://extensions.joomla.org/extensions/extension/core-enhancements/coding-a-scripts-integration/blank-module/

The only thing you've added is the ability to add some styling from the UI

I'm sorry but I don't think you're understanding what the PR actually does.

Lets take the top modules as an example. We currently have top-a and top-b positions. Yes, they're using CSS grid, however with the removal of the Bootstrap Size parameter, they're limited in regards to sizing.

This PR removes the hardcoded top-a/top-b and allows users to add infinite amount of module rows and defining a size of their own choice which isn't couple to Bootstrap in any way, but instead utilises CSS Grid.

At the end of the day, it's adding more flexibility to the frontend template.

Do you have a layout chart for the new front end template?

@rgmears You mean a page that displays all possible module positions?

Yes.

The homepage

You mean this?

These are the positions from the dropdown list:
Banner [banner]
Bottom A [bottom-a]
Bottom B [bottom-b]
Breadcrumbs [breadcrumbs]
Debug [debug]
Footer [footer]
Main Bottom [main-bottom]
Main Top [main-top]
Menu [menu]
Search [search]
Sidebar Left [sidebar-left]
Sidebar Right [sidebar-right]
Top A [top-a]
Top B [top-b]
They are not shown on the Home page.

With sample data of course.

However there are currently issues installing sample data at the moment so you won't see a full demo unless you build the homepage. Hopefully will get fixed soon

A chart like this would help a lot in the meantime:

That's from the protostar template.

@rgmears please have a Look: #14864

Thanks @franz-wohlkoenig .
A chart would look something like this:

Which is reminiscent of Matt Thomas's Bootstruct template.

@rgmears haven't a Chart, only Screenshot in #14864

@franz-wohlkoenig I made the chart from the screenshot. Just haven't added the labels. I wasn't sure if MENU is across the top.
And the screenshot has
TOP A ... TOP A
TOP B ... TOP B
while the bottom is
BOTTOM A ... BOTTOM A
BOTTOM A ... BOTTOM A
And I think the FOOTER should go all the way across.

@rgmears - The template now is what it is, and from the screenshot, you have pretty much the a replica of the chart. I used the module position as the title for all modules apart from those in sidebar-left and sidebar-right.

Anyway, back to the original point, this PR is simply "moving forward", so @wilsonge can you please merge this.

Can we please stay on topic. The availabile module positions in the Cassiopeia template are completely irrelevant to this pr

I think the module positions are relevant to this discussion. The question being:
Where would the Module Block be displayed?

Then I guess you really don't understand what this feature will do. It is template neutral !

@brianteeman Perhaps I don't as it appears to replace the template. Still you haven't answered my question: Where will the new Module Position created by the Block Module display in the template?

As it is a module, this 'module block' can be positioned within any template module position. The original module positions (#14864) remain with the exception of top-a and top-b been replaced by a top position and bottom-a and bottom-b been replaced by a bottom position (https://github.com/joomla/joomla-cms/pull/19062/files#diff-3001ea626c0063d81109c9aa32830d8c).

Thanks @ciar4n.

Added template chart/map #19103

I agree with @Bakual, this does not make much sense,
Too much effort to small profit.

Maybe it is fine idea when you need only 1 row, but when you need 10 new rows? you do 10 new modules,
In this case a custom HTML module with 10 of {loadposition blabla-positionXX} more easy, and simplier to find later.

but

If people want to have custom positions, it easily can be done in template configuration templateDetails.xml,
just add subfrom field, where user can add a custom position, set a style, class etc.

This would be more smart from my point of view.

Something like this:

<fieldset name="layout">
  <field
    name="positionsTop"
    type="subform"
    multiple="true"
    layout="joomla.form.field.subform.repeatable-table"
    label="Top positions"
  >
    <form>
      <field name="position" type="text" label="Name" filter="cmd" required="true"/>
      <field name="class" type="text" label="Class" />
      <field name="id" type="text" label="ID" filter="cmd"/>
      <field name="style" type="text" label="Style" />
    </form>
  </field>
  <field
    name="positionsMiddle"
    type="subform"
    multiple="true"
    layout="joomla.form.field.subform.repeatable-table"
    label="Middle positions"
    >
    <form>
      <field name="position" type="text" label="Name" filter="cmd" required="true"/>
      <field name="class" type="text" label="Class" />
      <field name="id" type="text" label="ID" filter="cmd"/>
      <field name="style" type="text" label="Style" />
    </form>
  </field>
  <field
    name="positionsBottom"
    type="subform"
    multiple="true"
    layout="joomla.form.field.subform.repeatable-table"
    label="Bottom positions"
  >
    <form>
      <field name="position" type="text" label="Name" filter="cmd" required="true"/>
      <field name="class" type="text" label="Class" />
      <field name="id" type="text" label="ID" filter="cmd"/>
      <field name="style" type="text" label="Style" />
    </form>
  </field>
</fieldset>

then in the template index.php just foreach and echo
echo '<jdoc:include type="modules" name="' . $position->position . '" style="' . $position->style . '" />';

Even can go further, and use it for top-a, top-b, bottom-a, bottom-a, so user will see an example how it is used.

Maybe it is fine idea when you need only 1 row, but when you need 10 new rows? you do 10 new modules,
In this case a custom HTML module with 10 of {loadposition blabla-positionXX} more easy, and simplier to find later.

Yes you would create a module for each row however this is fairly accepted logic, you create a row and then you add the content to that row. As already discussed, if using a custom HTML module you need to wrap each {loadposition blabla-positionXX} with HTML, the point of this PR is to avoid this.

If people want to have custom positions, it easily can be done in template configuration templateDetails.xml, just add subfrom field, where user can add a custom position, set a style, class etc.

Template providers use various different variations of what you suggest. Some reasons for a com_modules only solution...

1. Consistency for the user. Template providers each have a different solution to this. Offering a solution in core means a user only need to learn one method regardless of the template they use.
2. Easier workflow. Keeping everything in the module manager means a user is not constantly bouncing between the template manager and module manager when building a page.
3. Easier managed. Just makes more sense to manage modules entirely in the module manager. Creating template styles to define what and how module positions are available is a strange concept at best.

Easier managed. Just makes more sense to manage modules entirely in the module manager.

I often seen sites with 300+ modules, for everything, and only 1-2 article.
I do not think it easier to manage. And I do not think it is a right.

Easier, it when I know that all positions are comes from template, and do not spend a time to search the module wich use {loadposition blabla-positionXX} to load another module with {loadposition blabla-positionYY} that load some more with {loadposition blabla-positionZZ}

Creating template styles to define what and how module positions are available is a strange concept at best.

hm? I thought it what the template for.
The template define what positions and where should be displayed, and then user add a modules to that positions.

Consistency for the user.

And here is comes inconsistent.

Consistency from my point of view:
The template should provide positions, and module manager use them.

Template providers each have a different solution to this.

It is their problem.

I think our job is to show to user a good practice, instead of force them to place {loadposition blabla-position} everywhere.

• Hey Bob Average want a new position?
• yes!
• let's got to template configuration and add it
• oh yes, cool!
• now open the module manager, and add a new module to that position
• cool, that is awesome, thank you Joomla!

?

I am not sure that I really understood what you were trying to achieve with this PR before. Having used gantry for the first time over the last few days I absolutely understand what you are trying to achieve and it makes total sense to me now. However I am wondering if it really belongs in the module manager and maybe should be better suited to belonging in the template manager

I agree with @brianteeman ... this belongs in the template.

And, unless you want a controlled width, you do not really need the "top" position as there is already the "banner" position. Having an extra block above the "footer" is a good idea, although I see that the "footer" has a controlled width in the cassiopiea template, when I think it should be the full width of the page. Were that the case you don't really need the "bottom" position either as items could be set to display in the "footer" position, the order determined by the hierarchy in module manager.

As I mentioned earlier this change emulates Matt Thomas's bootstruct template (which I found had too many positions). https://github.com/construct-framework/bootstruct

Were that the case you don't really need the "bottom" position either as items could be set to display in the "footer" position, the order determined by the hierarchy in module manager.

There is a difference between content at the end of the main body section and content in a footer. For example:

<body>
    <header>
        <div id="module-header"></div>
    </header>
    <main>
        <div id="module-body-top"></div>
        <div id="component-output"></div>
        <div id="module-body-bottom"></div>
    </main>
    <footer>
        <div id="module-footer"></div>
    </footer>
</body>

So no, you shouldn't arbitrarily combine those positions because they display content relatively close to the bottom of the page. Semantically, a page footer has a different meaning than the end of the body (as conveyed by the markup structure).

No argument with you @mbabker ... I like the idea of a position that spans the bottom of the page. I think, however, that Frank LLoyd Wright's famous saying -- LESS is MORE -- should be kept in mind.

It's one of the tradeoffs you make sometimes for flexibility. Sure, you can make your template HTML basically this:

<body>
    <main>
        <div id="module-body-top"></div>
        <div id="component-output"></div>
        <div id="module-body-bottom"></div>
    </main>
</body>

But, with that you end up with the tradeoff of being in configuration hell to style modules which are designed to be "end of main but not site footer" bottom of the page and modules that are designed to be "site footer" bottom of the page. Personally I still think the first example I gave is still pretty simple and helps guide the user in building their page displays, this example IMO means the user has to be smarter about HTML and CSS matters.

The question, though, Michael, is whether the above "main" content section -- the "top" position -- and the below "main" content section -- the "bottom" position -- span the width of the page or are the same width as the "main" content position. At present "fluid" width in the cassiopiea template is not fluid. The "main" content section still has a controlled width (on wide screens).

Any discussion about the design and/or structure of the cassiopeia template are completely off topic and nothing to do with this PR at all.

However I am wondering if it really belongs in the module manager and maybe should be better suited to belonging in the template manager

It has been a while since I thought about this. One advantage was the grouping of modules. Eg. A user has 4 modules displaying services assigned to a 'Services' page.. user decides to also display these 4 modules on the homepage. The user will only need to edit the parent module block instead of editing each of the 4 child modules.

Potentially the module could offer other advantages. One that comes to mind is if modules can be created within the module block similar to how articles can now be created within menu items. This would allow users to create these rows of content in a single area. Any user of Gantry or similar would be familiar with the constant back n forth between the module and template managers.

Actually with gantry what i did was to define the positions in gantry (aka template manager) and then add module to the positions in the module manager

that is what i was trying to badly describe

One advantage was the grouping of modules.

You can already do that in the Custom Module.

Actually with gantry what i did was to define the positions in gantry (aka template manager) and then add module to the positions in the module manager

I think we agree software needs to be intuitive. It is unlikely a new Joomla user would guess to go hunting in the template manager to create a new position before creating a module in the module manager. A module block I feel is a little more self explanatory if it was your first time looking at Joomla. At least it is all in the same view.

You can't define positions in new places. You can only create "subpositions" in existing positions with that. So it is indeed not really a template thing even if positions are usually defined in the template.

@ciar4n there an alternative suggestion #19373 , what do you think?

Is there any interest in keeping this open?

Most definitely has my +1
Will make site building much easier

Yes. But I need to spend some time to figure out the template integration like we discussed before this becomes mergable

“This PR removes the hardcoded top-a/top-b and allows users to add infinite amount of module rows and defining a size of their own choice which isn't couple to Bootstrap in any way, but instead utilises CSS Grid.”

I like what I see here, just joining the conversation

I'm closing this. This is basically going to be done in a different way at the template level in core in the GSOC project for a page builder template https://github.com/joomla-projects/gsoc19_page-builder (that basically has the end goal of allowing dynamic module positions).

I also know that you, @C-Lodder and @dgrammatiko have released an improved extension version of this in https://extensions.joomla.org/extensions/extension/news-display/articles-display/perfect-grid/ if people are interested in this as a module