Cascade fiddles with my "include" in HTML comments
HTML heads, foots, and other reused static or dynamic content are often implemented with server-side includes.
<!--#include virtual="somefile.inc"-->
I'm finding Cascade finicky about that in two ways:
-
It adds an HTML break when the include is in a block with no other content (e.g. a head):
<br/><!--#include virtual="somefile.inc"--> -
It ignores the SSI call entirely in some contexts. In a template, this is ok:
<!DOCTYPE html>
<html lang="en">
<head>
<!--#include virtual="/ssi/_head.inc"-->
<meta charset="utf-8"/>
<meta content="width=device-width, initial-scale=1.0" name="viewport"/>
<title><system-page-title/>
</title>
<system-page-meta-keywords/>
<system-page-meta-description/>
But this is not:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta content="width=device-width, initial-scale=1.0" name="viewport"/>
<title><system-page-title/>
</title>
<!--#include virtual="/ssi/_head.inc"-->
<system-page-meta-keywords/>
<system-page-meta-description/>
</head>
For the moment I've added some of that content to my templates, making previews less focused on our content than I'd like.
Other nits seen along the way:
-
Cascade sometimes rewrites my template, adding unnecessary XHTML blather to my HTML tag.
-
See how I've placed:
above, not on one line within title tags? Yeah, lost an hour once when Cascade failed to render title content, as if the call wasn't there at all.<system-page-title/>
I would not be surprised if this forum's scrubber cleansed my text of angle brackets. We're all angle bracket people here, so I trust you'll see through that.
Thanks!
Discussions are closed to public comments.
If you need help with Cascade CMS please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Ryan Griffith on 25 Nov, 2015 01:48 PM
Hi,
Cascade expects there to be a
<head>tag within the Template for HTML outputs in order for it to generate the inline editing region resources and markup. If you leave out the<head>tag, Cascade will attempt to re-write the Template.Based on the snippets you provided, I suspect this may be the issue you are running into here. When you have a moment, try adding in the
<head></head>tags to see if that resolves at least some of the rewriting behavior you are seeing.Please let me know if you have any questions.
Thanks!
2 Posted by burleigh on 25 Nov, 2015 06:41 PM
Thanks Ryan. I'm sorry, I've created confusion by raising four related issues in one post. Let me focus on the two really troubling matters -- one involving blocks, one involving placement in a template of an HTML comment (that invokes a server-side include directive).
called from a template region emits this HTML:
It's wrong. But I'm guessing there's a workaround.
3 Posted by Ryan Griffith on 25 Nov, 2015 09:20 PM
My apologies for the confusion there, thank you for clarifying.
Are you using an XHTML Block by chance? If so, there is a known issue with TinyMCE in which the WYSIWYG will insert a
<br/>tag if there is no root element/tag. I believe this only occurs with Firefox, but I could be mistaken.My suggestion would be to use an XML block instead to avoid TinyMCE all-together. This would also make updating easier since you can actually see the content as opposed to the "hidden" HTML comment.
Just to clarify, are the code snippets the expected result when rendering a page, or is this what you are entering within the actual template?
Please let me know if you have any questions.
Thanks!
4 Posted by burleigh on 01 Dec, 2015 01:58 PM
Ryan:
Yes, the block was XHTML. Since it included only an HTML comment embedding a server side directive there's no content for the WYSIWYG editor to render. The added break was seen in Firefox and Chrome.
Notice that para is in past tense? Rather than continue to struggle, I recreated the block as a text block, and now there are no problems.
Yes, the template is HTML; what I showed in the OP was verbatim from the template.
burleigh closed this discussion on 01 Dec, 2015 01:58 PM.