Closed (fixed)
Project:
Entityqueue
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
12 Jul 2012 at 09:08 UTC
Updated:
17 Dec 2013 at 21:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
roam2345 commentedThis patch adds the ability to sort on the entities position in the queue.
Comment #2
roam2345 commentedMissed some field in previous patch
Comment #3
mrfelton commentedNot sure why, but that wasn't applying for me. Had a whitespace issue too. Here is one that applies cleanly.
Comment #4
bibo commented@mrfelton, sorry but your patch didnt apply (not to the latest july-7 version), while jucallmes patch in #2 worked as expected.
However, even that patch failed when it was used with drush make to build our site. It turned out that the problem was related to .info files and a certain bug in drush. That bug has been fixed in drush 5.7. After upgrading drush 5.4 -> 5.7, our drush make runs fine.
Marking as RTBC.
Comment #5
mrfelton commentedThanks for the heads up @bibo. It was a drush make issue that I was experiencing too, so will try upgrading there.
Comment #6
bibo commentedThe sorting seemed to work, but only partially and caused weird timeout errors. Currently we use the patch but not really the filters (hope to firgure it out later).
Also: the patch applying informed about a lot of offset (success still), so I wonder if it should be redone for the current version?
Comment #7
eft commentedHere is another patch. I created it by first applying @mrfelton's one from #3. Then I ran git diff again and excluded the prefixes (so the patch credits have been removed). Tested with Drush Make (Drush 4.5 even) and it applied fine. Just had to remember to specify the correct branch in the entityqueue repo.
Testing showed the Subqueue: Position field in the field list as expected and the sort list but the field was not in the list of filterable attributes.
Thanks to everyone behind the effort to move the project forward.
Comment #8
bibo commented@eft : which entityqueue dev-version are you using? Do you have a link to the commit?
It seemed to fail against my current version:
projects[entityqueue][download][revision] = "f34c4214819b2bcce9dcb2f9ed0a5d132aa59edb"Will try with latest dev.
Comment #9
bibo commentedPlease elaborate.
My make file fails the patching with these settings:
I also tried manually with "patch -p1 <", "patch -p0 -" and "git patch", and they all fail with various erros, such as:
Comment #10
eft commentedThis is how I configure my make file:
Comment #11
bibo commentedThanks eft, but for some reason the patch still fails with those settings in drush makefile.
Could it be that the branch youre using has changed meanwhile? I would patch only against a specific commit, since branches might evolve fast.
Im using drush 5.7.
Comment #12
paulihuhtiniemi commentedI had also problems applying patch in comment #7, so here's a re-created version of the same patch.
Comment #13
paulihuhtiniemi commentedI also noticed that there were problems with views where relationship to queue was not required. Here's another patch (apply after previous patch), that updates the entityqueue_sort() and render() functions. Not the most elegant solution, but seems to work for me.
Sorting is now done with custom usort() comparison function. It kind of sounds something that should rather be done with SQL, or what do you think?
Comment #14
paulihuhtiniemi commentedForget that patch in #13, it doesn't actually work :( As PHP manual says: "The cmp_function doesn't keep the original order for elements comparing as equal." http://php.net/manual/en/function.usort.php
Comment #15
jojonaloha commentedThere are a couple issues I see with these approaches.
I thought there was already a way to sort on the delta column of a field, but it looks like we are wiping that out in entityqueue_views_data_alter() when
unset($data[$field_table]);is called.I tried removing that and clearing all caches and then I was able to add the sort on delta, but then my view was joining the field_data_eq_node table a second time.
Example views query:
Other then that, I think removing the unset works as I'd expect. I'm thinking that instead of unsetting the field table, we could override the handlers with our own handler that removes the extra join.
The only other thing is that NULL values are sorted first if you don't want the relationship to be required. With Nodequeue views I typically get around that by adding a sort by Queue ID DESC before the Queue Position sort. I think adding a queue id sort handler would be an easy way to achieve the same result here too.
Comment #16
amateescu commentedOr we could copy the relevant parts from the field handler before unsetting it.
The only reason for unsetting the field stuff was to not have duplicate ways of dealing with entityqueue in views, so I would be happy with any solution that accomplishes that goal :)
Also, for everyone following this issue, I just merged the
7.x-1.x-ctoolsbranch into 7.x-1.x so we have a unified codebase to work on.Comment #17
jojonaloha commentedAttached is a patch that keeps the necessary information for sorting on the delta column. It also adds the queue and subqueue machine names for sorting.
The problem I see is that it still creates another join. Here is a sample query from views:
From what I can tell the query still returns the results I would expect, but the extra join makes me leery, especially when the relationship is optional.
I had also tried removing the table info, but then it doesn't show in the Sort options, and I think it's because it doesn't know that the table has already been joined? I'm still thinking a simple custom sort handler might be a way around this.
I'm also leaving this in "Needs work" for now because there are issues if you use the MultipleEntityQueueHandler (or any other handler where the $subqueue->name != $queue->name).
Comment #18
jojonaloha commentedOk, I think this is the better approach. It adds a new sort handler and instead of keeping the delta sort on the field_data table, it uses the fake entityqueue_relationship field to add the sort handler. Since it relies on the relationship, I added an error message if they try adding the sort without the relationship (not sure if there is a built-in way in views to require that). I had tried to add it to $data['entityqueue_subqueue'][$field_name . '_position'] instead so that the relationship was inherently required, but then for every type of queue (node, user, etc) there is another sort option, which just clutters up the UI and you have to select the right one.
For the MultipleEntityQueueHandler issue, at first I thought we could change entityqueue_get_options() to key by entity id for subqueues (maybe add a third optional parameter). Then instead of adding a join condition on the bundle it would be on the entity_id. The problem I see there is then the views are only exportable if the subqueues have the same entity id.
Given that, I think that option is out. So instead, I am selecting the queue names for the selected subqueues so we can add a join condition on the bundle.
Comment #19
amateescu commentedEdit: Scratch that, didn't look close enough..
Comment #20
jojonaloha commentedUpdated patch based on issues brought up in #2149117: Typo and ambiguity on views relationship
Comment #21
amateescu commentedCool, let's do this.
Comment #22
jojonaloha commentedCommitted 7e3b9e4