Similar #20724

I'm assuming Joomla Team did not resort to a 3rd party extension to achieve their own homepage.

Actually, we did ?

I don't think it needs to be in core personally, but if there's really a heavy interest in having it in core, https://github.com/mbabker/com_empty

@mbabker

Haha
Well... maybe it's just me but there isn't a single non-blog site that comes to mind, that doesn't require a page free from any article. Homepages comes to mind as the best candidate for such.
Thus why I feel differently than you on this.

Personally I can easily work around this, and don't need a 3rd party component like Blank. But I think it would be nice to have it on the core and make it easy on everyone.

maybe it is just you. I have never built a site that doesnt have a component on every page

@franz-wohlkoenig
That issue was about the modules being able to store more content. Related, but not the same as the objective of this topic could be achieve with the current module limitations.

@mbabker
Are you including the times you used com_empty ? ;)

Personally I find this requested quite often.

The problem I see with a com_blank is the template most likely wraps the component area with some padding or other styling. You will therefore still have a space for the component visible in some manner, all be it an empty space. I found the best solution to be an option within the template. You can therefore remove both the component and it's container.

@Ooops-404 I think you confused me and @mbabker ;)

@ciar4n exactly

The entire reason I built that is because frequently I come across projects where homepages are module driven (actually, in my current portfolio I can only think of two websites where the homepages are a com_content view, the rest are this empty component). Which works out OK, except for the fact that Joomla has to be routed to a component. The way to get around that was to set something like an empty article as the homepage, but there's still the performance hit of having all the things that happen when a component's display task is executed (so in the case of com_content that's however many database queries are executed in the model, the plugin events, and actually rendering things even if it is an empty article, so you still end up with "junk" markup). So the empty component takes care of that performance hit by just not doing anything at all.

As @ciar4n pointed out you really still need to account for the empty component space in your template (which we don't do for the joomla.org homepage, but in our case it isn't having a visual impact so not really a priority for me personally). So it is a little more involved than just "dispatch request to empty component and have a nice day" if you want to do things "right", depending on your template.

@brianteeman I did, crazy I know.

@mbabker @ciar4n
But couldn't the component force zero padding and zero margin in case the template as one? (via css!important).

To be fair, this is not a priority for me as I can do without, but I think it would be nice for people that are not as accostumed to joomla, they would have an easier time.

The component shouldn't be making design decisions for the template.

@mbabker
Good point, then it's kind of a sucky situation because it would potentially create another.
Well... there's something that could solve that second protentional problem, which is to give the user the option to add that rule or not (probably not what you wanted to hear ;) ).

You know, sooner or later we should really decide if we want end users customizing look and feel in templates or in the UI, and either drop the excessive UI options related to customizing look and feel or start dropping feature support in the rendering layer. We can't keep tacking options for every single possible scenario into the UI, it's how you end up with the mess that is the com_content edit page.

Not sure I'm following you.
I think that as a rule of thumb, styling should always be done via whatever template is installed. (admin & site) But features should be natively supported regardless of the template (ie. Articles navigation, voting, show/hide author... ).

This gives the user a bit of liberty, to move between templates (as all template will support the native features) , and further customize how whatever template they have looks like.

I believe joomla sets itself to be an easy way to own a site, not an easy way for a developer to build a site, even if they are not mutually exclusive.

That said, one of the things I love about Joomla over WordPress, is its simplicity. I find WordPress templates to be too packet with their own functionalities, feels messy. And if I understood you correctly, that's the direction you're contemplating here... Am I right?

Not at all. My groan about Joomla and its 4^2375890 options is that we shove so many options into the backend UI to control the frontend template that it creates massively complex layout files that are not easy to customize (or maintain once you've created an override; it's worse to some degrees when you start getting the complex template frameworks involved). https://github.com/joomla/joomla-cms/blob/staging/components/com_content/views/article/tmpl/default.php is not an easy file to follow in part because of how many options it is trying to account for (which is why for my personal projects and some of the stuff we've done at my day job when we do layouts we don't have the vast majority of the options in our overrides).

I find WordPress templates to be too packet with their own functionalities, feels messy.

Because WordPress themes come packed full of functionality that we would find in our modules and plugins quite frequently. So you aren't just getting a template, you're getting a massive package of functionality.

Many of my users are creating module-only pages,

Their approach is to use some com_nnn component that is unrelated to the current page ...
which is rather weird and ... confusing when someone is called to examined the website,

plus sometimes it has bad sideffects as the used component can be executing something undesirable
or it may execute some more code in the future that will break the page

Should stay as Template Feature. As Example in Cassiopeia.

Front pages without articles are 8 out of 10 in my case. If the template i use has the option "hide component" it's ok. If the template doesn't have it it's quite a problem.
A new menu item type called Frontpage (that uses the blank component?) would be very useful in my opinion for the majority of sites. I believe many template designers would also find it useful. What i see many times at quickstart packages is to use an article in a "modulish" way and make it seem like a module and all the other sections of pages are modules.
In this case also i have observed google to save the url of this article as top result and not the frontpage (google saves example.com/super-article and not example.com)

Front pages without articles are 8 out of 10 in my case. If the template i use has the option "hide component" it's ok. If the template doesn't have it it's quite a problem.

All that option does is not show the already rendered markup from when the component is run. You really have to have a "dead" component in place too, for the reasons pointed out by @ggppdk and myself.

What about this:

https://extensions.joomla.org/extension/blank-component/

?

@DavidBoggitt

I've used in the past, works well.

Pros: It just worked
Cons: One more extension to follow; having it on the extension admin menu is a bit weird.2

I just tend to install the fewest number of extensions possible in a website to avoid finding myself in a situation where I want to upgrade Joomla and can't due to some extension that stopped being supported by its original developer. And extensions like Blank, due to the problem it solves (kudos to Omar Muhammad) become just too central, important to the website as several pages will dependent on it. Thus why I think it should be a core function as in a type of page (and not appear in the extensions list like the form extensions of whatever).

@mbabker

Because WordPress themes come packed full of functionality that we would find in our modules and plugins quite frequently. So you aren't just getting a template, you're getting a massive package of functionality.

Which may bar the user from jumping from one template to another without having to address the "template proprietary" functionalities.
Now, I'm now saying that it's Joomla responsibility to tackle this, what I'm saying is that the way Joomla have been going about it, is miles better for the user and kind of sets a bar for template developers.So kudos to the Joomla team.

Closing this as it is easily resolved with an extension