I want to disable frontend indexing an make use of crawler. How to setup a crawler configuration for:
A) indexing the pagetree in several languages
B) indexing custom records in several languages
But there is nothing menitoned regarding languages in the documentation:
https://docs.typo3.org/typo3cms/extensions/indexed_search/IndexingConfigurations/CrawlerSetup/Index.html
Indexed search always uses frontend indexing. It only varies whether any visitor calls your page or if the crawler calls the page. Each time the cache is filled (by the first call) the content gets indexed.
The language configuration can be found in the manual:
https://docs.typo3.org/typo3cms/extensions/crawler/ExtCrawler/Configuration/ConfigurationRecords/Index.html (see the field 'Configuration') or the next page where paramSets.[key] gets described.
Be aware of any settings of the Url-parameter L, which is used as the language parameter for TYPO3.
Related
I would like to output additional data in most content elements (mostly fluid_styled_content) in the frontend for logged-in backend users (editing links for the CEs, additional information). The first idea was to insert additional Fluid code within <f:be.security.ifAuthenticated>. In theory this does the right thing, but the result is cached (bad: BE users might not see the additional data, others might see it). How does one work around this?
Ideas:
Use different templates for BE users. How?
Disable writing to and reading from the cache for BE users. How?
(Automatically) Assign a FE user group to BE users, because the cache should create different entries for each FE user group. How?
Render the additional output using JavaScript and get the data separately. Caching could work for all users, but complicated and would still require some way to discriminate between BE-/non-BE users. Would prefer not to implement this.
Requirements for a solution:
FE caching should continue to work for users which are not logged into the BE.
Caching for BE users does not necessarily have to work, but would be nice-to-have.
The output does not need to differ further between users.
You could deactivate the page cache for logged in backend users with a TypoScript condition:
[backend.user.isLoggedIn]
config.no_cache = 1
[global]
That seems excessive and there should be better solutions.
Ideas:
Add a cacheTag depending on BE login state (this would enable caching for all users)
disable caching in your content element definition's TypoScript by wrapping the FLUIDTEMPLATE in a COA_INT (see this SO post) (this would only disable caching for that FLUIDTEMPLATE)
Can <f:cache.disable> around the condition help? I found these to have no effect in plain content elements (FLUIDTEMPLATE), though.
Can <vhs:render.uncache> help?
I guess what you are looking for is called "frontend editing" - it is available as an extension that can be found here: https://extensions.typo3.org/extension/frontend_editing
i want to edit an existing Typo3 Backend configuration page.
I want to edit a configuration page like this here:
Where can i edit the extensions backend?
To be more clear: where can i change the edit page that an editor can use to change content.
Can someone give me a hint to the right directory or file in generall?
I'm using Typo3-7.6
Thanks
Sorry, can't manage to put all questions in an unformatted comment.
there are a lot of questions, as you are not clear what you want. Maybe that is a problem of the correct words, the vocabluary, but in TYPO3 we have some fix terms for specific object. And I think you do not handle these terms according to the TYPO3 community.
let's define some terms:
first the concept of TYPO3:
all data is stored in record of differnt database tables. All records are organized with some fields and teh main field is uid, the unique ID.
the main table is pages according to the folders of your disk. those folders can contain other records (like files). (nearly) each record in TYPO3 has a relation to a pagesrecord ina field named pid. even pagesrecords have this field and so they build a tree of pages and subpages.
There is one special page, which is no real page: the page with the ' uid' zero. As there is no real pagesrecord with the uidzero, there are other records with are stored in that page by having a pid zero. for example the start of your page tree is anchored in page zero, or global records like languages, user, storages.
Aside of being the anchor to other records, the pagesrecords have information themself. (page name, kind of page, a teaser image, SEO-information, visibility, accessibility, ...)
your screenshot looks like a content record (normaly in the table tt_content), in the lower right corner there you can see the table name and the uidthe the currently edited record.
'Backend': with backend we name the view to the data where an editor can change the content of the website. The real website is the frontend. This can be seen by everyone without the need to login in the backend (you might have access-restriccted areas of your website which need a login, but that still is 'frontend' as there is no option to edit content.
in the backend the editor might be restricted what he can access and what he can modify. An adminuser has no restriction (up until version 9 where the role of a maintainer occured to manage more general and basic options)
so we have not a single 'backend configuration page' but multiple places where we could configure special aspects of the website.
also there is no special 'extension backend'. we have global extension configuration and records belonging to an extension. (And an extension can enhance existing records with additional fields.)
Please be more specific what you want to change
I am new to TYPO3 and have trouble understanding the general relation between extensions and the backend of TYPO3.
For example, is it true that the goal of making an extension is to be able add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
For example if I wanted to add a carousel to my page, would I make an extension and design it in such a way that I can add it from my backend to the desired page? Or would it make more sense to, for example, put it as a partial and import it to the desired page using fluid (all of this without using the backend and just using code).
Or are both approaches possible and when would you go for the first or the second (or seek out a third approach)?
Sorry if this question is too general/vague. I feel like I do not understand how the backend and the files in my TYPO3 folder communicate to generate the website and that I am using content elements in the backend one time and typing out the elements in HTML the next time without a good reason for it.
I try to bring some light into the dark areas.
Backend This is the admin area of the CMS where in most cases the content is created by editors.
Frontend: How the website looks to a regular visitor
Extension: An extension is custom code, either your own code or by others which extend TYPO3 in one or more ways. The benefit is that you don't change the code of TYPO3 core itself and therefore it can be always updated.
An extension can be used for a lot of things:
- Shipping a site template with all the assets like CSS, JavaScript, HTML template, ..
- Providing custom content elements
- Providing new record types like news or forms
- Improve user experience
So yes, if you want to have a new kind of content elements you need to use an extension:
Search on https://extensions.typo3.org to check if there is already something which fits your needs
Use https://extensions.typo3.org/extension/mask/ (best in combination with https://extensions.typo3.org/extension/mask_export/) or https://extensions.typo3.org/extension/dce/ to make it a lot faster to create content elements
If experienced you can also create a custom content elements without any additional extension but for start I don't recommend that.
One approach to look at this question in a different way might be to differentiate between content created and maintained by editors (the backend users which typically add and maintain content) and parts of the visible webpages created in other ways. For example, the header, footer, menu of a site may be created by a sitepackage extension - this is something the editor (backend user without admin access) typically has no permission to access and that is one of the points of a CMS - the content is editable by someone without technical background. Of course this improves the stability as well because you don't have people fiddling around with things they should not be able to have access to and thus cannot break.
If you want your editors to be able to add (remove, change) content - do it in a way they have access to (typically using content elements).
You are right, the core provides content elements (such as "textmedia"), extensions can extend this by adding other content elements.
For your example with "carousel" you might want to look at the (official) Introduction Package which uses the bootstrap_package which offers a carousel content element. The Installation Guide explains how to setup a TYPO3 installation with "Introduction Package" so you may already be using that.
For example, is it true that the goal of making an extension is to be able to add edited/new content elements to your page that cannot be found in TYPO3 out of the box?
That is one of many, many other possible purposes of an extension. For example, look at the extension "min". It does not provide any content element and there is no visible change for the editor. An extension is just a way to extend the TYPO3 core (while the core itself also consists of extensions).
Introduction of Extensions in TYPO3 Explained
Sitepackage Tutorial
I know it's possible to create a page from a form using the built-in 'Create from the template' macro but are my options for updating existing pages from a form limited to paying for a plugin, like ConfiForms or Frevvo?
I would say that it is dependent on the type of update you want to do. An example - you want to update some part of page recursively for n number of pages, you can write a script which uses confluence rest api to do so. Out-of-the-box and suggested way are plugins.
I've done several sites with TYPO3 indexed_search. However I feel I still do not understand the nature of the relation between indexed_search and crawler. For instance, according to some authors to index tt_news I just need a generic crawler configuration and an indexed_search configuration for tt_news; but for other authors of tutorials and such I should create a crawler configuration for tt_news.
It is not clear to me what the relation is between crawler and indexed_search. How do they match? Shouldn't it be sufficient a root crawler configuration that when it finds an indexed_search configuration just runs it? Or does the URLs need to be generated by both? I've managed to create an index with just one crawler root configuration but I run the indexing through my own shell script that calls cli_dispatch.phpsh.
Are indexed_search and crawler redundant in terms of functionality (generation of URLs)?
Any clues are welcome.
Bests,
B.
Indexed_search can work without a crawler by indexing pages that are visited by visitors. The obvious disadvantage is that pages that aren't visited won't be indexed and thus won't show up in search results. If you have several frontend user groups configured then the chances that a page is visited are even lower.
The crawler can solve this by visiting each page. Furthermore it can visit pages as if it were member of (a combination of) FE user groups. This way it can help build the index of an entire website for all kinds of users.
Most of the details are explained in a tutorial by Xavier Perseguers. It's written for an older version but I guess that most of it is still valid.
(It's been a while since I last used indexed_search, but at that time the tutorial helped a lot).