I want simply add another regression: side-by-side-translation seems not
to work anymore.
So maybe you're right.
Yes Geoff (and all),
a) I at first agree, that a feature/preference like "allow HTML" should
not be taken out, before a better or at least working alternative is
existing - people might - and do - depend on such features/preferences.
b) From such "behaviour" of the Tiki community, users might be inhibited
of upgrading or emberassed, when they do.
upgrade compatibility is a strength of Tiki and should stay one!
c) I hope, we will not fall back in quality, just about because we try
out things in the running branch instead of trunk branch or testing branch.
-> Even not being a coder, I contribute by using SVN-Branch and
SVN-Trunk even for small productive projects and I upgrade sites as
early as possible. -> downloadable FTP realeases MUST have a certain
standart, or we will loose market shares instead of gaining them.
-> Rising marketshares and satisfied users will give us better
opportunities of funding, for that our consultants, webdevelopers and
software developers will keep and extend the ability of at least get
some earnings out of our engagement ... a win-win situation for the
community and those of us trying to live fulltime from Tiki.
my 3 ct. for now.
Am 09.08.2012 13:23, schrieb geoff@...:
> Hi Marc
> Perhaps my use of the word 'trick' was not quite right since it seems to me
> that most of the tiki code is about using 'tricks' or rather smart ways to
> do some very smart things :-)
> To the specific point however: a while back we spent a great deal of time
> debating the pros and cons of allowing HTML in menu names and urls and we
> came down on the side of it would be ok in certain circumstances where the
> admin was in total control of all menu editing - and since this offers great
> flexibility we went to some lengths to provide a new pref that allowed this.
> Since then we've had a couple of compounding regressions that have stopped
> this functionality: the first was the generic pattern checking that was
> introduced - which we flushed out in beta testing - and decided we could
> work-around for the 9.0 release. But I have now just worked through this
> logic to amend the regex pattern for the case where the 'allow html' pref is
> set (see commit 42561)- so that is fixed.
> I've not yet got to the bottom the latest regression however where the whole
> of the url text is assumed to be the page name but I'm now hunting for this
> - if anyone can point me in the right direction ie what recent commit
> altered the behaviour of how menus are 'displayed' that would be helpful.
> But no one seems to have picked up the more significant point that I was
> trying to make - which is that we now seem to be making very significant
> changes direct into the 9.x branch without trying them out in trunk first
> where they can 'experience' more testing through all the various use cases
> that inevitably arise.
> My view is that we are potentially setting ourselves up for a poor quality
> 9.1 by doing this - so surely we should only be doing FIXes directly in 9.x
> and anything NEW should go through trunk and be backported when it is
> What do others think ?
> -----Original Message-----
> From: marc@... [mailto:marc@...] On Behalf Of Marc Laporte
> Sent: 03 August 2012 14:29
> To: geoff@...; Tiki developers
> Subject: Re: [Tiki-devel] 9.x branch regressions
> I think the real solution is too avoid these tricks.
> I suggest adding a new field for menu items which would be for mouse-over
> information, so the user can read more about this section before clicking on
> On Fri, Aug 3, 2012 at 7:36 AM, geoff@... <geoff@...>
>> Hi - I'm getting more than a bit concerned about the regressions that
>> are getting into the 9.x branch since this is supposed to be our LTS
>> The latest thing I've only just spotted (sorry been out of the loop a
>> weeks) is another issue with menus.
>> For a long time we were able to use a 'trick' to add html tags etc to
>> a menu URL so that for instance we can add a title tag by setting the
>> url as something like tiki-index.php?page=pagename" title="title-text
>> or if sefurl is used it could simply be pagename" title="title-text
>> For version 6 we got concerned about security so introduced a
>> preference that had to be set to allow HTML in menus but this got
>> broken in the initial version of 9 because of another security measure
>> that now does a regex filter on all input - but luci tracked down a
>> work around for this to delete the lines temporarily just to bypass it
>> to get the input into the system - and then reinstating the check.
>> This is a pain but at least we can keep working.
>> I now find in the current branch that it is broken again and I suspect
>> something a bit more fundamental has changed since the original logic
>> essentially used the whole of the url text as the href tag adding the
>> closing quotes so anything else added just behaves as additional tags.
>> What I see happening now is that it thinks the page is called the
>> whole of the url text ie pagename" title="title-text - so of course
>> it can't find it
>> Now hopefully, whoever has made these changes, can easily fix this -
>> but my main point is to ask whether it is right that we are doing such
>> significant changes direct into the branch presumably without testing
>> it in trunk first and importantly being aware and considering all the
>> likely use cases
>> Thoughts everyone
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions will include endpoint security, mobile security and the
>> latest in malware threats.
>> TikiWiki-devel mailing list
> Marc Laporte
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> TikiWiki-devel mailing list
fon: +49 178 8 272 383