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.

similar posts @ bloxtacy:

• nice TYPO3 extensions
• update current list of available plugins from TER
• The requested page didn’t have a proper connection to the tree root