No, I appreciate the reminder. You put a lot of work into that and I probably needed a reminder...
Cheers, Dan On Wed, Jan 6, 2010 at 2:50 AM, Markus <[email protected]> wrote: > Take your time! :) > > It wasn't meant to pressurize you in any way. Just wanted to make sure > that it has not get lost. > > Best wishes, > Markus > > On Jan 5, 11:39 pm, The Editor <[email protected]> wrote: >> I did get it Markus. I'm sorry--haven't had a chance to review it. >> I'll try to get it into the next release. Maybe tomorrow. Just having >> a hard time keeping up with everything at the moment. And there was a >> major security issue I needed to plug pronto--so that had first >> priority. >> >> Cheers, >> Dan >> >> >> >> On Tue, Jan 5, 2010 at 4:52 PM, Markus <[email protected]> wrote: >> > Dan, have you received that email with the ready-for-translation >> > system pages? I sent it to you on 12/11/09. Just wondering because the >> > system files in 3.3.3 are unchanged. >> >> > On Jan 5, 3:29 pm, The Editor <[email protected]> wrote: >> >> On Tue, Jan 5, 2010 at 6:40 AM, Erlend Sogge Heggen <[email protected]> >> >> wrote: >> >> >> >> Multipage copy/rename >> >> > I never tried this functionality but it sounds really powerful. I can >> >> > see how it has no place in the core, but I do hope it would stay >> >> > around. I remember I once wanted to do some major renaming in a >> >> > MediaWiki set up. Every page had to be done one-by-one, even when I >> >> > just wanted to change the hierarchy from /oldparent/pagename to / >> >> > newparent/pagename or /exemptparent/samepage/pagename to /samepage/ >> >> > pagename. >> >> >> Actually, as it is written in the core, it is somewhat limited. There >> >> is however an extremely powerful plugin I wrote called tree, kind of >> >> from the old dos days: rentree, deltree, etc. There's also a more >> >> powerful fileadmin plugin, which can do even more. They are both in >> >> the systems tools section of the solutions area. These are another >> >> reason to remove this capability out of the core. We have readily >> >> available plugins that are far superior. >> >> >> >> WikiWords (case sensitive page names) >> >> > I'm very glad you're not stuck up about WikiWords like some other >> >> > wikis are, but it is undeniably a useful feature just the same. I >> >> > think WikiWords is the sort of feature that could be made to 'light >> >> > up' a little in the plugins repository. I'm talking about the concept >> >> > that is being discussed with Wordpress right now, about 'Caonical >> >> > Plugins': >> >> >http://wordpress.org/development/2009/12/canonical-plugins/ >> >> > I for one really like the term 'Classic plugin'. >> >> >> WikiWord is actually quite a misnomer in BoltWire. Unlike the normal >> >> CamelCase approach to wikiwords, in BoltWire setting wikiwords to true >> >> simply gives you the option of saving case-sensitive pages names. >> >> Which essentially eradicates many of BoltWire's case insensitivity >> >> features. How it got connected with wikiwords is not clear in my >> >> recollection, but it goes back to the very early days of BoltWire >> >> 1.xx. We had an individual who strongly desired the ability to save >> >> case insensitive page names. At this point however, I believe we have >> >> a situation where BoltWire is better served by removing an option and >> >> being more consistent in our philosophy. Case insensitivity everywhere >> >> possible. >> >> >> Note there already is a wikiwords plugin, in the links section that >> >> explains this a bit more and gives one example of a simple wikiwords >> >> markup. If we thought camelcase links like SiteAuthView => >> >> [[site.auth.view|+]] would of value, it would be a simple plugin. I >> >> would be happy to code it one day. Just with our hierarchical system, >> >> wiki words don't make perfect sense. Or at least, there's multiple >> >> ways to set them them. >> >> >> >> Full toolset replacements >> >> > What does this entail exactly? >> >> >> This allows you to put a completely custom conditions.php, >> >> functions.php, commands.php script in your config folder and have >> >> these used instead of the core functions. My reason for deleting this >> >> is that we have several other ways of customizing these things, >> >> particularly: toolmapping, and site.auth.functions/commands pages. >> >> There's also the problem of system bugs caused by script dependencies >> >> that can get messed up. It would be nice if all these functions were >> >> completely independent, and maybe we can get to that point, but I >> >> don't think it is the case now. Particularly with the functions. >> >> >> Cheers, >> >> Dan >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "BoltWire" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/boltwire?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "BoltWire" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/boltwire?hl=en. > > > >
-- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
