Encountered an issue today where I made tweaks to the a TYPO3 page and the page became blank. The <body> tag was empty!
I fixed it by clearing cache, but I also found another page with the same problem later on.
Doing some research I found that the page is empty on the cache_pages table.
What is causing it? I am using TYPO3 4.5.6
It happened to me. and the cause was, in the fluid template?
Instead of using fluid template, i just use the regular html tag if you didn't initiate the view helper or something in your form.
This usually happens, if you don't have a PAGE TLO.
Make sure your main template includes something like:
page = PAGE
page {
10 = TEXT
10.value = Hello world!
}
You might have cleared it by accident.
Related
I'm beginner in typoscript, I understand the principle, but I have a small problem from the start.
On my homepage in the setup field of the template-tools, if I put:
page.10 = TEXT
page.10.value = Hello World
It works, I have my display,
however, if I put:
page.10 = HTML
page.10.value = Hello World
it does not show me the text anymore ...
What do not I understand?
page = PAGE
page.typeNum = 0
page.10 = HTML
page.10.value = Hello World
Since TYPO3 6.0 there no longer is a HTML object in typoscript. So there is no rendering.
Try to avoid examples from very old days as TYPO3 has changed a lot.
You could look for typoscript errors in the TSOB (TypoScript Object Browser) or Template Analyzer
(see: Web -> Templates -> ... drop down selection on top of page)
As mentioned above, the HTML Content object has gone.
Valid solution: just use the TEXT object for such HTML output.
Note the stdWrap.htmlspecialchars thing.
(Read more: https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Functions/Stdwrap.html#htmlspecialchars)
If you use both in connection correctly, it is a save and recommended way.
Although maybe HTML output should sit better in a FLUID template or partial.
But still there are some usecases for our approach.
I have a TYPO3 which strips any <p> tags from content I create when the RTE editor is enabled for the field in question before it saves it in the DB. And it seems I cannot find a way to disable this behavior with a TypoScript. As soon as I disable the RTE editor I can save <p> tags and they get correctly rendered in the frontend. They also get correctly rendered in the frontend when I simply add them directly in the database in the tt_content table in the bodytext field.
When I switch to the edit source mode of the RTE I see all <p> tags in place. Before and after a save (also they never make it to the DB) so it looks like they get converted to (linux) line breaks or something and get converted back to <p> tags when the editor loads them in the backend. But those line breaks of course have no effect to in the frontend.
I thought this behavior would be controlled by RTE.default.proc but everything there looks good to me (p is already in the allowed tags and there is no clue why it could be stripped). I've also tried to disable the RTE.default.proc.entryHTMLparser_db and RTE.default.proc.exitHTMLparser_db as I wouldn't mind it if the HTML content as you see it in the edit source mode of the RTE (so with RTE still enabled!) would not be touched at all - in fact I would prefer it - but this had no effect. On the other hand when I add tags to the allowed tags which weren't there before (like <button>) this works so the things I try to add to RTE.default.proc aren't ignored in general.
So how can I stop TYPO3 from stripping my <p> tags from RTE content or touching it at all? I'd prefer a solution with TypoScript but meanwhile I would also be happy about an ugly hack in a sys extension as long as it works...
I'm not sure if this is a bug or not but the solution to my problem lies in p.rmTagIfNoAttrib = 1. At least in my TYPO3 version (v6.1.7 and nearly only built in extensions) I cannot find this setting in the preset TypoScript of the page or the RTE editor so I'm guessing it defaults to 0. In my logic 0 means false so I'd say the default would read as "remove tag if there is no attribute?: no!".
However TYPO3 seems to work after its own logic. Adding the following statement to the page TS sloves my problem and <p> tags are preserved:
RTE.default.proc {
entryHTMLparser_db {
tags {
p.rmTagIfNoAttrib = 1
}
}
}
The reasons for this behavior are explained in the TYPO3 manual:
Many of the transformations performed back and forth in the TYPO3 backend date back to when it was a challenge to incorporate a RTE in a browser. It was then sometimes needed to fall back an a simple <textarea> where rich text had to be presented in a simple enough way so that editors could work with it with no visual help.
I'm trying to put TinyMCE on my website. I figured out how to get it to show up, but I'm lost on how to process the content. In their example, they just have a link that references the top of the page and clicking on it somehow magically causes their dump.php script to execute. I don't understand what's going on here. Here is the link:
http://www.tinymce.com/tryit/basic.php
The "Submit" button at the bottom is really a link in a span element with href="#". The form action is dump.php. I want to know how they configured this to run without an actual submit button. Any help in understanding this is greatly appreciated!
To Get Content From Tinymce You Can Use GetContent Method of Currently ActiveEditor Instance
tinyMCE.activeEditor.getContent();
method is used to getting Content .. to Set The Content
tinyMCE.activeEditor.setContent("I Want Text To Be in Tinymce");
to find a perticular element in tinymce get body and find element
var body = tinyMCE.activeEditor.getBody();
$(body).find("#elem_id")
to get a full html
tinyMCE.activeEditor.getDoc().documentElement.innerHTML
hope that helps ..
Since I use PHP, I found this which is also useful:
http://www.tinymce.com/wiki.php/TinyMCE3x:How-to_implement_TinyMCE_in_PHP
Two questions and maybe they are caused by the same thing/setting.
Using TinyMCE with full corporate account. Many of the publishers are just pasting HTML into the HTML Source Editor... we are just getting this going the results are very mixed.
So if someone has a well coded page it works well - as far as we think.
But if you create a page with a couple of (or one) open div tag. Holy cow! The editor can throw divs everywhere - 30 extra on one page someone sent me. Why is the editor changing content? Can we keep this from happening? If a publisher makes an HTML mistake we would rather that the mistake shows - not be scrubbed.
Also I noticed myself when creating menus that if you put in anything inside a link tag (like a div, ul, li, dd, dt, dl, h1-6... pretty much any tag) other than a span, that the editor will either push the tag content outside of the link tag or it will change the tag to a span.
http://www.tinymce.com/wiki.php/Configuration:Cleanup/Output
Looks like the verify html is the new setting. Will report back after testing.
David - I would have marked yours as right if you answered. Looks like that works for 3.4 and below.
For version 3, use
verify_html : false
From here http://archive.tinymce.com/wiki.php/Configuration3x:verify_html
I have added a facebook like button to my page, however when it is clicked the flyout appears, and then disappears.
At first I thought it was other elements on the page hiding it, but the problem persisted even on blank pages.
Tried both the iframe and html 5 codes that were generated by facebook and neither seems to work.
iframe - http://jsfiddle.net/aDK95/1/
Html 5 - http://jsfiddle.net/L9nZZ/1/
In both cases it seems to been hidden by the hidden_elem class:
#facebook .hidden_elem {
display: none !important;
}
It seems very similar to this bug reported at FB that was reported in May. However there doesn't seem to be much movement on it.
Has anyone else come across this? Know of any work arounds?
I came across this bug and it flummoxed me for quite a while. The steps I took to rectify it are as follows:
Ensure that you have put in the Javascript SDK initialization
Make sure that the #fbroot div is not inside a hidden div
In the Open Graph tags on the page, the og:url has to be set to a https protocol
and not a http protocol
Run your page through the Facebook Debugger at https://developers.facebook.com/tools/debug to check for any errors. Another interesting point which helped me resolve this was that when you put in your "URL to Like" value in the Like configurator, the dynamic like button generated shows whether that url would work well or not.