I am looking for an opportunity to expand the hamburger menu that is standard in the TYPO33 bootstrap template with an extra level. I have already searched the internet but did not find a solution. I use the standard TYPO3 bootstrap template.
For a third menu you need to adjust three things:
Add a TypoScript line in your TS template (Module "Template"): page.10.dataProcessing.10.levels = 3
Set the path to the Fluid templates to a path under your control. The extension bootstrap_package is not under your control, on every update it will overwrite your changes in there! How to set the paths: https://docs.typo3.org/typo3cms/extensions/bootstrap_package/Configuration/TypoScript/Index.html#page-fluidtemplate
Copy the partial bootstrap_package/Resources/Private/Partials/Page/Navigation/Main.html to your location and add the third level like the second level is built. Maybe you can find here more information: https://github.com/benjaminkott/bootstrap_package/issues/320
What you need is a little knowledge of TypoScript (where to find and change) and Fluid (How to use ViewHelpers)
Related
How can one play around with TypoScript code shown in documentations about TypoScript?
Tested with a local Typo3 test instance, Typo3 version 9.5.5, Official Introduction Package installed.
In the backend, create a new page in the tree. Rightclick -> enable it (the red overlay should disappear). Make sure it is selected in the tree.
Click on the blue Template button on the left. Usually it will show you the blue No Template message.
Make sure on the top Info/Modify is selected from the drop down.
Click the gray + (New record) button under the drop down.
On the bottom, click Edit the whole template record.
Optionally give it a speaking template and website title, like 'Playaround' and 'Play Around'.
Optionally, under tab Options -> Clear, select Constants and Setup - this will clear everything this Template has inherited from parent templates, but will also disable the debug infos at the bottom of the frontend for this page (if you have installed the Official Introduction Package).
Under the tab General -> text entry Setup, enter the following TypoScript:
page = PAGE
page.10 = TEXT
page.10.value = Hello World
press the Save and then the View button.
A new tab opens, showing you the frontend for your page, printing the text 'Hello World'.
Now you can play around with the code examples given in eg. the TypoScript Reference.
Funnily enough, I just found out that Typoscript is by definition not a programming language, but a configuration description. That's why Typo3 is needed as a substructure for this, I think. There seem to be online demos of Typo3 on the net, but I don't know whether they are up to date and whether you can test TypoScript there. Therefore access local containers / installations as suggested. Or if the possibility exists a dev subdomain.
I have to implement a media download feature. The backend user should be able to upload a media file, set the title, description, release date and so on... The result should then be visible and the file available for download in the frontend.
I am not sure what is the best way to achieve this: Plugin or Custom content element ?
Whats the main difference between the two and what would be the best solution for my task ?
Plugins are used for more complex rendering of records with different views (for example a list and a detail view of records stored somewhere in a storage folder). A custom content element (CE) should be preferred if all relevant data is stored in the record.
For your case, a Content Element seems to be the right solution. This kind of custom content elements can also be easily created with helpful extensions like "mask" which may takes you 10 minutes to create a custom CE.
https://typo3.org/extensions/repository/view/mask
If I understood you properly.
You can define plugin as type of "list_type", or as "CType" (if you need to code specific function, which is hard or unable to achieve using eg. Fluid contents) or even as another menu type defined as "menu_type".
These all types can be the same way made plugin, this separation for types are basically only for making it appear in different selectors. So:
your plugin defined as menu_type is to be selected in "Special Menus" content type in "Menu type" selector,
defined as list_type (so called) is to be selected in "Insert Plugin" content in "Selected plugin" selector,
defined as CType is totally new content type.
But they work the same way and this is easily to be switched using parameter in ext_tables plugin register call:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPlugin( ['Label', $_EXTKEY.'_myPluginSuffix'], 'CType');
1) You can use the "File Link" content element and adapt its TypoScript (tt_content.uploads.20.renderObj) to your needs.
2) You can use the file_list extension and adapt its Fluid templates to your needs
I'd like to create a custom drag and drop template so I can increase the design possibilities without losing the functionality. I can't find anything in their documentation.
I was hoping to create something like this, not sure if I'm missing something obvious but I can't find a drag and drop that allows for the different coloured background with columns too.
I could use a block of code but I can't edit the css styles so it wouldn't be responsive for mobile and also not very friendly for those who don't know html.
Rather old question, but to who it might be helpfull:
If you code your own template and upload it to Mailchimp you lose the 'drag & drop' system/UX interface with the different blocks. You are able to create repeatable blocks but then it works with a dropdown list. This is (in my humble opinion) not that user friendly and takes a while before you fully understand how to use the dropdown. I had to explain it to a client earlier today and took a while before they understood it, so I decided to write them a manual for it.
But the design you want to create should be possible to make with a standard MC template. In the 'design' tab you will find settings to control background colors etc.
Still not possible, answer from the Mailchimp support: "At the moment, it's not currently possible to code a drag and drop template completely--one of our drag and drop template layouts will need to be selected, but you can drop in Code blocks to get a little more control over the styling of certain sections."
Though, if it's any help, it is possible to fully custom code your own template, and then add in mailchimps special Template language to the template to open up sections as editable within the campaign builder--or even duplicate certain sections of content. It's not quite the same as the drag drop templates, but adds similar functionality. More info on working with template language can be found here: https://mailchimp.com/help/getting-started-with-mailchimps-template-language/
I know this is an old question, but while searching for this myself I stumbled upon a solution posted here.
Basically it is possible to code your own drag n' drop template, but the solution has not been documented.
Find one of the Mailchimp templates (either one of the basic templates or a custom template from the 'Themes' menu.
Use 'Inspect element' and copy the source code of the iFramed html-email.
Paste in your preferred HTML-editor and modify as intended
Create your own template from the 'Paste in code' mode
If you want custom modules to be added by default, edit using the menu 'Edit design' in the bottom of the screen.
Save and exit :)
I found part of the answer on another topic: [Is it possible to code drag&drop templates for mailchimp?
If you add the following code into your main content div or td it will enable the drag and drop block editor:
mc:container="body_container" mccontainer="body_container"
example:
<div mc:container="body_container" mccontainer="body_container"></div>
This code will add a block editor region to the preheader section:
mc:container="preheader_container" mccontainer="preheader_container"
For the header:
mc:container="header_container" mccontainer="header_container"
For the footer:
mc:container="footer_container" mccontainer="footer_container"
Note: It doesn't seem to matter what you call the mc:container. Creating a new container with a different name worked. Although using just mc:container tag seems to work at first by itself, the mccontainer (no colon) tag is required for it to save properly.
You can create your own drag and drop template you need to add the following into your html coded template where you want the 'drag and drop' feature to exist.
<div id="templateBody" mc:container="container_name" mccontainer="container_name" class="tpl-container">
<div mc:block="3502204" mc:blocktype="text" mcblock="3502204" mcblocktype="text" class="tpl-block"></div>
</div>
This can be repeated in your code multiple times for multiple insertions. I could not find documentation to indicate if the container name or block number needs to be unique, I did make it unique in my template.
im working with Claus' Fluid Powered TYPO3 and I'm quiet happy with it. At the moment I have to implement a template wich should contain another extension (e.g. news) in the sidebar.
What is the preferred way to implement this.
My idea was to add the f:cObject ViewHelper and insert the extension in that way.
Is this the correct approach?
Thx
Markus
This depends on the type of template you are building:
Page templates should have proper content areas into which you can insert content. If the content needs to be shared, you have a few options: a) create the element in a sys folder and reference it from your Flux form settings then use v:content.render to render it by UID. b) Place any number of shared elements in a sys folder and render all by PID. c) Use content sliding in a column in your template which is there in all templates and is designed to contain elements which "slide" to every subpage (and can also be edited on subpages if editor has access).
Content templates can use flux:grid with flux:form.column, or flux:form.content as a shortcut to quickly make a single column, to add a content area, then flux:content.render to render those elements. This allows you to control that gets rendered around the plugin.
Plugin templates can associate a Flux form and use the steps described in point 2.
I think you're looking for 1a) or 1c) in this case.
My Requirement is to have a global header and footer with author able properties.
So if we update the properties on one page it should be reflected across all pages.
What is the best approach to achieve this in CQ5.
ACS AEM Commons now supports this functionality without use of an iparsys - Shared Component Properties (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Configure your menu with Shared and/or Global properties and you can simply template it directly onto all of your pages (no iparsys required). You can then edit the header/footer from any page on the site and it will by updated on all pages.
Unlike using design dialogs, Shared Component Properties supports standard content activation and internationalization (values stored below the homepage) and anything else you would expect from content.
If all of your pages site under a hierarchy, you could use an Inherited Paragraph System (iparsys). This is from an old version of the documentation, but is still a good intro:
The inherited paragraph system is a paragraph system that also allows
you to inherit the created paragraphs from the parent. You add
paragraphs to iparsys at for example, /content/geometrixx/en/products
and as result, all the subpages of products that also have iparsys
with the same name inherit the created paragraphs from the parent. On
each level, you can add more paragraphs, which are then inherited by
the children pages. You can also cancel paragraph inheritance at a
level at any time.
While not quite what you're describing in the original post (edit anywhere) it will allow you to edit the content once (at the parent page) and inherit the changes everywhere.
Traditionally you could create the components and swap the dialogs out for design dialogs. Basically you would rename your component dialog to design_dialog.
What this will do is save the changes you make to this object to a design path under etc. You can set a design path for site by going to the top level parent and setting a designPath property.
So node structure might look something like
parentNode
- #prop designPath = "designs/myapplication"
childNode1
childNode2
etc...
Any component using a design_dialog on the parentNode or its children nodes will get their information from the designPath. If you do not set a design path, the infomration is saved under etc/designs/default (or defaults, not sure, going off the top of my head).
There are some alternatives to this:
What our team did was in our siteHeader component we use http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/commons/inherit/InheritanceValueMap.html (inheritancevalue map) instead of the regular value map. The inherited value map will traverse the tree up looking for items from it's parents. This is a great source for learning how to use valuemap instead of just the default properties object:
http://experiencedelivers.adobe.com/cemblog/en/experiencedelivers/2013/02/valuemap-and-his-friend.html
This does get complicated with larger sites, and you'll have to do a lot of customization to get the system working the way you want, but it's an option if you don't want to have to manually set designPaths for every new site your authors create.
Alternatively, if you do like the idea of using designPaths and design_dialogs, you can always hook into the page creation workflow and have the page component add a designPath property on creation (this is a lot easier said than done though).
hope that helps