I have my site package extension toolbox with a lot of custom ViewHelpers. For not violating DRY rule I registered my own namespace (with global namespace import tip) for recognizing it within Fluid instead placing at the beginning of each template as usually in typo3conf/ext/toolbox/ext_tables.php and in general that works:
$GLOBALS['TYPO3_CONF_VARS']['SYS']['fluid']['namespaces']['toolbox'] = ['BIESIOR\Toolbox\ViewHelpers'];
I can (or rather could) use my VH's like <toolbox:someViewHelper />, however after moving page from development to production (the same machine, just switched domains) suddenly I get an exception like:
TYPO3Fluid\Fluid\Core\Parser\UnknownNamespaceException
Fluid parse error in template Standard_action_Orangeheader_2c41396366318874342b894b22eff7acb311cc0c, line 2 at character 1. Error: Unknown Namespace: toolbox (error code 0). Template source chunk: {toolbox:containerEscape(condition: data.tx_mask_escape, start: 'true')}
What's frustrating this problem disappears when I'm logged to BE as an admin and preview the FE in the same browser, as fast I'll logout from BE and/or visit required FE page in another browser, the exception comes back.
As mentioned during development this problem didn't occur, after logout.
ViewHelper is used in page's template included in main TypoScript with FLUIDTEMPLATE cObject.
Had somebody such weird behaviour?
Use ext_localconf.php instead of ext_tables.php for it.
Not sure, but I think ext_table.php is Backend End (BE) context only, but you need the ViewHelper in the FE Context.
Related
On my live site 'mysite.com' I see the following error message in the console:
Blocked loading mixed active content “dev.mysite.com/fileadmin/templates/fonts/glyphicons-halflings-regular.woff2”
[Learn More]
jquery-1.11.3.min.js:4:24860
Blocked loading mixed active content “dev.mysite.com/fileadmin/templates/fonts/fontawesome-webfont.woff2?v=4.7.0”
[Learn More]
jquery-1.11.3.min.js:4:24860
I have no clue how it got there and don't remember what I changed. Where do I need to look for and how can I fix this?
I do have a Development Site ... dev.mysite.com ... and for deployment I just move the new files into the live folder.
Edit: I want to fix this problem by loading the files from my live site ... but I don't know from where I'm loading those files.
As those font-files are probably loaded from CSS I assume you already load your CSS from the dev server.
Check this out in the your browser (Network-tab).
You might see it in the HTML source. But the loading also could be initiated by javascript. so you need to check that too for any references to your dev-server.
Then you need to identify the source of this inclusion. If it's in the javascript it's obvious.
The CSS includes can be initiated in multiple places. The most common are in typoscript, so first try: go to the Template Analyzer and look for your dev-server domain. Identify the template and modify it.
I have a strange problem:
TYPO3 7.6 with realul 2.2.1
I got a page with a form. One field of the form gets prefilled via get-parameter (sysid=xxxxx).
The site is multilanguage: german->0, english->1, mapped via prevars '' and en.
When I call the page via www.domain.tld/form-page/?sysid=xxxxx I can fetch the get parameter and fill the field.
When I call the page via www.domain.tld/en/form-page/?sysid=xxxxx I get a 404. That's weired because www.domain.tld/en/form-page/ works without any problems.
I tried several settings (e.g. exclude sysid from chash generation) but nothing worked.
Any hints what I could do?
One additional note: the getvar links are not generated in TYPO3, the are called via barcodes.
I cannot reproduce your problem on the same versions of T3 and realurl.
And I guess (wild guess), it is not a realurl problem, but a TYPO3-core problem.
Could you try calling the page via:
www.domain.tld/index.php?id=XX&L=1&sysid=xxxxx
Furthermore investigate and tell us your settings of
[FE][pageNotFound_handling] and according (installtool/LocalConfiguration).
Nevermind. Error occured because I didn't adjust the realurl-setting for the domain after moving to live. Therefore automatic configuration took place and that didn't work. With manual conf it works.
we are using Typo3 7.6.6 for our new homepage. To simplify the process of writing new articles, we introduced the extension TinyMCE4 as TYPO3 RTE. On our test-system tinyMCE works fine, the editors are satisfied.
To prepare for production environment we introduced SSL. Hence the homepage is referenced over https://....
Since this change tinyMCE no longer appeared. After some research we found out, that the tinyMCE extension tries to load a specific dynamically generated js-file tinymceConfiguration....js over HTTP (not over SSL as preferred).
Since we have a strict policy, the server doesn't allow the client to catch the script without using SSL. Unfortunately we cannot change that policy.
The question is: where does the extension get the URL from. Can I overwrite it to reference the https://.. path?
I already tried changing
config.baseURL
tinyMCE.init({
...
document_base_url : "https://.."
});
But it didn't work.
Does anybody have an idea?
Regards,
Thomas
you could try to tell your browser to use "Content-Security-Policy" in that way all http links are rewriten by the browser itself. Maybe the lazy way.
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https?hl=en
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
Regards
Pete
I set config.disableAllHeaderCode = 1 in my recent TYPO3 sites, as I want full control over the page template.
But this not only throws out the html tag etc., but also the default Js (which could be used to uncrypt mailto-Links.
One solution would be to copy this TYPO3-generated JS from the core code and insert it manually. Very simple: just set config.disableAllHeaderCode = 0, load the page once, copy the js, done. But, in case of an update or settings change, this might break.
So: is it possible to access this "default JS" via typoscript and assign it to the PAGE object?
Have a look at https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/frontend/Classes/Page/PageGenerator.php. You will see that the spam protection code is hardcoded and only added to the page output if config.disableAllHeaderCode is not set.
Therefore I don't see a possibility to do that. Therefore the answer seems to be no, unless you XCLASS the PageGenerator. I would just copy the JavaScript code; I'm using TYPO3 for some years now and wouldn't remember that the spam protection code ever changed.
There is a solution I think. Go to /typo3/sysext/cms/tslib/templates. There is a file tslib_page_frontend.html. This file is responsible for rendering the whole page including the head. You can define a new path to the above mentioned file. For example set the following code:
config.pageRendererTemplateFile = PATH_TO_YOUR_THEME//Resources/Private/Core/tslib_page_frontend.html
respectively
page.config.pageRendererTemplateFile = PATH_TO_YOUR_THEME//Resources/Private/Core/tslib_page_frontend.html
The new template file can look like the following small snippet:
###JS_INLINE###
###BODY###
That way the inline JS is still rendered (and I think the spam protections JS is inline JS - which can be stored in external files).
I need to use ZendAMF on a symfony project and I'm currently working on integrating the two.
I have a frontend app with two modules, one of which is 'gateway' - the AMF gateway. In my frontend app config, I have the following in the configure function:
// load symfony autoloading first
parent::initialize();
// Integrate Zend Framework
require_once('[MY PATH TO ZEND]\Loader.php');
spl_autoload_register(array('Zend_Loader', 'autoload'));
The executeIndex function my the gateway actions.class.php looks like this
// No Layout
$this->setLayout(false);
// Set MIME Type
$this->getResponse()->setContentType('application/x-amf; charset='.sfConfig::get('sf_charset'));
// Disable cause this is a non-html page
sfConfig::set('sf_web_debug', false);
// Create AMF Server
$server = new Zend_Amf_Server();
$server->setClass('MYCLASS');
echo $server->handle();
return sfView::NONE;
Now when I try to visit the url for the gateway module, or even the other module which was working perfectly fine until this attempt, I only see a blank screen, with not even the symfony dev bar loaded. Oddly enough, my symfony logs are not being updated as well, which suggests that Synfony is not even being 'reached'.
So presumably the error has something to do with Zend, but I have no idea how to figure out what the error could be. One thing I do know for sure is that this is not a file path error, because if I change the path in the following line (a part of frontendConfiguration as shown above), I get a Zend_Amf_Server not found error. So the path must be correct. Also if I comment out this very same line, the second module resumes to normality, and my gateway broadcasts a blank x-amf stream.
spl_autoload_register(array('Zend_Loader', 'autoload'));
Does anyone have any tips on how I could attach this problem?
Thanks
P.S. I'm currently running an older version of Zend, which is why I am using Zend_Loader instead of Zend_autoLoader (I think). But I've tried switching to the new lib, but the error still remains. So it's not a version problem as well.
got it...
I was not using
set_include_path()
while loading Zend. It's still odd that it would give such a cryptic error, but this was the missing piece indeed.