The indexed_search pagination outputs links like "Page 1, Page 2, Page 3"
Is there any way to edit it to remove the word 'Page' so the output is just the numbers?
<is:pageBrowsingResults numberOfResults="{result.count}" currentPage="{searchParams.pointer}" resultsPerPage="{searchParams.numberOfResults}" />
I just looked into the code and saw that the page label is fetched from the locallang with index displayResults.page.
With plugin.tx_indexedsearch._LOCAL_LANG.en.displayResults.page = and without a string behind the = it should work.
The en is for the language key, you need to set it for every language.
The documentation you can find here:
https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/TopLevelObjects/Plugin.html#local-lang-lang-key-label-key
From Typo3 10 onwards we have no pagination HTML template, instead Typo3 has provided ViewHelper for PageBrowser.
So, We can extend that viewhelper in our Template provider extension and edit as per our needs.
Related
I tried to implement a form with form framework in the news detail view. The basic way is explained here:
https://docs.typo3.org/c/typo3/cms-form/10.4/en-us/I/Concepts/FrontendRendering/Index.html#render-within-your-own-extbase-extension
Viewhelper:
<formvh:render persistenceIdentifier="EXT:myext/Resources/Private/Forms/myforms.form.yaml"/>
Form definition:
renderingOptions:
controllerAction: detailAction
addQueryString: true
submitButtonLabel: Absenden
fluidAdditionalAttributes:
class: ''
identifier: myForm
label: 'myLabel'
type: Form
prototypeName: myPrototype
The form is displayed. When I submit the form the news detail view is shown again including the form, but it's empty. The form is not processed. Something is missing, but I cannot find it in the manual.
Thanks!
I think the important part is written in the note below the linked paragraph:
In general, you can override each and every form definition with the help of TypoScript (see ‘TypoScript overrides’). This feature is not supported when you are rendering forms via the RenderViewHelper.
Luckily, there is a solution for your problem: use the ‘overrideConfiguration’ parameter instead. This way, you can override the form definition within your template. Provide an according array as shown in the example below.
<formvh:render persistenceIdentifier="EXT:my_site_package/Resources/Private/Forms/MyForm.yaml" overrideConfiguration="{renderables: {0: {renderables: {0: {label: 'My shiny new label'}}}}}"/>
That means you can check for post-variables by TypoScript conditions and adjust the controllerAction (and view) accordingly. The show / detail action is not processing the form usually, so it's logical that another action has to be assigned. I'm not sure in the moment if it does matter if double opt-in or a confirmation page shall be shown, that might depend on the form-extension.
After some hours of experimenting i was able to solve the problem. It ist simply a matter of caching ...
Georg has implemented in news a special caching engine which ignores the config.no_cache = 1 definition in setup. So the detail view of news is always cached even when the whole installation ist set to config.no_cache = 1. So this combination seems to work:
Viewhelper in Detail.html:
<formvh:render persistenceIdentifier="EXT:myext/Resources/Private/Forms/myforms.form.yaml"/>
And this definitions in the yaml file of the form:
renderingOptions:
controllerAction: detail
addQueryString: true
submitButtonLabel: Absenden
additionalParams:
no_cache: 1
identifier: myForm
label: 'myLabel'
type: Form
prototypeName: myPrototype
This renders the whole page without cache which is not optimal. It would be better when only the news entry is rendered without cache. and there is the problem, that in many installations the parameter 'disableNoCacheParameter' is set in the localconfiguration file which disallowes no_cache=1 in urls.
So i looked for an other - better - possibility to work around this problem.
First make a new fluid template anywhere in your resources folder with the modified viewhelper from above:
<formvh:render persistenceIdentifier="{settings.persistenceIdentifier}"/>
Then write a typoscript like this:
lib.embeddedForm = COA_INT
lib.embeddedForm {
10 = FLUIDTEMPLATE
10 {
file = EXT:myext/Resources/Private/Forms/myForm.html
settings {
EXT:myext/Resources/Private/Forms/myforms.form.yaml
}
extbase {
pluginName = Formframework
controllerExtensionName = Form
controllerName = FormFrontend
controllerActionName = perform
}
}
}
And final you can embed the form with
<f:cObject typoscriptObjectPath="lib.embeddedForm" />
as COA_INT in the news template. This disables the caching of the form.
Perhaps it helps ...
I have been using FluidTYPO3 (flux and vhs) to run TYPO3 web pages for many years now. With TYPO3 10, I face a major problem. I'll quickly write about my use case, how I solved it so far, and then what the problem with 10 LTS is.
Use case:
I want to have a content element template for a timeline using FluidTYPO3/flux. Each "point" on the timeline should have a heading, some text, and optionally some images. All in all, pretty basic (or so I thought).
Solution so far (TYPO3 <= 9):
Timeline elements are sections. Images are using flux:field.file.
Simplified example of the form:
<flux:form id="timeline" label="timeline">
<flux:form.section name="timeline" label="Timeline">
<flux:form.object name="element" label="Element">
<flux:field.input name="title" label="Heading" />
<flux:field.text name="label" label="Text" enableRichText="TRUE" />
<flux:field.file name="images" label="Pictures" allowed="jpg,png,svg" multiple="TRUE" maxItems="50" size="5" showThumbnails="TRUE"
/>
</flux:form.object>
</flux:form.section>
</flux:form>
With this, multiple elements can be created on the timeline and each of them can have its own set of images.
Problem in TYPO3 10:
The technology (TCA group fields to select files) that flux:field.file relies on was deprecated in TYPO3 9 and removed in TYPO3 10, see this notice. That is one of the reasons why flux:field.file was also marked deprecated and is going to be removed in TYPO3 10.
The TYPO3 deprecation notice says to use FAL relations instead. Of course, flux can also do this with flux:field.inline.fal. However, you can only have one FAL field per FlexForm. This precludes its usage in sections, since all sections would share the same images. This limitation is known for some time - see this bug report for example - but has never been fixed. It is also why I initially chose not to use FAL fields. Using bare file fields was the recommended workaround at the time.
Question:
So - how is everyone doing it? How to add multiple image fields to a flexform in TYPO3 10?
EDIT: More specifically, how to add an image field as part of a Flexform section that can contain multiple child records (resulting in multiple image fields)?
Note: I know that I can get a "file-like" field back by using an input field with inputLink renderType (like this), but as far as I can tell it does not allow to link multiple images.
I've found another workaround that might be appropriate for some use cases:
It is still possible to use flux:field.file fields if the useFalRelation parameter set to true, even on TYPO3 v10 LTS and in repeatable FlexForm sections. This will then put sys_file record IDs separated by comma into the field instead of raw filenames. They can be used as src argument for, e.g., f:image just as well as the filename, so the CE templates itself do not have to be modified. All existing CEs that had useFalRelation set to false need to be migrated though so that the filenames are replaced with sys_file UIDs.
This is a bit better than the inputLink workaround since it allows multiple images.
It seems the only workaround with TYPO3 core onboard methods is to go for a Flux-Container having a single column containing simple default "Text with image" or "text with media" elements and then to just ignore additional options of those elements and to just render the necessary fields.
With Gridelements this is called a "functional container", since the container determines the behaviour and appearance of those elements, while the elements themselves don't have to be custom elements at all.
Additionally this makes access to the content of those elements - i.e. while doing a search query - much easier.
The bug report you mentioned already contains the solutions, since the actual problem described there is that FAL fields in a flexform are using the same name.
So instead of
image
according to the bug report there should be
settings.foreground.image
which is of course not working, since the dot is part of the path but not of the name.
But actually replacing the dot with an underscore and using some suffixes within the same flexform tab should do the trick:
settings.foreground.settings_foreground_image
settings.foreground.settings_foreground_image2
This way you make sure that
The field names within your flexform are unique
The actual field name within the sys_file_reference entry already contains the full path information
You can use that information to fetch images i.e. within a DataProcessor and still know the FlexForm field they actually belong to
Sitll I would recommend to fully move away form FlexForms (and thus Flux too) in favor of "real" fields in the database table.
If you currently use the flux:field.file element at typo3 10 with the useFalRelation=1 you can replace it by the flux:field element. It is not deprecated and works in combination with the flux:form.object element
Following example:
<flux:field.file
allowed="jpg,png,svg,gif"
exclude="false"
label="MyLabel"
name="myname"
showThumbnails="1"
useFalRelation="1"
maxItems="1"
minItems="1"
/>
Can be replaced with:
<flux:field type="input" name="myname" label="MyLabel"
config="{
type: 'group',
size: 1,
internal_type: 'db',
use_fal_relation: 1,
allowed: 'sys_file',
maxitems: 1,
minitems: 0,
show_thumbs: 1,
appearance: {
elementBrowserAllowed: 'jpg,png,svg,gif',
elementBrowserType: 'file'
}
}
"/>
I am trying to set up the following structure:
Landing-Page (Root-Template)
--- Content Webpage 1
--- Content Webpage 2
------ Other Sub stuff
--- Blog (Blog-Template)
------ Blog stuff (apply Blog-Template)
--- 404, etc.
My problem with this is that if I am applying the blog template to my blog root, then my template is applied to all sites at the same level (so: Content Webpage 1 & 2, ...).
How can I prevent this and only assign my blog template to this site and lower?
P.S.: I am a beginner, so a bit of background would be nice if this is possible. I read a few of the Tutorials on docs.typo3.org, but that did not help...
You an create a template-record on the page Blog, then only that page and subpages get that configuration. Else the default configuration is taken which is or has to be defined in the root-template.
You also could use Conditions in the root-template to check for the Blog-Page and assign the special template inside that condition. Assumed your Blog has the pid (Page-Id) 5 the condition would look like this:
... (other stuff before)
[PIDinRootline = 5]
here you special template configuration
[global]
... (other stuff afterwards)
There is another option but there you need already advanced knowledge, as it's not explained too deep in my answer there (the TCA-part is missing): how to add multiple fluid-templates.
Okay, I finally got it to work like I desired.
Because the Blog-Template is a static Template I just assigend it to the main Template. Important was the order of the static Template includes.
Fluid styled content
Bootstrap package
Typo3 Blog
Typo3 Blog Template
The reason for that is that the Typo3 Blog Template needs the Fluid styled content and because my Fluid styled content include was the last one before, Typo3 threw me an error that it was not able to find some fluid elements.
Is there a way to get the Log In Form for Frontend User on every page? I would prefer the footer.
And if someone is logged in you can see the Log Out Button.
Is this possible without an extension?
You can copy the default felogin output to wherever you want on your template. For example use lib.login, copy the plugin.tx_felogin_pi1 into it, change the template and you're fine.
lib.login < plugin.tx_felogin_pi1
lib.login.templateFile = path/to/your/template/file
More you can see in the official documentation: https://docs.typo3.org/typo3cms/extensions/felogin/8.7/Configuration/Index.html
In general there are three options to include a CE (e.g. the Login-form) on all pages:
use typoscript to generate the CE. Normally the CEs are defined in tt_content, from where you could copy the base configuration and adapt it. For some plugins you also find a complete configuration beyond lib (for newer extensions there you only find the settings). All the configuration must be done in typoscript.
use typoscript to render the content of a special page/ column. In this variant you have a special page only for content referenced somewhere else. Advantage: you could configure the CE in the usual way. Try to avoid referencing CEs by uid as an editor might disable or delete the current element(s) and insert a new one which would not be rendered.
use a special column in your root page and inherit the content to all subpages. Advantage: you could change the inherited content easily on each page (if this column is available in the current backend layout).
example for 3:
variables {
footer_content < styles.content.get
footer_content.select.where = colPos = 15
footer_content.slide = -1
}
I have a link-type field in the backend. This stores the information like this:
"3 _blank" <----- for internal pages
"http://www.google.com _blank" <--- for external pages
How can I build links in Typoscript, using this values? Common typolink technique wont apply here.
it will apply put these values as typolink's parameter
lib.mylink = TEXT
lib.mylink.parameter = 3 _blank
It will create a link to page
Page title here