Are beez and hathor really HTML5 templates? I don't know myself.

beez3

just check the generated HTML code of the first page. You can see footer, section HTML tags that are exclusive HTML5. So this really fixes a bug.

Also checked the frontpage generated HTML code after this PR in the W3C validator and the only errors i got are regarding the CSS media=projection that is deprecated, I plan to remove those too in this PR.

hathor

I think it was not build as an HTML5 template, but in the generate code across the backend exist some HTML5 features (data- * attributes for instance) so it should be HTML5.

Also checked the control panel generated HTML code after this PR in the W3C validator and just got 1 error: align="center" (in the version) that is obsolete in HTML5. I plan to remove that too in this PR.

I also plan to put html5.js for older IE versions.

Are beez and hathor really HTML5 templates? I don't know myself.
For beez at least
https://issues.joomla.org/tracker/joomla-cms/7359#event-139164

Other than reducing th file size by a few bytes is there any benefit to these changes

Other than reducing the file size by a few bytes is there any benefit to these changes

The few bytes reduced are not relevant to the case.

The benefits? Aside that, with the creation of HTML5, XHTML is good for the history books? :)

It solves a series of problems of using HTML5 features (section, nav, footer, header HTML tags, data-* attributes, etc) in the Joomla core that are rendered in this templates inside a XHTML 1.0 Transitional DOCTYPE which in invalid HTML code according to the web standards.

You can check that in the W3C validator: https://validator.w3.org/

Example for beez3 (component.php):

Also, one of the things accessible templates need is having valid HTML code so that machines can correctly interpret the HTML code.

Thank you that answers my question

ok, it's ready for testing.

I have tested this item successfully on 920bb31

Working properly & start with correct code:

Isis

• System: Control Panel, Global Configuration, Global Check-in, Clear Cache, Clear Expired Cache.
• Component: Banners, Categories, Clients, Tracks.
• Error Page

Hathor

• System: Control Panel, Global Configuration, System, Server, Permissions, Text Filters.
• Component: Banners, Categories, Clients, Tracks.
• Error Page

Protostar

• Default Startsite
• Error Page

Beez3

• Default Startsite
• Error Page

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/9842.}

I have tested this item successfully on a231b51

Thanks!

I found an issue, when swapping from protostar to beez template my article which was set to acces: registered with a readmore link.

What is expected is that the intro shows with a readmore link that asks you to register/login
When swapping to beez from Protostar, the readmore link is gone and the full article and full image displays. In the backend the article still has a readmore links set

I have tested this item unsuccessfully on a231b51

changing from protostar to beez template breaks readmore link

Just to add if you want to see the issue I found.

create an article following the steps described here (with or without patch both give the same issue):
https://issues.joomla.org/tracker/joomla-cms/9865

@klatte88 "with or without patch both give the same issue"

So the issue you found is unrelated to this patch, right?

What I ment is with or without Brians patch for the other issue, to show that it is unrelated to Brians patch, I guess that was a bit vague

But yes upon further testing it seems to also be unrelated to your patch

@klatte88
Thanks for clarifications! Please remove your unsuccessful test statement.

@andrepereiradasilva

Unfortunately this pull request (as it is) breaks some error pages. Just a week ago I fixed a major bug in Gantry 4, which was caused by the same behaviour.

You can quickly get the error by appending &format=htm to almost any page to get:

Fatal Error: Call to undefined method JDocumentRaw::setHtml5()

Error page does not always have JDocumentHtml object, which causes $doc->setHtml5() to fail on fatal error.

Easiest fix is to add a check to make sure the function exists or the object is JDocumentHtml before attempting to make the call.

Proper fix would be to make it possible to change document type before rendering error page. Right now doing that is impossible, though.

thanks for the warning @mahagr. will check that

@mbabker can you give a hand here? is there is any reason why the error pages (error.php) are not rendered like index, login, component and offline templates?

That cause several issues and makes the job harder to make a custom templating to error pages.

Ask whoever wrote JDocumentError to not inherit JDocumentHtml properties and functions. error.php is rendered by the former, the rest by the latter.

Actually JDocumentError is not being used either in this case; it uses JDocumentRaw which is set on routing (htm isn't a known type).

how about replacing (only in error.php files)

$doc = JFactory::getDocument();

for

$doc = JDocument::getInstance('html');

To force the error pages to be rendered as HTML.

That won't force it because it's a different document type. You need to do
all the conversions in the error.php template files or make error.php be
rendered by the JDocumentHtml class.

On Saturday, April 16, 2016, andrepereiradasilva notifications@github.com
wrote:

how about replacing (only in error.php files)

$doc = JFactory::getDocument();

for

$doc = JDocument::getInstance('html');

To force the error pages to be rendered has HTML.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#9842 (comment)

That won't force it because it's a different document type.

The change i propose in error.php files would solve the problem @mahagr is talking. I tested.

or make error.php be rendered by the JDocumentHtml class.

Yes, IMHO error.php should be rendered by the JDocumentHtml class. That way it would be a template like the other ones (login, index, offline, component) with no special cases and so easier to maintain.

It would also solve some other bugs in error.php rendering (the mod_languages, for instance, doesn't load the css in error php pages).

But, since i don't understand quite well joomla error handling, if i try to do that kind of change the result will most probably be that something gets broken .

Again, ask whoever designed JDocumentError to be a different document type than JDocumentHtml, and why they wrote the error handler to only support HTML output. It's not a bug in the error.php template, it's how the thing is (poorly) designed; it doesn't support <jdoc> tags. Changing the $doc reference won't fix anything in error.php; now you're changing references of another JDocument instance instead of $this instance that you're already rendering. So you have to do all the HTML5 stuff in error.php directly and not rely on anything that's in the JDocumentHtml API.

ok, i see. since it was (poorly) designed this way i will do the small html5 changes in error.php directly then.

And thanks again for the explanations.

This PR has received new commits.

CC: @franz-wohlkoenig, @klatte88, @waader

This PR has received new commits.

CC: @franz-wohlkoenig, @klatte88, @waader

Please test again.
Include also a test in each template error page with ?format=raw query string.

After a quick code review, all error pages should now work.

This PR get conflicts really quickly.
So will close this PR and will make a PR for each template. That should be more easy to test and mantain conflicts.