in one extension file: I run below code:
var_dump($GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_watermark_pi1.']);
the result is :
["hooks."]=> array(4) { ["dagou_post."]=> array(1) { ["view."]=> array(2) { ["state."]=> array(1) { ["template"]=> string(11) "###INPUT###" }...
and I can tell it outputs this file: ext_typoscript_setup.txt inside extension:watermark and also the ts settings from global and local pages.
Question:
I checked file: typo3\sysext\cms\tslib\class.tslib_fe.php, and trying to figure out how does this work: $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_watermark_pi1.'], but only saw var $tmpl='';
from this code: $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_watermark_pi1.'], tmpl should be an object, and setup['plugin.']['tx_watermark_pi1.'] should be the property. So anyone can give me some explanation on how does $GLOBALS['TSFE']->tmpl->setup['plugin.']['tx_watermark_pi1.'] work? thanks.
$GLOBALS['TSFE']->tmpl->setup is the cumulative recursive TS setup of your compete website. It gathers all TS templates, found in rootline from your current selected page, parses it and compiles into array.
Obviously, you will find nothing about tx_watermark_pi1 in class.tslib_fe.php, because tslib_fe knows nothing about it - it just creates FE, and one of the tasks is to create tmpl object, that contains complete setup of all TS, found in rootline.
You can find more info on TS parsing here
The typoscript code you write and also the ts-files delivered with the extensions you have installed are parsed to php and then cached. When the frontend is built up, this very big php array is written to this global object and then read from there by several other classes like extension plugins and so on.
You can find that code in the t3lib/class.t3lib_tsparser*.php classes if you want to take a look (although I don't think that will help you).
Related
I get a project that used TYPO3 CMS, the task is quite simple, adding cookie usage notice on the header part of the website.
I never working on TYPO3 before, but already reading the documentation. Somehow I can't figure out which file to edit. even the documentation tutorial and file structure is different than the project I handle.
I don't have any project documentation for the project either, and I don't want to ask you to do my task, but I'm blank at the moment and don't know where to find the respective file needed.
Any suggestion or clue how to handle the issue?
my index.php on root folder look like this:
if (defined('E_DEPRECATED')) {
error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED);
} else {
error_reporting(E_ALL ^ E_NOTICE);
}
// ******************
// Constants defined
// ******************
define('PATH_thisScript', str_replace('//', '/', str_replace('\\', '/',
(PHP_SAPI == 'fpm-fcgi' || PHP_SAPI == 'cgi' || PHP_SAPI == 'isapi' || PHP_SAPI == 'cgi-fcgi') &&
($_SERVER['ORIG_PATH_TRANSLATED'] ? $_SERVER['ORIG_PATH_TRANSLATED'] : $_SERVER['PATH_TRANSLATED']) ?
($_SERVER['ORIG_PATH_TRANSLATED'] ? $_SERVER['ORIG_PATH_TRANSLATED'] : $_SERVER['PATH_TRANSLATED']) :
($_SERVER['ORIG_SCRIPT_FILENAME'] ? $_SERVER['ORIG_SCRIPT_FILENAME'] : $_SERVER['SCRIPT_FILENAME']))));
define('PATH_site', dirname(PATH_thisScript).'/');
if (#is_dir(PATH_site.'typo3/sysext/cms/tslib/')) {
define('PATH_tslib', PATH_site.'typo3/sysext/cms/tslib/');
} elseif (#is_dir(PATH_site.'tslib/')) {
define('PATH_tslib', PATH_site.'tslib/');
} else {
// define path to tslib/ here:
$configured_tslib_path = '';
// example:
// $configured_tslib_path = '/var/www/mysite/typo3/sysext/cms/tslib/';
define('PATH_tslib', $configured_tslib_path);
}
if (PATH_tslib=='') {
die('Cannot find tslib/. Please set path by defining $configured_tslib_path in ' . htmlspecialchars(basename(PATH_thisScript)) . '.');
}
// ******************
// include TSFE
// ******************
require (PATH_tslib.'index_ts.php');
edit: adding screenshot of the interface suggested by #Riccardo (typo3 ver 4.4.4)
Which version of TYPO3 are you running? As Bernd wrote, it is difficult to help you without further information.... I'll try to explain the first passages where you could gather some infos.
1) Access TYPO3 backend with a user with administrative privileges
2) Try to identify the main TypoScript template with this procedure:
click on template (1)
click on the "zero" page with the TYPO3 symbol (2)
you should see on the right a list of the TypoScript templates (3),
click on the one that is marked as "is Root"
2) After that, click on the first dropdown on the right area (with the "info/modify" item and select "TypoScript Object Browser" (a.k.a. TSOB)
3) After you have done that, you should see a "tree" that represents the TypoScript configuration;
be sure to have "setup" selected (1)
search for the object that builds your page, which should most likely be page = PAGE (2)
[answer edited]
I'm afraid I'll have to ask for a survey supplement
Can you identify in which part of the various objects the header of your site is rendered? My suspects would be focused on the [home2] or the [outer_frameset] object;
Hoping that they will contain the usual array with something like:
home2.10 = something
I think that the quickiest (and dirtiest) way to append something before the whole page would be something like
home2.1 = TEXT
home2.1.value = <div>whatever your message would be </div>
I don't know if you need something more complex than that...
Said that, I admit I never worked with frame inside TYPO3 and I think that the last time I did something with frames was...uh... maybe 9 years ago.
Don't change that index.php!!
As it is part of the core which gets overwritten on an update of TYPO3.
As there are very much options for configurating a page there can be no recipe matching all.
My best tip: get a TYPO3 profi to have a look into your installation so he can find which files are responsible for the page rendering and could include the cookie notice.
There also are some extensions which could render such a notice in your pages in a very easy way. But that all depends how your installation is configured. Nothing to say without further knowledge.
I've been setting up a site with Wintersmith and am loving it for the most part, but I cannot wrap my head around some of the under-the-hood mechanics. I started with the "blog" skeleton that adds the paginator.coffee plugin.
The question requires some details, so up top, what I'm trying to accomplish:
Any files (markdown, html, json metadata) will be picked up either in /contents/article/<file> or /contents/articles/<subdir>/<file>
Output files are at /articles/YYYY/MM/DD/title-slug/
/blog.html lists all articles, paginated.
Files just under /contents (not in articles) are not treated as blog posts. Markdown and JSON metadata are still processed, but no permalinked URLs, not included in blog listings, file/directory structure is more directly copied over.
So, I solved #1 with this suggestion: How can I have articles in Wintersmith not in their own subdirectory? So far, great, and #3 is working -- the paginated listing includes all posts. #4 has not been an issue, it's the default behavior.
On #2 I found this solution: http://andrewphilipclark.com/2013/11/08/removing-the-boilerplate-from-wintersmith-blog-posts/ . As the author mentions, his solution was (sort of) subsequently incorporated into Wintersmith master, so I tried just setting the filenameTemplate accordingly. Unfortunately this applies to all content, not just that under /articles, so the rest of my site gets hosed (breaks #4). So then I tried the author's approach, adding a blogpost.coffee plugin using his code. This generates all the files out of /contents/articles into the correct permalink URLs, however the paginator now for some reason will no longer see files directly under /articles (point #1).
I've tried a lot of permutations and hacking. Tried changing the order of which plugin gets loaded first. Tried having PaginatorPage extend BlogpostPage instead of Page. Tried a lot of things. I finally realize, even after inspecting many of the core classes in Wintersmith source, that I do not understand what is happening.
Specifically, I cannot figure out how contents['articles']._.pages and .directories are set, which seems relevant. Nor do I understand what that underscore is.
Ultimately, Jade/CoffeeScript/Markdown are a great combo for minimizing coding and enhancing clarity except when you want to understand what's happening under the hood and you don't know these languages. It took me a bit to get the basics of Jade and CoffeeScript (Markdown is trivial of course) enough to follow what's happening. When I've had to dig into the wintersmith source, it gets deeper. I confess I'm also a node.js newbie, but I think the big issue here is just a magic framework. It would be helpful, for instance, if some of the core "plugins" were included in the skeleton site as opposed to buried in node_modules, just so curious hackers could see more quickly how things interconnect. More verbose docs would of course be helpful too. It's one thing to understand conceptually content trees, generators, views, templates, etc., but understanding the code flow and relations at runtime? I'm lost.
Any help is appreciated. As I said, I'm loving Wintersmith, just wish I could dispel magic.
Because coffee script is rubbish, this is extremely hard to do. However, if you want to, you can destroy the paginator.coffee and replace it with a simple javascript script that does a similar thing:
module.exports = function (env, callback) {
function Page() {
var rtn = new env.plugins.Page();
rtn.getFilename = function() {
return 'index.html';
},
rtn.getView = function() {
return function(env, locals, contents, templates, callback) {
var error = null;
var context = {};
env.utils.extend(context, locals);
var buffer = new Buffer(templates['index.jade'].fn(context));
callback(error, buffer);
};
};
return rtn;
};
/** Generates a custom index page */
function gen(contents, callback) {
var p = Page();
var pages = {'index.page': p};
var error = null;
callback(error, pages);
};
env.registerGenerator('magic', gen);
callback();
};
Notice that due to 'coffee script magic', there are a number of hoops to jump through here, such as making sure you return a buffer from getView(), and 'manually' overriding rather than using the obscure coffee script extension semantics.
Wintersmith is extremely picky about how it handles these functions. If callbacks are not invoked, for the returned value is not a Stream or Buffer, generated files will appear in the content summary, but not be rendered to disk during a build. Enable verbose logging and check of 'skipping foo' messages to detect this.
I'm working in a Zend Framework based application (Shopware).
I add a template dir in my controller like this:
class Shopware_Controllers_Backend_Pricify extends Shopware_Controllers_Backend_ExtJs
{
public function init()
{
$this->View()->addTemplateDir(dirname(__FILE__) . "/../../Views/backend/");
parent::init();
}
}
But somehow, smarty always looks in the (not existing) part of the controller action:
Unable to load template snippet 'backend/mycontroller/model/main.js' in 'snippet:string:{include file="backend/pricify/model/main.js"} in Smarty/sysplugins/smarty_internal_templatebase.php on line 128
The Controller works over loading via ext js, but I do not see that this is a problem. When I var_dump template directories, the correct dir is included. I debugged the code far into smarty, but never found the part, where the directories are checked.
I'm aware, that this may be a problem within the software stack, but since I do not know where to search, I ask here. If I need to post additional data, please tell me.
I found, that the problem was that shopware extends CamelCase to camel_case folders.
I noticed that the blog module for SS have hardcoded pieces of text - that I need to translate (in french). I found that the code is in /blog/templates/Includes/BlogSummary.ss but when I modify it, nothing changes on front-end...
I tried to run a /dev/build/?flush=all but nothing... still.
Any idea? Help would be much appreciated. Thanks in advance.
Have you set your locale? I recently set up a site in English & Spanish and used this setup.
// add similar code to your _config.php file
#Translatable::set_default_locale('en_US');
#Translatable::set_allowed_locales(array(
# 'en_US',
# 'es_US'
#));
Further, I had to add i18n::set_locale() code to the init() function in my content controller to get the template translations to work.
<?php
class SmartLanguageExtension extends DataObjectDecorator {
function contentcontrollerInit() {
i18n::set_locale(Translatable::get_current_locale());
}
}
In my case, I added an extension to the Page_Controller class for reusability later on.
// _config.php file
Object::add_extension('Page', 'SmartLanguageExtension');
Is there any way to do something like that.
I have next wiki text:
{{template_open_tag}}
{{template_some_data}}
{{template_close_tag}}
And there are templates:
{{template_open_tag}}
<my-tag>
{{template_some_data}}
bla-bla-bla...
{{template_close_tag}}
</my-tag>
But tag '<bold>' processed already when first template transluded and wiki render this page like:
bla-bla-bla...
</my-tag>
But I want to see:
**bla-bla-bla...**
In my extension:
$wgHooks['ParserFirstCallInit'][] = 'myTagInit';
function myTagInit( &$parser ) {
$parser->setHook( 'my-tag', 'myTagRender' );
}
function myTagRender( $input, $args, $parser, $frame) {
return "**".$input."**";
}
Thank you.
P.S.
And don't ask me why I need this strange markup and don't want to use something like this:
{{template_tag|{{template_some_data}}}}
And {{template_open_tag}} like:
<my-tag>{{{1}}}</my-tag>
To warn you -- this sort of structure will likely be phased out entirely in future versions of MediaWiki, due to its inconsistent behavior and the difficulties it causes with structures like tags and sections.
The correct and future-proof way to do it is indeed to contain both your start and end in one template and pass the middle in as a parameter, eg {{template_tag|{{template_some_data}}}}
Set $wgUseTidy to true to make MediaWiki remove unclosed tags only after all the templates have been evaluated. Alternatively, you can use wikimarkup - as Adrian said - which does not suffer from this limitation.
Update: AFAIK XML-style extension tags are evaluated before way template including happens, so piecing them together from multiple templates is not possible. (Event <ext>{{{1}}}</ext> does not work pre-1.16, though you can make it work in 1.16 with recursiveTagParse.)
instead of using <bold> use ''' in both your {{template_open_tag}} and {{template_close_tag}} and it should render as bla-bla-bla...
Also, you can't do:
{{template_open_tag}}
{{template_some_data}}
{{template_close_tag}}
You have to do
{{template_open_tag}}{{template_some_data}}{{template_close_tag}}