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.
Related
I'm currently on a Looker project, in the model in one of the explorers there are many joins that pull a lot of information, but as the customer says, this is just the beginning. I don't understand how to unload it, persist doesn't help, I tried to make a data_group.
Now I’ve picked up the PDTs, but I don’t understand how they can be implemented if i font have a querie. It is possible only through lookML to pull out a delay table or a sql that the looker has generated based on what we have in the look.
The looks like a regular table with 8 fields, it takes a long time to open, I tried to comment on unused dimensions and measures, I tried to delete those joins on which we do not depend, nothing comes out .... a fresh look may be needed
I've done quit a couple of upgrades from t3 4.X to 6.X but this time I have a persistent problem I cannot not understand. After doing the upgrade (all upgrade wizards ran fine), I can see in the database that the image column of tt_content has the FAL index values in it and not the file names anymore. The references to the FAL tables are ok as well. When I look at CEs like textpic, however, the image tab does not show any images. No images are shown in the FW either.
I could think of trying to fix this in TS but I want to upgrade this install to 8 and think that when the first upgrade needs such a clutch, further updates will be doomed right from the start.
[edit #1]
I'm 100% sure it worked before. But now, whatever I do (update ref index, ...), sys_file_reference stays empty.
[edit #2]
I now followed How to upgrade TYPO3 4.5 to 6.2 and it worked. Strange thing is that it's not really that different from how I did it all the time. Maybe it just needed me to try it 27 times :)
your problem might depend on individual contentelements. if you have individual definitions the upgrade wizard does not know, these definitions stay unchanged and as a result your 'new' images (sys_file records) are not inserted correctly.
Individual CEs might need extra care at each upgrade.
After 6.2 FAL was stable and had no big changes. I would not expect the same amount of work for further upgrades.
In TYPO3 Version 6.2 the fileadmin-folder is represented by an automatically created storage record. In this record is a setting to respect case-sensitive filenames.
If this setting is not enabled before the migration of all media-files, then all media-files with upper-case characters are written in the database but not found anymore by the file-system because they are written lower case then.
So if you never find any images on the page after migration I assume all images had one or more upper-case characters in the filename.
If you've only a few images you could change the filename in the database, specifically in the table sys_file and the column identifier, else it's the best to repeat the whole process and care about the setting in the storage-record fileadmin in time.
Storage-records are located on the root-page [uid=0] in the backend, where also backend-users are resided.
Below is a partial screenshot of the database-table sys_file:
My experience was that mysql mode SQL_STRICT_TRANS_TABLES was in the middle of the problem. Once changed, sys_file_reference begins to fill the records correctly.
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!
We are using the plugin https://goodies.pixabay.com/jquery/tag-editor/demo.html for our AutoComplete feature. We load the source with 3500 items. The performance gets too bad when the user starts typing and the autocomplete loads the filtered result after 6 to 8 seconds.
What are alternate approach that we can take for upto 4000 items for Autocomplete.
Appreciate your response!
are you using the minLength attribute from autocomplete?
on their homepage, they have something like this:
$('#my_textarea').tagEditor({ autocomplete: { 'source': '/url/', minLength: 3 } });
this effectively means, that the user has to enter at least 3 charaters before autocomplete will be used. doing so will usually reduce the amount of results from the autocomplete to a more sane count (like 20-30 maybe).
However, this might not necessarily be your problem. first you should figure out, if it's your server that's got a problem with responding fast (you can use your browser developer toolbar to see how long the requests takes to complete).
If the request takes 6-8 seconds, then you will have to optimize your server's code. On the other hand, if the response is quick, but tageditor needs a long time to build the suggestion list, then the problem is, that it might not be optimized for so many suggestions. in that case, the ultimate solution would be to rewrite the autocompletion module yourself or patch the existing one to better scale to your needs.
Do you go back to the server every time the user types in something to get the matching results?
I am using SPRING ehcache which gets all the items from database and stores in the server cache when the server is started. Whenever the user types the cached data is used which gets the results with few milliseconds. Some one else recommended me to use this.Below is the example for it
http://www.mkyong.com/ehcache/ehcache-hello-world-example/
I am using the jQuery autocomplete features with 2500 items without any issue.
here is the link where it being used http://www.all4sportsonline.com
I am working on a new web app which is based in ExpressionEngine and for the most part I am basing the content on channel entries. However I am experiencing some very weird issues with the exp channel entries tag in that it is not returning all relevant entries each time. I can't figure out what's going on with it as the entries are definitely available when viewing them in the control panel, and they will also show up as requested in my template, but sometimes they just disappear and/or are not processed properly. This is the case for large and small sets of entries also, ranging from 3 channel entries which fit the criteria specified within the exp tag to 500 entries.
Any thoughts or feedback would be greatly appreciated.
There could be a number of things going on here so here are some things to look at, just in case;
If the entries have entry dates in the future - you'll need your channel entries tag to have the parameter show_future_entries = "yes"
Likewise if the entries are closed, or expired, you'll need to add show="open|closed"
Are you looking at a particular category and these entries aren't assigned to the category?
Are you looking at a particular category but have exlcuded category data from the entries tag
Are you retrieving more than 100 entries? There is a default limit of 100 entries returned unless you specify a limit parameter.