I build a DCE content element where users can add new products for different categories. So I use sections as follow:
Problem is that I can add only up to 34 new elements. After that I can create new elements but TYPO3 is not saving that. So it is not possible to add new products
Are there any limitations or something else? Or had someone the same problem?
Thank you
Mando
Usually, there is no limit on the number of flex section container elements.
Have a look at your webserver logs, maybe some POST values are dropped, and try to increase the size of the underlying DB field, maybe thats cut off.
go to the php settings, then to max_input_vars and increase the limit/number to 2000. It will work!
Related
Configuration: TYPO3 7.6.30, tx_cal 1.11.1, realurl 2.1.8
Problem: the realurl table tx_realurl_urlcache gets bigger and bigger with millions of entries and the whole system slows down extremely until I truncate the table.
It seems that is the case because the urls for single events contains the chash. They looks like this:
detailansicht/cal/event///tx_cal_phpicalendar//carmine-abate-der-huegel-des-windes/?tx_cal_controller%5Byear%5D=2018&tx_cal_controller%5Bmonth%5D=12&tx_cal_controller%5Bday%5D=13&cHash=c9eebc60256d7201b969e975ee151d94
Any idea whats going wrong here?
Thanks!
Your problem could be that search engines follow all your links and any repeated events will result in indefinite further 'pages'.
Try to restrict the spidering with no-follow / no-index directives. at least for dates more than x month in future/past.
Otherwise restrict visibility of such events at all.
What is the best way to allow backend users to edit variables?
For example, I have a TYPO3 that sends out various e-Mail notifications and I want the backend users to be able to globally change the recipients. I started with template constants, until I found out, that backend users cannot edit the "template" module.
So what would be the best way to achieve this? I'm using Typo3 8.7.7
I would create a configuration record which can be edited by the backend users.
one way would be to include one file from fileadmin/ into the constants definition of typoscript. This file editors could change. But that could be a security risk, as the editors could define any constants.
the next option would be to define additional fields to the pages record, where these values could be set by any editor. In typoscript you access the field (maybe with slide = -1, so the value needs to be set just once)
another option: add these fields to a (special?) CE (ContentElement).
last option: use std CEs (e.g.HTML-content) at special pages or columns and use the content field (bodytext). (HTML-content has the advantage that the bodytext field is stored unmodified.)
Cleanest and leanest option would be option two (additional fields to table 'pages'). Option three and four are possible with pure typoscript, but you need to use CONTENT or RECORD object. If you use fix uids: remember that your editors might delete the CE and add a new CE with the same content (but another uid)
Addition:
As #Thomas-Löffler in his answer said:
you also can add a new kind of record/table, where an editor can insert or change the global values. Handling is like pages or tt_content. you can differ if your records are global (pid = 0, or special storage page) or dependent on page tree (rootpath), so you can have differnt values for different page subtrees.
I like Thomas‘ answer for providing a dedicated place to store the configuration option instead of putting it e.g. to pages because your configuration option is not bound to a page context.
Nonetheless for me personally it feels a bit odd to create a dedicated table for it. A table that would never hold more than one record.
That leads me to the conclusion that a key-value storage would be the right thing to use. Fortunately, TYPO3 ships System Registry. The only downside is that there‘s no interface for it so you‘d have to come up with your own forms to fill it. That‘s much easier if you go with Thomas‘ solution…
A clean and easy way is setting up a backend module with a form to set the email addresses.
Then you can grant the access right to a specific group or user and they are ready to go.
I want to migrate existing news from one instance to another one incl. relations to FAL and content elements.
What is the best practise? I tried T3D Export, but it needs too much memory. Is this the only solution or do you have better ones?
1st you can try to export smaller chunks.
2nd you can do the export by hand. But then you must know which records are involved and what files are involved. And you must handle uid-collisions!
Starting with a simple query for your news-records.
Then you need all related records: FAL, tt_content, categories
Depending on your tt_content records you might need further related records - typical: FAL
Then you need to identify all the files.
Before you import all the records: make sure the used uids are unused in your target installation. oherwise you need to modify your uids (e.g.: you can add a constant value of 10000 to all your uids)
I wanted to find out how to specify fields to appear side-by-side in BIRT layout e.g.- City State Zip in a address line. By default, it seems to put the fields one below another and I can't seem to find a way to reposition them side-by-side
BIRT 2.6.0 and Eclipse Helios
I would use a grid to control the placement of the controls on the page. BIRT uses a web design metaphor and as such things need to be placed explicitly on a page. When you are building a page in simple HTML you often need a table or some other structural element to control how one piece of text (or image) relates to another. BIRT is no different in this regard.
Good Luck!
Using a grid for this is not the right solution unless you actually want elements aligned into columns.
If you set the Display value of your Data elements to Inline instead of Block they will be displayed side by side on the same line exactly like you want.
I use BIRT 2.3.2, and it normally puts fields side-by-side, by default. This may be an issue to do with which report item type you are using to display your data - try using a table, rather than a list report item.
The BIRT does not follow the placement of element based upon the X, Y coordinate instead it used relative tabular layout. So, fields can only be placed in sequential manner. To align it perfectly, Grid control can be used with needed rows and columns and set the width and height of columns.
However, this is just a workaround to place the element, exact placement of element on absolute position is yet not available. May be in future release it could be added into the BIRT.
after exporting jasperreport template, I found that the number of records per page depends on pageHeight. Suppose I always want all the records to be on one page, is there a way to specify this? is there a way to get how many records I want per page? it seems to be depending on height of the report.
You could put in a page break that prints out when $V{REPORT_COUNT} == $P{SOME_NUMBER}. This would force a new page to start.
You can't really ensure that all the records will be on one page unless you only get X number of records. Jasper is built to output the data you give it and if you give it lots of data it will try to output it all.
You can do things like make the font smaller to put more data on the page or to use columns so that data will use the space more efficiently.
Maybe if you give a description of what you want to do a suggestion more suited to your needs may be possible? :)