On Tue, 16 May 2006, Phillip Karlsson wrote:
At the bottom, I list the two changes which would make this a really useful tool for me to use.
One low-tech hack I've just thought of:
Store the site a node belongs to as a prefix on the node name (have your own write code add it in before calling Wiki Toolkit / write a name munging pre_write filter).
When you read nodes out, munge the name again (again, in your code, or a post_retrieve plugin).
Finally, have the other retrieval stuff (recent changes, find by metadata etc) do some filtering. You could do some of it in your own code, but I'm sure we could add an optional parameter or two to help you out. We could also probably add a few more plugin points to help.
The internal links stuff would need a bit of jigger-pokery, but I'm getting quite close to ripping it out and starting again (or at the very least put it all in nice helper functions, rather than strewn randomly around the code), so some refactoring of that to support you would be welcomed :)
Thinking of your other suggestions: * Adding in a table prefix would be a large scale change to the codebase. It might prove a chance to abstract out quite a bit of the SQL, but it'll be a lot of work to implement, and even more to test. I'd avoid this option if you can. * Adding a new table for "associated wiki", linking nodes to that, and providing filtering Quite a bit less work, but possibly harder to test if you've caught all the possible places you need to change. Would want to be combined with a few more bits of rationalisation of the SQL, and certainly an overhaul of the internal_links code.
My thoughts are that the best for wiki toolkit would be the associated wiki table option, but probably the quickest and easiest for you would be the node name stuff.
Nick