Experiences with 1400-article-blog in Treepl CMS - problems and solutions

I made a little video to showcase what we liked with Treepl when we migrated and relaunched a blog with aprox. 1400 articles, what problems we had and what solutions we found:

2 Likes

Thanks for sharing your experience.

Nice work @TimL.
In the Treehouse meeting you talked about the Tags module and the loading issues and I know Treepl are going to work on optimising this. But I noticed you have the tag component twice. Once for the top 20 list and another for the filter.
Could you instead just have it once in the template, creating a collectionVariable, and then render the two section from the one collection? May need to do a bit more work with the Liquid logic, but it could cut down on the component calls.

Another option could be to generate these two section on a blank page and AJAX them in after initial blog page load - since they are not critical elements to have ready straight-away.

@Adam.Wilson Yeah, that’s right. Vlad was pointing to that, too. And helped me out with this code for the blog filter form:

{% if Blogtags == null %}

{% component type: “module_tag_list”, module: “1858”, sortBy: “name”, sortOrder: “ASC”, CollectionVariable: “AllTags”, limit: “2000” %}

{% assign AllTags = AllTags.items %}

{% else %}

{% assign AllTags = Blogtags.items | sort:“name” %}

{% endif %}

{% for item in AllTags %}

…

{% endfor %}

So the tag collection in the filter form is only rendered if the other one for the top-20 (Blogtags) isn’t present (which is good practice). He also used a filter on the collection to sort alphabetically rather than in the component tag. Those changes brought down render times from over 10 seconds to around 6 seconds.
I’m interested in the Ajax solution though. I was thinking of that but I’m not good with Ajax. Do you have some example JS for me to try?
As mentioned, Vlad told me that optimization for module_ tag_list and module_category_list is on the way …

Here are a couple of things that I might try.

For sorting by tags, is search any faster? Might be worth trying to pass a url param to a pre-populated search form? A different possible strategy.

For the editors needing to find posts, If I was stuck in that situation I guess I could create a front end version of the blog post lists and then generate the URL for the editor on the back end.

Not sure if either is feasible, but just some different ideas.

Another thought, regarding the issue of sorting and assigning tags to posts, what about using another custom module as a data source to replace the tag list.

I can’t remember if data source items are sorted by name either.

@TimL How long does it take to output the entire list on the front end? I’m wondering if you could load your first batch of articles and then load the entire list in a hidden way below in the background, then when a user filters by tag you hide the first list, and show the entire list filtered with JS on the front end?

Just another possible strategy?

Ah, ok. So both tag components never load together. That’s good.

For the AJAX method, you might set up a blank, no template, page with your tag component and Liquid formatting in place. Let’s call it /ajax-tags.
Wrap this content in a div with ID like tagSource.

Then in your blog, replace the tags section with a div of ID tagHolder and run something like this:

$.get('/ajax-tags', function(data) {
    $('#tagHolder').html(data).find('#tagSource');
    // do other stuff if needed...
});

I haven’t tested this but it should work :slight_smile:

More info on this jQuery function: https://api.jquery.com/jQuery.get/

1 Like

Thanks for your thoughts, @Alex_B_Centrifuge. The difficulty with using the front end to list and find posts is that items with a release date in the future won’t show up there. The editors usually work one day in the week, they write all the posts and schedule them for release in the following days.
I need to check on the idea of using another custom module for tagging. But if you need more than one tag per post this would get clunky as you would need to create multiple data source properties. But it’s worth contemplating about this …

Thanks a lot, @Adam.Wilson!

@vlad.z @Eugene I guess you already have your eyes on the issue with the flawed sorting in list view for custom module items and system module items over all pages.
Regarding tags: I like the way they can be sorted by drag and drop in the Admin. It just doesn’t work well with a lot of tags. One solution would be to give the option to sort the tags alphabetically as a preset and then sort by drag and drop again. We will create a backlog request for that in case you guys don’t already have another solution on the way.

1 Like

Oh yeah, I missed this. Of course.

Welcome to the forum, @DonGibson. Haven’t used Salesforce yet. Can you give us specifics about the problem with the blog? How is Salesforces integrated on the site, via Javascript widget?

Public backlog request for sorting would be perfect since we have no internal task for this yet.
As for the {% component type: “module_tag_list” %} - it will be optimized in the current sprint.

@Vlad, with sorting you mean the problem that module items only sort per page in list view? I can write a backlog request for that but to be honest, to me this is not a feature request but a bug. It just doesn’t make sense to have a list view with pagination if sorting only works per page - unless you limit the number of items to not more than 50. But then you don’t need pagination in the first place. I was sure you guys are aware that this is not usuable and that you are already working on a fix. Can you please confirm that you need a backlog request for this?

2 Likes

Hi @TimL

I mean the desired solution for sorting tags in the admin panel (on item detail view).
As for the sorting items per page on item list view - we already have this improvement listed as feedback task in our internal backlog

2 Likes