Flexinode table view by taxonomy terms

Oops, not logged in. That was me.

It helped me. Have a beer.

I'd like to use this but I'm getting the following when I try to access admin-modules to enable it:

Parse error: parse error, unexpected '{' in /path/to/modules/flexinode_terms_extension.module on line 6

This worked great for me under 4.5, but 4.6 appears to break it. Any ideas on what it would take to fix?

OK, I fixed it. Minor edits to work with 4.6. Attached.

Steering clear of flexinode.... ;)

please add the patch again but *without the word module in it*. it seems to be lost ATM.

Thanks a LOT for this. It gave me a good start on achiving what I needed.
BUT, I wanted to SORT on the taxonomy fields, not filter (as the above one did)

Here's my version (some dirty code, it's just a FYI, standalone module, not a commit)

It adds taxonomy fields as an indexable, sortable column identical to flexinode behaviour.

Currently - it only works on REQUIRED, SINGLE term vocabularies, and the ordering of the columns has not been implimented.
But it was fun finding how flexinode abstracts the 'field types' into their own little hooks.
The SQL required is not a place I want to visit again, however. The SQL query came out taking up half a page!

.dan.

Sounds great, so I installed the module. Any tips on how to acutally use it :(

Anyone successfully using the flexinode_terms_extension.module w/ 4.7? :-)

okay, i installed flexinode_terms_extension_0, enabled in on the modules page, and went to

.../flexinode/termstable/1/7 (which should work for my taxonomy)

but i got the page not found.

(curious why leafish_paul is steering clear of flexinode..)

i have got the same problem as skid, with a drupal 4.6 site and flexinode_terms_extension_0.module: I always get a "Page not found" error

For those of you having trouble with this: it is not a patch, rather it is a contributed module. Place it in your flexinode directory and enable it as a seperate module. That should fix it.

For Drupal 4.7, you need to replace line 93:
$output .= theme('pager', '', 20, 0, 'default', tablesort_pager());

With this:
$output .= theme('pager', NULL, 20);

However, parent terms do not list nodes in child terms-- any way to change this behavior? I'm not sure...

This is an absolute noob question

Is there a way to re-arrange the columns??

i.e im using : flexinode_taxonomy_table.module and i want the terms(or vocab) column next to title. is there any way i can re-arrange the columns

thanks in advance for any help

Do they correspond to the weight that you give each field? I'm not sure... it's worth trying...

I think its the field id, and then the terms are added at the end in the present module. So i was thinking of a way to get the terms in between in the array (i've no clue how!!).

Actually, you are right, weights might be the way to go about it. If i have any success, will post back

We needed a custom tabular layout of flexinode data. This was the trickiest part of the entire project. Having tried several suggestions and solutions before finally arriving here, it was a happy moment when dman's code gave just the result needed.

We did modify the SQL just a bit to add a sort of filter for the results, and yes dman, the SQL is really scary!

Thanks for the code which we used with Drupal 4.7.6 without a hitch. Perhaps your code can be made easier to find since it could be very useful for others out there.

We customized the code from dman to allow for filtering by a taxonomy id as well by adding the category ID to the path. If anyone is interested in that version I can post it here.

Does or does not views.module now take care of all this for us nowadays?

As this is 4.7, flexinode, and built without reference to CCK or Views, should it be closed/dropped?
If not, is there anything it does that views doesn't (yet) just for a wishlist or HOWTO?
As I said before, I'm not that keen on revisiting it - it's now a year since I figured it out and it was all clever but horrid internal flexinode tricks.

I say post your update version for posterity, then close?

FTR, my implimentation went live but the client found the interface too busy (so we didn't repair that layout), and a less generic, simpler, revised version was used instead

I am not sure how to tackle this issue. But It needs to be tackle, for it's an important feature.
However, the solution in the patches is not the right route to take IMO. Simply adding rows for each thing we want to filter by is not the real solution.

Lets leave it open for now.