I love the flexibility module-grouping gives you to customize the document structure. I am wondering if there is any way (configuration or custom code) to remove the automatically created "Modules" treeview layer?
<tab type="modules" visible="Yes" title=""/>
Note: I do not wish to change the title. I wish to remove the layer while keeping its children.
To the best of my knowledge there is no direct way to do this.
The following is a workaround but I don't know all the implications and side effects.
I did a small test with
/// \file
/// #defgroup grp1 First Group
/// the first group
/// #defgroup grp2 Second Group
/// the second group
In the file modules.js we see:
[ "First Group", "group__grp1.html", null ],
[ "Second Group", "group__grp2.html", null ]
In the file html/navtreedata.js we see:
[ "Modules", "modules.html", "modules" ],
When we replace this line with
[ "First Group", "group__grp1.html", null ],
[ "Second Group", "group__grp2.html", null ],
it looks like you get the requested result, but this workaround has to be done by hand and as written before the side effects are unknown.
As written by #JPGarza a side effect is:
if you click on some tree view items it won't remember the selection and the treeview will show a different current page.
Related
I want to create a content element where the editor can chose an icon to display on the frontend.
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addTcaSelectItem(
'tt_content',
'CType',
[
'LLL:EXT:your_extension_key/Resources/Private/Language/Tca.xlf:yourextensionkey_newcontentelement',
'ServiceCE',
'example-registration',
],
'textmedia',
'after'
);
$GLOBALS['TCA']['tt_content']['types']['ServiceCE'] = [
'showitem' => '
--div--;LLL:EXT:core/Resources/Private/Language/Form/locallang_tabs.xlf:general,
--palette--;;general,
header; Header,
bodytext;LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:bodytext_formlabel,
',
];
Here I'm creating the layout on the back-end to insert the content, with just a header and a bodytext.
There would be a lot of possible solutions:
dependent whether the icon should be assigned to pages or content elements work with the table pages or tt_content
your extension will provied the list of icons:
add an additional field with a select list for the icons to the records. put it into TCA (Configuration/TCA/Override/<table>.php). Make sure the value is the icon-name, so you do not need additional replacements in FLUID.
Add the rendering to the FLUID template where it belongs. As it should be available everywhere the Layout-templates would be a good place.
use sys_categories:
use the build in categories for providing icons to any record.
create some categories with either the icon as category image or use another field as the icon name. (You even could add another field especially for the icon name.)
For the rendering of pages or tt_content add a data processor to get the assigned sys_category-records of the data record and then render the first/all icon(s) of the record in the Layout-templates.
Like the title said I'm trying to figure out how to save to file and load from file data entered into the extraWidget menu? I'd appreciate any assistance.
I'll assume that by "data entered into the eXtraWidget menu", you mean the values entered in the widgets appearing on an eXtraWidget tab.
If that's the case, it's fairly easy to do using the xw:export and xw:import primitives.
Suppose you have a very simple xw interface, like this:
extensions [ xw ]
to startup
xw:clear-all
xw:create-tab "t" [ xw:set-title "Menu" ]
xw:create-multi-chooser "mc" [
xw:set-items ["a" "b" "c" "d"]
]
end
That would give you an extra tab like this, with a "multi-chooser" in which you can select multiple letters ("a" and "c" in this example):
To export the whole interface and its content to a JSON file, you can simply call:
xw:export "menu.json"
and then recover the widgets and their values at any time with:
xw:clear-all
xw:import "menu.json"
You need to call xw:clear-all because xw:import will otherwise warn you that those widgets already exists.
I hope you can help me with this. After reading all the documentation several times, googling for days, etc I don't find the way to do what i'm going to explain in a clean way, and in think I'm missing something because it's a really basic scenario.
I'm working with oData models, in this case 2 named models, "Model1", "Model2". Now what I want is to show a "parent" ComboBox based on an oData path, and a table that changes its items depending on the selection, in other words.
Model1 { //JSON representation of the data.
Accounts:[
"account 1": {invoices: ["invoice1", "invoice2", "invoice3"]},
"account 2": {invoices:["invoice4", "invoice5"]}
]
}
Combo Box:
<... items={Model1>/Accounts} /> -- This works and shows Account 1, and Account2.
Table
<Table... items="{Model1>Invoices}">
..
<items>
....
</items>
</Table>
What I want is the table to change it's context to the account selected on the ComboBox. The point is that this works, but the first time it loads the view, as there is no account selected, it calls the wrong odata path MYSERVICE/Invoices, instead of doing nothing, as the Account is not set yet, and the path for the invoices, once selected the account, shoud be MYSERVICE/Account('Account1')/Invoices for example.
I know I can achieve this with code, but I'm sure there must be a clean way to do this.
Seriously, this is driving me crazy.
Thanks for your help.
Are you sure that
items="{Model1>Invoices}"
triggers odata call? Because this is a relative path (without leading slash), normally it should not do the call.
What you can do:
Handle ComboBox selectionChange event;
In this event handler, create a path that you will bound the table to. In your case the path could look like this: "/Account(Account1)" - "/{EntitySetName}({KEY})". You can make use of createKey method of ODataModel2;
Set the table's context using the path:
oTable.bindObject({
path: sPath,
model: "Model1",
parameters: {
$expand: "Invoices"
}
});
Once the context is set, the relative binding will start working automatically and table will get the "Invoices"
I assume that the Account and Invoices are linked via navigation property and one-to-many cardinality, that's why the $expand parameter will load the corresponding invoices.
By default TinyMCE (4) has a "Paragraph ▼" dropdown, and if you click on it you get a list of formatting options ("Paragraph", "Heading 1", etc.).
I'd like to be able to do two things. First, I want to change the options and their names (eg. to "Normal" and "Heading"), and I found the block_formats option which does exactly that:
block_formats: 'Normal=p;Heading=h1'
However, I'm stuck on thing #2: adding classes to the generated elements. Instead of plain <h1> elements, when someone picks "Heading" I want to generate a <h1 class="heading">.
I thought maybe this would work:
block_formats: 'Normal=p;Heading=h1.heading'
... but it doesn't, and I haven't been able to find any other option that would let me do this. Then again, the TinyMCE documentation isn't always the easiest place to find answers, which is why I came here.
Does anyone know how I configure TinyMCE to have a "Paragraph ▼" dropdown with customized names AND custom classes on the generated elements?
I never did find a way to do this, so what I wound up doing instead was remove the block format drop-down entirely and replace it with the (custom) format dropdown. In other words I:
removed the formatselect from the toolbar1 config (removing the un-configurable normal formatting dropdown)
added the custom format dropdown (styleselect) to the toolbar1 config
defined a style_formats config entry with my custom styles
The style_formats config looked like this:
style_formats: [
{
title: 'Header',
inline: 'span',
classes: 'someClass',
styles: {someStyle: '5px'}
},
], // next style would go here
There were only two downsides of this approach. First, the dropdown now says "Formats", and I don't seem to be able to configure that anywhere. However I do have a single formatting dropdown, with only the options I want, and those options add the desired classes to the formatted text, so the dropdown's name isn't a big deal.
The second issue was that TinyMCE uses an <iframe>, which prevents it from using our stylesheet. I could have written a stylesheet for TinyMCE and then appended it to the <iframe> (or used some TinyMCE mechanism, if there is one) ... but I'm lazy so I just used style: entries for each custom format to define the style.
I use doxygen and wonder if my understanding for
\xrefitem and "heading" is correct?
In my code I have:
//! \xrefitem Cars "heading" "ListName"
//! Text
Here I define a key "Cars". All occurences of this key will be put to the "Related Pages" menu. There will be a link with "ListName" under which all occurences of the related artefacts with that key will appear.
Now my hope was that "heading" is changeable and items of the same key will be put under "ListName" but under different "headings".
//! \xrefitem Cars "Audi" "ListName"
//! Text
//! \xrefitem Cars "Mercedes" "ListName"
//! Text
But whatever I enter for "headings" it is not shown, likewise "Audi" or "Mercedes".
Can anybody explain the purpose of "heading" and what I can do with it and if my understanding is correct?
I read the manual now dozens of times but just do not get it.
It's a good idea to follow the advice in the manual and use an ALIAS. This helps to make it clear that changing the parameters (e.g. "Audi" to "Mercedes") is meaningless.
To takes the manual's example
ALIASES += "reminder=\xrefitem reminders \"Reminder\" \"Reminders\""
and using
/reminder Make Coffee
will result in something like
Reminder
Make Coffee
i.e. Heading, Text
on a page labelled
Reminders
i.e. ListName
Hope that helps - I'm a bit rusty and working from memory here.