Changes to the "base" theme?

[fballiano]

Hi everybody,
I'm trying to work on a new frontend theme for our beloved platform and I'd like it to be as extensible as possible without using custom .phtml files. So the theme uses the "base" phtml files as much as possible.

In this process I found some things of the base templates that would need an update, since that theme was created many years ago and CSS now it's extremely more powerful than before so a lot of elements wouldn't be needed anymore.

A couple of example:

• in OM all the buttons have two "span" elements inside, something like:

<button type="submit" class="button" onclick="window.close();" title="<?php echo $this->__('Close') ?>">
   <span><span><?php echo $this->__('Close') ?></span></span>
</button>

which screw all the CSS frameworks out there. Will we ever have the possibility to remove those two useless spans?

• some elements have images in them, eg:

<a href="http://magento.test/catalogsearch/result/index/?dir=asc&amp;order=relevance&amp;q=prova" title="Set Ascending Direction">
   <img src="http://magento.test/skin/frontend/base/default/images/i_desc_arrow.gif" alt="Set Ascending Direction" class="v-middle">
</a>

which I'd like to replace with SVG symbols, embedded in the html. will we ever be allowed to do that?

So the question is actually: how will we manage the changes to the base theme?

[addison74]

I agree, but changes must be made with surgical precision. These files are not updated, only a few have undergone changes over the years. If we are going to look inside every of them there is inconsistency in many places, for example I reported one here #1652

Also, email templates must be analyzed.

[justinbeaty]

Updating the frontend theme -- one of the final frontiers :)

This is sort of tricky I guess. I can see the removal of the <span>'s as probably okay, but I would guess it still breaks someone's theme. If we want to do more in the base theme, we would always have to ask if it will break things or not, and I feel like we will be stuck in this situation where we can't quite do what we want because of compromises. If we only do this in the 20.0 branch, then we could have a lot of merge conflicts and or things getting fixed only in one version and not the other.

Would it be better for us to have something like app/design/base/html5 as a new base theme? There we could get as crazy as we want to without having to worry about breaking stuff. The downside is that things might need to be fixed in three places (rwd, base/default, base/html5).

[addison74]

I think that a new base theme can be analyzed on the same level as the current one, but its use must not be hardcoded just based on an option in the OM config as is the case with the Backend theme (legacy, theme X). I am using legacy but others use OM theme.

We can go even further, if a store works without issues with the new base theme, then the administrator can delete the old one in the system file. In this case, the selection in the config would be based on which directories OM finds at the same level and not on a value entered by us, an automatic check that I don't think is complicated to achieve.

[fballiano]

@justinbeaty at a first glance I wouldn't add a new base theme, we'd have to maintain 3 for multiple branches, seems very hard.

But @addison74's idea it's interesting, for example we could have a flag in configuration "use legacy base theme" and we just add some "if" in the base theme "if legacy theme do this, otherwise do that", like for example if legacy theme keep the double spans, otherwise no.

None of these options is perfect. I think the normal way would be simply modify the base theme in the v20 branch and make major releases out of it. We will have conflict but at the end of the day we almost never modify the base theme anyway, not nearly as much as the "code" at least.

[justinbeaty]

What is the ultimate goal for us, though? Say that we want to remove prototypejs, then it gets really messy trying to have a bunch of if/else in the phtml files. Or change the HTML structure more than just optional span's.

The downside is indeed having 3 themes to maintain.

[addison74]

If we take a look at the number of PRs only a contain changes in the theme files. Just as the Backend theme was added (to which there is still a lot of work to be adopted by everyone), so a new base theme directory can be added in parallel. As long as there is a configuration option in the Backend, there should be no issues (I am not sure 100% about this statement). Those who want the Magento version ca use it as before, those who want an updated version can use the remastered one. Anyway, the current Frontend theme used will have to be modified by everyone because it is based on what was in Magento. An evaluation of the files must be done and CSS/JS/HTML5 issues identified in order to determine if this effort is worth it. I'm putting it in the balance now there are still 150 open issues and 140 PRs that need the efforts of each one of us.