Concerns about version 2
Have to say that I'm not all that enthralled by the need to remove the channel entries tag - it adds in an area of uncertainty when using channel entry parameters in low_reorder:entries and when debugging. I know your docs say it works identical to the channel entries tag, but who should we go to with a channel entries problem now - Low or EL. In fact EL wouldn't help. Be useful if the old version was still available. I'm no dev, but what about other 3 party add-ons that introduce parameters that can be used in the channel entries tag - will they work in low_reorder:entries? What if EL extend the channel entries tag? What about other add-ons that replace the channel entries tag with theirs - how would I use low_reorder then?
Best wishes
Lee
Replies
Low 1 May 2012 09:07
Hi Lee,
I understand your concern and I have thought a lot about this transition. The final conclusion was, if I was to add more flexibility to the add-on, I needed to step away from the custom field approach. It was too limiting for the stuff that I wanted to implement and for feature requests.
Behind the scenes, I now populate the fixed_order="" parameter of the channel:entries tag before calling it. There are no extension hooks in place to manipulate this directly, which is why I'm forced to "mask" the channel:entries tag with the low_reorder:entries tag. I use the same approach for my Low Search and Low Alphabet add-ons, so I've built quite a bit of experience with this approach. It works well.
If you encounter a problem with the tag, ask me. I'm dedicated to my add-ons and in offering the best support I can. If that means I encounter a problem with the EL core code, I will be able to spot this quickly and take the appropriate measures (either fixing my own add-on, adding a workaround or reporting a bug at EL). Since I use the same approach for more of my add-ons, I will be watching this closely.
As for other add-ons and their parameters: this is no cause for concern. Internally, the channel:entries tag is called and all existing parameters are read as you would expect.
Also, be aware that I am in the developer preview program, so all significant changes to the channel:entries will come to my attention before they are released. I can make the necessary changes to my add-ons accordingly, if that ever happens.
In short, the low_reorder:entries tag really does work identically to the channel:entries tag, now and in the future. If you run into any issues, come to me for support, and I'll get you sorted (pardon the pun) straight away.
leeaston 1 May 2012 09:44
Thanks for the writeup.
What happens when other add-ons take the same approach and replace the channel entries tag, how would I use low_reorder then?
Low 1 May 2012 09:49
Well, if they do, it's usually to display entries in a certain order or limited by given parameters, like Low Alphabet and Low Search. In both cases, there's no need to use Low Reorder, as that defeats the purpose of the former add-on. I haven't come across any issues with this so far, and am not aware of any add-on that might cause them. If you have an example, I'm all ears.
Leevi Graham 1 May 2012 09:53
Hi Lee,
Masking the channel:entries tag is a pretty common. NSM Categories, NSM Channels, NSM Better Meta all use the same technique. It provides powerful functionality and built inherited custom field support.
The only downside I have found is the processing overhead. channel:entries is quite memory intensive even with the disable param. In the case of Low Reorder this isn't a problem because previously you would have been using a custom field and loading a full channel:entries tag anyway.
Cheers Leevi
leeaston 1 May 2012 10:14
Thanks guy's! So for example can NSM Channels and Low Reorder work together?
Low 1 May 2012 10:21
If you're after something like this:
...then yes.
(Note, that code is to make a point, not necessarily good code, because of this.)