Tag Archives: extensions

The requested page didn’t have a proper connection to the tree root

Posted on by
1

Just a fast snip i was hunting today:

It might be helpful to you, if

  • you use RealUrl
  • get the errors after following links to pages what definetely are correct and visible
  • the errors shows “mp vars”

Get yourself the ‘realurlmanagement’  extension and list the pages in backend hat are the target of the links with it (use ‘pages’ option in module´s view)

The extension may show you several different paths to your page. Just flush them all and you´re good to go.

I was searching for user errors on a larger system for an hour, and did check the realurl caches at last.

And if you´re here but the above solution is not working for you, check the first obvious thing in your shortcut / linking page:

Did you specify the target page? :-)

Backend View

nice TYPO3 extensions

Posted on by
Reply

just wanted to post five neat extensions you can get freely from the TER i find worth to be mentioned since they really give me no headache but useful features:

  • stg_clearcache
    allows you to clear cache of user-owned branches in one big installation, so it’s not only clear cache of this one special page and also not clear all page cache. useful if you run a large system or microsites.
  • kb_filequota
    allows you to have a quota on filemounts, either by giving a size limit on the filemout itself or for each user. useful if you’d like to save space and suppress waste in the filemounts.
  • rscliem
    allows you to automatize the extension updates on your system. i use it as nightly extension-cache update and it notifies me by mail, if extension should be updated for the very TYPO3. useful if you’d like to take steps in automatic administration.
  • realurlmanagement
    allows you to view and manipulate a lot of stuff relating to RealUrl extension. simple alias and page-path editing. useful if the system works with RealUrl.
  • nc_staticfilecache
    allows you to cache the pages from your system to server disk and serve them from there (waaay faster!) and so have the site up and running even if the your TYPO3 is ill. useful, if you have mostly static pages and mod_rewrite going.

even if some of them might be well known, i wanted to put a link to give the extension authors a big up! yeah great stuff, keep on going!

if you think this short list was helpful, just leave a comment. i would appreciate, if you send me your missing extension entry for here ;-)

$TBE_STYLES and custom css in TYPO3 backend

Posted on by
6

the most of this night went on to find out how to bring my own css file to the TYPO3 backend for my own extensions, which happen to be more and more BE modules. This is just readable fun of an oldschool try and error session.

The issue is, if you go and program stuff that makes your life in the backend more comfortable, you´d better go for it the real way. It has to look nice, at least as much as the skin of TYPO3 does itself. Speaking of this, I kinda like the way they´re going in 4.2. But I hate that the following line of code blows away all the “4.2 magic” and reveals you the historic 3.x backend interface style. Time to move on…


$TBE_STYLES['styleSheetFile_post'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

Doing so will overwrite the following commands, next to others. Imagine, how devastating this is.


@import "typo3-colors.css";
@import "typo3-alt-menu-php.css";
@import "typo3-alt-db-navframe-php.css";
@import "typo3-db-list-php.css";
@import "typo3-clipboard.css";
@import "typo3-alt-topmenu-dummy-php.css";
@import "typo3-alt-palette-php.css";
@import "typo3-TCEforms.css";
@import "typo3-dyntabmenu.css";
@import "typo3-index-php.css";
@import "typo3-tree.css";
@import "ext-cms-layout-db-layout-php.css";
@import "typo3-file-list.css";
@import "typo3-csh.css";
@import "typo3-workspaces.css";

So, THIS does not work. And don´t try this at home, it will shock you ;) You may try to reinvent another BE style at all (thus skipping on importing around 20 stylesheet files) but I am not going to do that.

Better stick on this following line in the ext_tables.php of your extension. It works for my purposes right now: it just adds a stylesheet file that comes packed with the ext when installing.

$TBE_STYLES['stylesheet2'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

Note that the css file in this case resides in the extension root folder. It works for one extension using this line of code. But if you have another one with the exact same command, there will only be one of the css files, but you might be expecting two of them. Well, how about guessing cool numbers that nobody else is going to use? (23, 42… any eleven digit prime number should work just fine)

It is understandable that the post-style is for having the important skin features included at last. That ensures that nobody else freaks out with the standard css commands for the backend. css is just so good. But how are we supposed to create a backend user experience that fits into the style, but with a touch of our own unique taste? It´s just humiliating to produce hardcoded html style attributes. ^^

Custom CSS, just include it

I ran into this problem this night, because I am developing two BE modules simultaneously, that can´t be fusioned to one in a semantic matter. Both should have got the css fanciness, but only the stylesheet2 field in $TBE_STYLES can be used safely. So is my experience to date.

The perfect solution would be the associative array at $TBE_STYLES['stylesheet']. Note the missing 2. I thought, it was clever to just extend this array to my needs like in the following code. Unfortunately, it didn´t work as expected.

$TBE_STYLES['stylesheet']['bbb_sortwizard'] = t3lib_extMgm::extRelPath($_EXTKEY).'myownway.css';

This would make every extension that needs a css file loaded to save it using the extension´s unique key. But, it did not work out. Two fields are predefined:

[modulemenu]=sysext/t3skin/stylesheets/modulemenu.css
[backend-style]=sysext/t3skin/stylesheets/backend-style.css

A good point to start on drilling the holes into the core, eh? ^^

Tonight, I rather used the quicker solution that will work in a way:

Putting the css inline

$TBE_STYLES['inDocStyles_TBEstyle'] .= '
.someclass {margin-top: 10px;}
.anotherclass {border: 1px solid black;}';

See the nasty concatenation of this value. It is naive to think that this is the best possible way to bring in own style to the backend of TYPO3. Well, the conclusion is, as long the internet does not present me more information on that issue (tell me how to do it in a constructive comment, this is appreciated) I will stick to the last mentioned way of inline css.

If you do as well, please concatenate too, that if you happen to be the last extension to be loaded, the code of the other extensions are respected, too. “Older” css commands otherwise would be deleted. Thank you.