0 users online. Create an account or sign in to join them.Users

Search

I am having trouble again with dealing with too much data :)

The scenario: i have 9576 enrtries in a catalog section.
Some of the items are submodules that need to be linked to other items in the same section.
First i tried the subsection manager, but that was causing memory problems as expected. even with increasing the memory limit in my httacces file to 1gb.

Then i tried the select box link, which renders the list of my 9576 entries fine although it takes a couple of seconds.

Now i am able to load the linked items in a new datasource that is filterded by the parameter output of the selectbox values in the original ds (datasource chaining)

The problem here is that it's almost impossible to select the submodules in the selectbox link field, because of the really long list.

I found a nice solution by using a tag list field and the Autocomplete Tags extension.
Which creates a nice autocomplete list where you can easely search and select the submodules.

Only problem is that the parameter output of this field contains the article numbers from the 'article number field' And somehow i can't filter the second datasource on these values when i use a filter field for 'articlenumber'.

I guess a comma seperated list for fitering only applies on entry id's like the selectbox link does.

So finally i come to this question; can i somehow tweak the taglist (which is in symphony's core and not an extension) that it can also output entry id's in the output parameter like the selectbox link?

Or can someone make a suggestion on making a user friendly selectbox link that can deal with lots of data?

Thanks in advance.

Edit: forget about the taglist option, it's messing with my csv exports
I'll stick to the selectbox link for now, but if someone has a userfriendly solution for selecting multiple items in a 9576 item selectbox list, i am happy to hear

Have you tried the Reference Link Field extension? It has a very fast search/autocomplete functionality.

A thought on it: This autocomplete stuff could be added to the standard SBL field as well. One might build an extension that simply puts this functionality "on top" of SBL fields. If I only had more time...

Wow, thank you michael for pointing this out, it's perfect!
I was just playing with the 'autocoplete tags' extension to tweak it so i could get the selectbox link to autocomplete, but with not much succes.

Would be cool if i managed to do that so i could finaly have an extension... but i think the structure of a selectbox is much harder to convert then the taglist field.

Anyway, no need for that now with this extension!

Btw i am using this for the xml to indesign job i was talking about,
Tackled lots of difficulties, but working really well now, got a nice project going now

This submodule autocomplete field is a really usefull feature!

So you find the reference link field and its autocomplete work okay with 9.5k entries? I'm setting up a project which may use this field to link to a section which will end up having about 1k entries, and a SBL+ field which links to a section which will have about 2k entries (used to enable adding of child entries when creating parent entries).

I believe both these fields load all options into the browser in full at page load...

Yes, they do. But up to a certain amount of data this technique will perform better than doing an AJAX request on every keystroke. The fascinating thing about the Reference Link Field is that the jQuery autocomplete is very fast.

I myself haven't tested this with more than 2000 entries, however. In this situation the user experience was very good.

So you find the reference link field and its autocomplete work okay with 9.5k entries?

It's working 'okay', but it takes the back-end page about 5 seconds to load. Also every entrie contains 30 fields...
So i had to increase the memory limit to 1 GB in the .httacces file to make this work. (Hope i don't get troubles with my hosting again)
I really have no other choice, cause without the extra memory it would be a show stopper.

So i think with 2k entries you should be fine, maybe even without memory increase.

This i think is somewhat a downside of symphony, with amounts of data like this, memory issues take place. Don't know if this is symphony related or other cms'es like wordpress deal with this also?

Edit:
i forgot to mention that when the page is loaded, the autocoplete works like a charm; pops up instantly

A thought on it: This autocomplete stuff could be added to the standard SBL field as well. One might build an extension that simply puts this functionality "on top" of SBL fields. If I only had more time...

This sounds like a good view option for the Select Box Link Plus (or is it "Advanced"?) field! The Reference link is just a SBL field with a jQuery autocomplete on top, as far as I remember. So all options are loaded into the DOM. Which is slow. It could be rewritten so that all options are not loaded into the DOM, but are searched using an AJAX request instead. This would make page loads much lighter, but the searching would be slightly slower (an AJAX request calling the DB rather than parsing a cached array).

I really would love to see some lazy loading ajax in these types of extension, as I've had troubles myself with entry counts (Nick knows all about my moaning on that one).

Jut having paging type loading would be great, i.e. load 10 entries, when the 10 are done, load the next 10, and so on...

I'm sure this would speed things up so the UI is available almost instantly, and all the entries would become available piece by piece.

Multiple entry selecting over several lazy loaded entries though... how could that part be addressed? checkboxes?

It might be worth noting that a while ago I actually modified the Reference Link's behaviour to use jQuery autocomplete + AJAX (see commits). This uses autocomplete to load the possible entries by AJAX, removing the need to populate the DOM and then hide them, which does get a bit messy when dealing with large amounts of entries.

Edit Ah so yeah, pretty much did exactly what Nick described earlier :P

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.1
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details