Nabble - TikiWiki - Dev

Re: DIV wikiplugin's default "float:none"

2009-12-23T13:31:47Z

+1, it's really unnecessary

luci

On 12/23/2009 01:43 PM, Sylvie Greverend wrote:

> +1 Gary
> Commit 24013
> I will rollback if somebody find it not ok (regression?)
> sylvie
>
> On Wed, 2009-12-23 at 18:57 +0900, Gary Cunningham-Lee wrote:
>
>> Is the default "float:none" for the DIV wikiplugin
>> (lib/wiki-plugins/wikiplugin-div.php) really necessary? This property
>> appears by default if no other choice is made as a plugin argument. But
>> if you give a class to the div as an argument so it can get properties
>> from the stylesheet, that inline "float:none" causes trouble when the
>> float property is set in the stylesheet, forcing an "!important". Since
>> the default behavior of a div anyway is not to float, why add this to
>> the inline properties? I more or less chopped it out of the plugin file
>> to test, but don't really know the clean way to do this in the plugin
>> code, so could someone have a look at this and edit the file, please
>> (assuming I'm not missing some important reason for wikiplugin divs to
>> have "float:none" explicitly)?
>>
>> -- Gary
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Tikiwiki-devel mailing list
>> Tikiwiki-devel@...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> -------------------------------------------
> Modern Hosting PIPNI - http://www.pipni.cz/
>
>

Re: tiki-assignermissions.php

2009-12-23T10:53:33Z

Apart from the logical slight inconsistency, this is another good
reason why I am digging this:

>From the thread at
http://edu.tikiwiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=344

> I am also trying to advocate for fixing an inconsistency (for me)
> in how deferred inheritance of perms from 'Registered', when defining
> perms for a new group, cannot be avoided, although one defines the new
> group without 'including the perms of' Registered.
>
> That is very annoying, it was not so before.
> Because when you define permission for the RolePerms templates group,
> you want not to have any deferred inheritance (shaded perms that would
> be inherited at runtime, if Register still has them):
> if the new group does not 'include the perms of Registered', all the
> perms marked (shaded or not) must be written in the grouppermissions
> table for that group.
>
> This is important for RolePerms-xxx?, because these perms will be copied
> and transformed into objectpermissions granted to that role when any ws
> objects is created.
>
> I had to empty temporarily all perms of 'Registered' when defining the
> RolePerms-xxx? templates at edu.two, to get things right.
>
> That is also not very consistent for normal usage outside workspaces.
>
> See tikiwiki-devel thread 'tiki-assignpermissions.php'

Re: {img} - regression 4.0

2009-12-23T05:07:52Z

Just wondering if the separators param is the good implementation
2 other solutions
1/ as an url with , is not correct, the , can still separate url - the
user must encodes his urls. The | in the standard can be in an url
2/ accept in the plugin parsing something like src=ffff src=xxx and it
will returns a table

I think I will like 2/ - if people agrees I will do it
Thanks
sylvie

On Tue, 2009-12-22 at 21:05 -0500, lindon wrote:

> Okay, I'll make this change in a few days when I get back from out of
> town.
> lindon
>
> On Tue, Dec 22, 2009 at 12:07 PM, Paulo Sacramento <psacra@...>
> wrote:
> +1 for both, although people who are already relying on this
> (i.e. assuming that , and | are separators, instead of none)
> should make amends as a consequence.
>
> Paulo
>
>
>
> On Tue, Dec 22, 2009 at 5:56 PM, Sylvie Greverend
> <sgreverend@...> wrote:
> In tiki3 it was possible to have
> {img
> src="http://chart.apis.google.com/chart?cht=p3&chd=t:11,23|Available&chtt=Disk+Usage"}
> Notice the url has some , and |
> Now it is not possible because the src is split to
> display multiple images. Separators are , and |
>
> 1/ Do we agree to have a parameter in {img} that
> specifically gives the separators? I do not fill nice
> to be obliged to code , with %2C...
> Usually this url are painful and automatically
> generated
> 2/ for previous compatibility can separators be
> default to none?
>
> Thanks
> sylvie
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon
> Developer Community
> Take advantage of Verizon's best-in-class app
> development support
> A streamlined, 14 day to market process makes app
> distribution fast and easy
> Join now and get one step closer to millions of
> Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer
> Community
> Take advantage of Verizon's best-in-class app development
> support
> A streamlined, 14 day to market process makes app distribution
> fast and easy
> Join now and get one step closer to millions of Verizon
> customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________ Tikiwiki-devel mailing list Tikiwiki-devel@... https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

"Admin home" -> "Control Panel"?

2009-12-23T04:57:50Z

Why not renaming the "Admin home" (tiki-admin.php) with "Control Panel"
for Tiki 5.x onwards?
To avoid further confusion with new wiki users between the "Admin" menu
on the side column, and the main page where basic setup of features is
handled, like Control Panels in servers... (Currently named as "Admin home")
Just a quick thought...
Xavi

En/na tw.o - Community Home of the TikiWiki CMS/Groupware Project ha
escrit:

> The page Control Panel was changed by marclaporte at Sat 19 Dec. 2009 22:21 CET
>
> You can view the page by following this link:
>
> http://tikiwiki.org/tiki-index.php?page=Control%20Panel
>
> You can view a diff back to the previous version by following this link:
> http://tikiwiki.org/tiki-pagehistory.php?page=Control%20Panel&compare=1&oldver=53&newver=54
>
>
> ***********************************************************
> The changes in this version follow below, followed after by the current full page text.
> ***********************************************************
>
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> @@ -Lines: 2-8 changed to +Lines: 2-8 @@
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> ||Application|Tiki version included|Handles upgrades?|notes
> - ((Fantastico)) | 3.2 | yes |[https://www.simplescripts.com/script_details/script:TikiWikiCmsGroupware|Simple Scripts] (ex.:[http://bluehost.com|Bluehost]) | 3.2 | yes |[http://www.jumpbox.com/app/tikiwiki|JumpBox]| 3.2 | |
> + ((Fantastico)) | 3.3 | yes |[https://www.simplescripts.com/script_details/script:TikiWikiCmsGroupware|Simple Scripts] (ex.:[http://bluehost.com|Bluehost]) | 4.1 | yes |[http://www.jumpbox.com/app/tikiwiki|JumpBox]| 4. | |
> [http://www.click2try.com/catalog/Content-Management/TikiWiki/details|Click2try] | 3.0 | |
> [http://apsstandard.com/|apsstandard.com] for 1 and 1 | 3.2 | |[http://www.apsstandard.org/r/doc/aps-format-1.0-packaging-guide/index.htm|Application Packaging Developer's Guide]
>
>

...
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Dogfood Question

2009-12-23T04:49:34Z

Or even better, to host it at doc.tw.o as a different set of structures
categorized under a new top category and categ tree, etc. As I already
suggested to Rick months ago. In order to replace the "Tutorials" in
doc.tw.o (task oriented), which became kind-of-orphan of attention years ago

And in tiki 5.x, that "tikiwiki for smaties" content could use it's own
perspective/workspace, hopefully :-), so that it would be a real and
good use case for dogfooding perspectives & WYSIWTSN, btw! :-)

I don't like the current situation with many documentation pages
scattered among different sites... (I know some are handbook-style, and
others are howto-style, but anyhow, they document features and how to
use them). We are making it difficult to find things for end users with
a single "search box" to search everywhere where there is some
documentation. So while there is not single (& easy free software)
search box for all sites containing documentation, I would vote for a
roadmap to join in the same site doc.tw.o and tiki for smarties...

Something similar should be discussed on a later stage with the
documentation from profiles.tw.o, themes.tw.o, etc. Maybe iframing the
rellevant pages in those sites from the equivalent doc.tw.o pages would
do the job, while allowing the search to index the content of those
iframed pages? (I wonder if that's possible, or if this makes sense to
somebody else)

My 2 cents...

Xavi

En/na Rick Sapir ha escrit:

> "TikiWiki for Smarties" is published under a creative commons license. There
> would be no problem with copying it and "repacking" it to be published by
> doc.tw.o.
>
> -R
>
> ---
> Greetings from Sanford, NC, USA!
> ----- Original Message -----
> From: "Gary Cunningham-Lee" <gary_c@...>
> To: "Tikiwiki developers" <tikiwiki-devel@...>
> Sent: Monday, December 21, 2009 11:02 AM
> Subject: Re: [Tikiwiki-devel] Dogfood Question
>
>
>
>> That gets into the relationship between people's individual sites and
>> the Tikiwiki project sites. Tikiwiki for Smarties would be an
>> appropriate place for this kind of information for sure, but I think
>> that, in principle, it's good to also put information on one of the Tiki
>> project sites, to reduce the chance of it becoming unavailable at some
>> point in the future.
>>
>> -- Gary
>>
>> Desilets, Alain wrote:
>>
>>> I find Rick's Tiki for dummies is a really good place for that sort of
>>> task oriented documentation. Maybe that would be a good home for that?
>>>
>>> Alain
>>>
>>> -----Original Message-----
>>> From: Gary Cunningham-Lee [mailto:gary_c@...]
>>> Sent: Friday, December 18, 2009 11:00 PM
>>> To: Tikiwiki developers
>>> Subject: Re: [Tikiwiki-devel] Dogfood Question
>>>
>>> I've thought for a long time that we're really missing information about
>>> how to take the next steps after Tiki is installed and initially
>>> configured. One area that would be good to collect/share information
>>> about is how to get various layouts within a wiki page, how to place
>>> headings, images and text so it looks like a nice HTML page, how to make
>>> columns, how to use plugins (more details, with live examples and
>>> discussions, etc.). This would supplement doc.tw.o, which is, I think,
>>> best limited to reference and basic getting-started information.
>>>
>>> New people also ask things like when should I use a wiki page and when
>>> an article, things on that level.
>>>
>>> Well, I thought mods.tikiwiki.org would be good for this, if it could be
>>> a Tiki installation, in the sense of continuing from where the basics of
>>> doc.tw.o leave off. This kind of information overlaps some of what I've
>>> done at themes.tw.o (like
>>> http://themes.tikiwiki.org/Floated%20box%20demo) but would also get into
>>> use cases, and so there's also the connection with Profiles. Anyway, one
>>> way or the other, the more this kind of information can be provided, the
>>> more new people will see what Tiki is capable of, etc. And it'd be a
>>> good place for contribution from experienced users who aren't
>>> developers, since it's about using the software and not about the code.
>>>
>>> -- Gary
>>>
>>>
>>> Desilets, Alain wrote:
>>>
>>>> What a great idea Eric!
>>>>
>>>> Alain
>>>>
>>>> -----Original Message-----
>>>> From: Eric Kelner, P.E. [mailto:kelner@...]
>>>> Sent: Friday, December 18, 2009 12:02 PM
>>>> To: Gary Cunningham-Lee
>>>> Cc: Tikiwiki developers
>>>> Subject: Re: [Tikiwiki-devel] Dogfood Question
>>>>
>>>> Good comments. In general, I'm wondering if the developer community
>>>> dogfood experience is different than the "regular" users' and admins'
>>>> experiences. I suppose it is, since developers are far more familiar
>>>> with the code. Has there ever been a Tikifest focused on
>>>> applications, rather than development? I'd like to learn how others
>>>> are implementing the tool. I'd also like to learn some admin tricks.
>>>>
>>>> I'm probably missing a lot of good stuff. I recall seeing a brief
>>>> user's presentation at a Tikifest awhile back, but I'm thinking it
>>>> might be worth a one-day user's symposium or roundtable, maybe on the
>>>> front-end of a Tikifest. Participants could post discussion
>>>> questions/topics (on a wiki page, of course) ahead of time.
>>>> Users/Admins could give brief
>>>> (15 minute) overviews of their sites, followed by discussion for, say
>>>> 45
>>>>
>>>> minutes, providing a lot of discussion time. Being on the front end
>>>> of a Tikifest, it may also stimulate developer discussion. If the
>>>> concept were to catch on, I can envision possible on-line interactive
>>>> training sessions and Q/A for new users as well.
>>>>
>>>> Off the top of my head, here's a possible agenda. Ideally, each
>>>> application would be completely different in its approach.
>>>>
>>>> 8:00 - Opening and Introductions
>>>> 8:15-9:30 - Discussion/User Questions
>>>> 9:30-9:45 - Tiki Application #1 Presentation 9:45-10:30 - Discuss
>>>> Application #1
>>>> 10:30-10:45 - Break
>>>> 10:45-11:00 - Tiki Application #2 Presentation
>>>> 11:00-11:45 - Discuss Application #2
>>>> 11:45-1:00 - Lunch
>>>> 1:00-2:30 - Admin Tips, Tricks and Techniques
>>>> 2:30-2:45 - Tiki Application #3 Presentation 2:45-3:30 - Discuss
>>>> Application #3
>>>> 3:30-3:45 - Break
>>>> 3:45-4:00 - Tiki Application #4 Presentation
>>>> 4:00-4:45 - Discuss Application #4
>>>> 4:45-5:00 - Closing Remarks/Adjourn
>>>> 5:30 - Happy Hour (Can't forget this!)
>>>>
>>>> I know user groups aren't a new idea. This one came to my mind as
>>>> something that seems to be missing. We could call it "TUG." I'd be
>>>> happy to take the lead if there's interest. If it's already happening
>>>>
>>>> in one form or another, please let me know who the lead is. It also
>>>> wouldn't necessarily have to be done in coordination with a Tikifest -
>>>>
>>>> that just seems convenient.
>>>>
>>>> Eric Kelner, P.E.
>>>> Vice President
>>>> Letton-Hall Group
>>>> 210-372-0830 (Office)
>>>> 210-875-6277 (Cell)
>>>> www.letton-hall.com
>>>>
>>>>
>>>>
>>>> Gary Cunningham-Lee wrote:
>>>>
>>>>> I like the idea of doing the discussion within the wiki page itself,
>>>>> but often it isn't easy to see who said what and when they said it.
>>>>> (Probably people rely on the page history to keep track of
>>>>> contributions.) I suppose people work out some methods of formatting
>>>>> the page if this is important to see in-page (even something
>>>>> impromptu
>>>>> like how it was done at the doc.tw.o Editorial Board pages).
>>>>>
>>>>> Somebody asked in irc about if Tiki had in-page signatures like
>>>>> Mediawiki does. Apparently the author/editor can add a little syntax
>>>>> and then his/her name, the edit time, and some other info will be
>>>>> pasted in as text. It'd be good if Tiki had this also. And I was
>>>>> thinking it'd be interesting to think about taking this another step
>>>>> and maybe have something like a highlight background color on the
>>>>> person's contribution on mouseover, or meta information in a popup or
>>>>>
>>>>> something. Just hover around the page and see creation info
>>>>> colorfully. The downside would be no appearance of it when printed.
>>>>>
>>>>> -- Gary
>>>>>
>>>>> Desilets, Alain wrote:
>>>>>
>>>>>> Could have done it that way. Personally, I find comments are mostly
>>>>>>
>>>> good
>>>>
>>>>>> to allow users to rapidly post casual comments on a page.
>>>>>> Alain
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eric Kelner, P.E. [mailto:kelner@...] Sent:
>>>>>> Thursday, December 17, 2009 1:34 PM
>>>>>> To: Tikiwiki developers
>>>>>> Subject: [Tikiwiki-devel] Dogfood Question
>>>>>>
>>>>>> Hi All:
>>>>>>
>>>>>> I just read the Watch Icon discussion and have a question. Why
>>>>>> isn't
>>>>>> the comments feature being used? Everyone is just editing the wiki
>>>>>> page. It seems that the comment feature would be the best way to
>>>>>> capture the discussion, then you could rank ideas by scoring the
>>>>>> comments. Since it's a discussion by tiki developers, it's
>>>>>> interesting that it isn't used. Just an observation.
>>>>>>
>>>>>> BTW, how about using the "poll" feature to vote on User Watch
>>>>>> proposals?
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> Eric Kelner, P.E.
>>>>>> Vice President
>>>>>> Letton-Hall Group
>>>>>> 210-372-0830 (Office)
>>>>>> 210-875-6277 (Cell)
>>>>>>
>>>>>> www.letton-hall.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>>
>>>>>> ------
>>>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>>>> Take advantage of Verizon's best-in-class app development support A
>>>>>> streamlined, 14 day to market process makes app distribution fast
>>>>>>
>>>> and
>>>>
>>>>>> easy
>>>>>> Join now and get one step closer to millions of Verizon customers
>>>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>>>> _______________________________________________
>>>>>> Tikiwiki-devel mailing list
>>>>>> Tikiwiki-devel@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>> ------
>>>>
>>>>>> This SF.Net email is sponsored by the Verizon Developer Community
>>>>>> Take advantage of Verizon's best-in-class app development support A
>>>>>> streamlined, 14 day to market process makes app distribution fast
>>>>>> and easy Join now and get one step closer to millions of Verizon
>>>>>> customers http://p.sf.net/sfu/verizon-dev2dev
>>>>>> _______________________________________________
>>>>>> Tikiwiki-devel mailing list
>>>>>> Tikiwiki-devel@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>>>
>>>>>>
>>>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>>
>>>>>> No virus found in this incoming message.
>>>>>> Checked by AVG - www.avg.com Version: 9.0.716 / Virus Database:
>>>>>> 270.14.112/2571 - Release Date: 12/18/09 04:40:00
>>>>>>
>>>>>>
>>>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>> ------
>>>> This SF.Net email is sponsored by the Verizon Developer Community Take
>>>>
>>>> advantage of Verizon's best-in-class app development support A
>>>> streamlined, 14 day to market process makes app distribution fast and
>>>> easy Join now and get one step closer to millions of Verizon customers
>>>>
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> Tikiwiki-devel mailing list
>>>> Tikiwiki-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>> ----------------------------------------------------------------------
>>>> -------- This SF.Net email is sponsored by the Verizon Developer
>>>> Community Take advantage of Verizon's best-in-class app development
>>>> support A streamlined, 14 day to market process makes app distribution
>>>>
>>>> fast and easy Join now and get one step closer to millions of Verizon
>>>> customers http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> Tikiwiki-devel mailing list
>>>> Tikiwiki-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 9.0.717 / Virus Database: 270.14.114/2574 - Release Date:
>>>> 12/19/09 04:38:00
>>>>
>>>>
>>> ------------------------------------------------------------------------
>>> ------
>>> This SF.Net email is sponsored by the Verizon Developer Community Take
>>> advantage of Verizon's best-in-class app development support A
>>> streamlined, 14 day to market process makes app distribution fast and
>>> easy Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Tikiwiki-devel mailing list
>>> Tikiwiki-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and
>>> easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Tikiwiki-devel mailing list
>>> Tikiwiki-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 9.0.717 / Virus Database: 270.14.116/2578 - Release Date:
>>> 12/21/09 04:35:00
>>>
>>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Tikiwiki-devel mailing list
>> Tikiwiki-devel@...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>

Re: DIV wikiplugin's default "float:none"

2009-12-23T04:43:21Z

+1 Gary
Commit 24013
I will rollback if somebody find it not ok (regression?)
sylvie

On Wed, 2009-12-23 at 18:57 +0900, Gary Cunningham-Lee wrote:

> Is the default "float:none" for the DIV wikiplugin
> (lib/wiki-plugins/wikiplugin-div.php) really necessary? This property
> appears by default if no other choice is made as a plugin argument. But
> if you give a class to the div as an argument so it can get properties
> from the stylesheet, that inline "float:none" causes trouble when the
> float property is set in the stylesheet, forcing an "!important". Since
> the default behavior of a div anyway is not to float, why add this to
> the inline properties? I more or less chopped it out of the plugin file
> to test, but don't really know the clean way to do this in the plugin
> code, so could someone have a look at this and edit the file, please
> (assuming I'm not missing some important reason for wikiplugin divs to
> have "float:none" explicitly)?
>
> -- Gary
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Ajax save draft and auto save features

2009-12-23T04:22:01Z

Great Idea, Nelson! :-)
I was scared years ago when I tried it (as undocumented feature), and
since then, I always avoided that feature for production. With the
changes you propose, that would be perfect for improving autosave
feature in a more intuitive way (like in other apps., etc)
Thanks for taking care of this improvement.
My 2 cents.
Cheers
Xavi

En/na Nelson Ko ha escrit:

> Hi,
>
> I've been trying out the ajax auto-save feature and the save draft
> features in trunk, and...
>
> 1) 1st of all they don't work unless I add <input type="hidden"
> name="page" value="{$page}" /> to the form, because it needs to read
> that to work. I was going to commit that... Any objection? It
> duplicate the page=xxxxx in the query string, but I suppose hat's ok.
> It does not need to be escaped, right? (for a hidden form input var)
>
> 2) Secondly I don't understand the purpose of the "Save draft"
> feature. What is saved is a "personal" draft which is not viewable by
> anyone else except the person saving it, and the next time you edit
> the page it shows the draft contents and "Draft last edited xxxxxxx".
> This is really confusing if someone else has edited the page since...,
> even if it says "Warning: new versions of this page have been made
> after this draft". Is anyone using this feature? If yes, how to
> improve it...., if no, can it be removed?
>
> 3) As for the auto-save feature, it works but it auto-saves to a
> temporary file and is not a real auto-save. Well, I suppose this might
> work for edit lost protection, but again it is confusing because when
> I edit the page again, it says: If you want the saved version instead
> of this autosaved one Click Here. And if I view the page, it shows the
> non-autosaved one. The problem is that this is just very different
> from what other apps' auto-save does. But I can understand we may not
> want to make the wiki history full of auto-saves....
>
> Any suggestion?
>
> I am actually suggesting that the above 2 features be combined into
> one, called "auto-save" that behaves more like other apps and also
> saves it to the wiki page. This will provide lost edit protection and
> have some additional features as follows:
>
> This new auto-save will save to the wiki history. There are two modes
> that can be set by the admin.
>
> Mode 1: all edits are saved to wiki history (simple)
>
> Mode 2: only final edit is saved to wiki history. In the second mode,
> there will be something in the history that indicates that this is an
> auto-save. So when it auto-saves again, the wiki history will be
> checked to see if it is in fact the same person auto-saving again. If
> yes, then it will replace that history entry instead of adding one.
>
> Any comments?
>
> Nelson.
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>

DIV wikiplugin's default "float:none"

2009-12-23T01:57:49Z

Is the default "float:none" for the DIV wikiplugin
(lib/wiki-plugins/wikiplugin-div.php) really necessary? This property
appears by default if no other choice is made as a plugin argument. But
if you give a class to the div as an argument so it can get properties
from the stylesheet, that inline "float:none" causes trouble when the
float property is set in the stylesheet, forcing an "!important". Since
the default behavior of a div anyway is not to float, why add this to
the inline properties? I more or less chopped it out of the plugin file
to test, but don't really know the clean way to do this in the plugin
code, so could someone have a look at this and edit the file, please
(assuming I'm not missing some important reason for wikiplugin divs to
have "float:none" explicitly)?

-- Gary

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: tiki-assignermissions.php

2009-12-23T00:13:07Z

Jean-Marc Libs wrote:

> On Tue, Dec 22, 2009 at 7:19 PM, Giancarlo Pinerolo <giancapin@...> wrote:
>> Il martedì 22 dicembre 2009 14:15:41 Jean-Marc Libs ha scritto:
>>> I'm not sure I understand, so I have a question:
>>> Under your proposal, can I still try to set some permissions for
>>> Registered, look what it does, and then decide I don't want them and
>>> simply remove them ?
>>> Or would I have to hunt them down everywhere else to remove them ?
>> To have this, you must select a group, eg
>> 'include the permissions of group' Registered
>> when you define 'Editors'
>>
>> a) if fyou didn't select to include the perms of any group, Registered may
>> have tiki_p_blog_post, Editors may have tiki_p_blog_post, and when you remove
>> tiki_p_blog_post from Registered, Editors keep it.
>>
>> b) If you selected to 'include perms of: Registered', when you remove
>> tiki_p_blog_post from Registered, Editors loose it also.
>>
>> as it is now, i's always b), you cannot have a) by no means.
>
> So if we have 'include the permissions of group' Registered into 'Editors'.
>
> Currently, if I give tiki_p_blog_post to Registered, 'Editors'
> inherits it, but I am prevented to give it directly to Editors
> (because it already has it by inheritance).
>
> If I understand correctly, the change you suggest, is that I should
> still be allowed to give tiki_p_blog_post to Editors. This way, when I
> remove tiki_p_blog_post from Registered, Editors still has
> tiki_p_blog_post.

The actual problem is that even if you do NOT
'include the permissions of group' Registered into 'Editors'.
you are still prevented to give it directly to Editors.
Which I think is wrong.
In practice, the result is that Registered is always as included
At least in 3.3

>
> Did I understand correctly the change you suggest ?
>
> If so, I like it.
>
> Jyhem
>
>>> I don't like very much the idea that if I set a permission somewhere,
>>> other stuff happen in other places and if I unset it, I don't get back
>>> to the previous situation. But I'm not sure that is what you suggest.
>>>
>>> Jyhem
>>>
>>> On Tue, Dec 22, 2009 at 1:46 PM, Giancarlo Pinerolo <giancapin@...>
>> wrote:
>>>>> Hi,
>>>>>
>>>>> Is it a problem to let groups inherit permissions, and when making a new
>>>>> group, be aware of how permissions are being inherited?
>>>>> This avoids the
>>>>> need to set permissions separately. Then if a permission is removed from
>>>>> an inherited-from group, the second part of the removal action is to
>>>>> restore the permission for the group(s) that previously inherited it.
>>>> Avoiding to click on perms that would be inherited is an useful, faster
>>>> and logical suggestion aid.
>>>> If, when sublitting the form, these were also written in the
>>>> grouppermissions table, that would also avoid the second part: having to
>>>> restore them for all groups in case of removal from the inherited-from
>>>> Registered and Anonymous.
>>>>
>>>> Giancarlo
>>>>
>>>> -------------------------------------------------------------------------
>>>> ----- This SF.Net email is sponsored by the Verizon Developer Community
>>>> Take advantage of Verizon's best-in-class app development support A
>>>> streamlined, 14 day to market process makes app distribution fast and
>>>> easy Join now and get one step closer to millions of Verizon customers
>>>> http://p.sf.net/sfu/verizon-dev2dev
>>>> _______________________________________________
>>>> Tikiwiki-devel mailing list
>>>> Tikiwiki-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>

Formation of Tikiwiki Users Group (TUG)

2009-12-22T21:00:47Z

I thought I'd change the thread name to be more descriptive. There were
enough positive comments about forming a user group that I've taken the
liberty of naming our new group Tikiwiki Users Group (TUG). Even if we
only have 5 or 6 members initially, it would still be of value IMO.
So, what I'm hearing is the following:

1. An event, like a TUG webinar/in-person meeting, held in conjunction
with a Tikifest would be of value. It would be focused on users, with
application examples and discussion. Developers would be welcome to
join in.
2. We have at least two Tikis that could be used as repositories for
information.

As I said in a prior post, I'm happy to organize the group and the first
TUG meeting sometime during or immediately after Tikifest NY (I won't be
available before the 15th). I am happy to offer our AdobeConnect
resource for the webinar (only 14 slots available with our current
subscription). I may be able to get up there in person, but not sure at
this point. Suggested agenda is listed below. I'm happy to take one
slot to show one of my Tikis. We'll need volunteers for the other three
slots. We'll also need users to submit some questions for the early
discussion and we'll need help with Admin Tips, Tricks and Techniques.
Suggestions for improving the agenda are welcome.

8:00 - Opening and Introductions
8:15-9:30 - Discussion/User Questions
9:30-9:45 - Tiki Application #1 Presentation
9:45-10:30 - Discuss Application #1
10:30-10:45 - Break
10:45-11:00 - Tiki Application #2 Presentation
11:00-11:45 - Discuss Application #2
11:45-1:00 - Lunch
1:00-2:30 - Admin Tips, Tricks and Techniques
2:30-2:45 - Tiki Application #3 Presentation
2:45-3:30 - Discuss Application #3
3:30-3:45 - Break
3:45-4:00 - Tiki Application #4 Presentation
4:00-4:45 - Discuss Application #4
4:45-5:00 - Closing Remarks/Adjourn
5:30 - Happy Hour (Can't forget this!)

This will only work if we can get a few users involved and willing to
commit some time. So please let me know if you're willing to
participate in TUG. Rather than clogging up the Dev mail list, please
send me an email directly (kelner@...). Assuming I get at
least a few on board, the first order of business should be to divide
work, plan for the meeting and discuss how to best use the on-line
resources (like "Smarties") and others that are already available.

Please let me know your interest as soon as possible.

Thanks.

--
Eric Kelner, P.E.
Vice President
Letton-Hall Group
210-372-0830 (Office)
210-875-6277 (Cell)
www.letton-hall.com

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: {img} - regression 4.0

2009-12-22T18:05:14Z

Okay, I'll make this change in a few days when I get back from out of town.
lindon

On Tue, Dec 22, 2009 at 12:07 PM, Paulo Sacramento <psacra@...> wrote:

+1 for both, although people who are already relying on this (i.e. assuming that , and | are separators, instead of none) should make amends as a consequence.

Paulo

On Tue, Dec 22, 2009 at 5:56 PM, Sylvie Greverend <sgreverend@...> wrote:

In tiki3 it was possible to have
{img src="http://chart.apis.google.com/chart?cht=p3&chd=t:11,23|Available&chtt=Disk+Usage"}
Notice the url has some , and |
Now it is not possible because the src is split to display multiple images. Separators are , and |

1/ Do we agree to have a parameter in {img} that specifically gives the separators? I do not fill nice to be obliged to code , with %2C...
Usually this url are painful and automatically generated
2/ for previous compatibility can separators be default to none?

Thanks
sylvie

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

blank page after save

2009-12-22T15:36:00Z

All,

I discovered another problem after upgrading to 4.1.
When I edit any page and hit the "Save bottom" it I get basically a
blank page.
After hitting "Refresh" I end up at the Homepage again.

Any idea what I can do about this?

Thank you,
-- Bernd

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: tiki-assignermissions.php

2009-12-22T14:02:50Z

On Tue, Dec 22, 2009 at 7:19 PM, Giancarlo Pinerolo <giancapin@...> wrote:

> Il martedì 22 dicembre 2009 14:15:41 Jean-Marc Libs ha scritto:
>> I'm not sure I understand, so I have a question:
>> Under your proposal, can I still try to set some permissions for
>> Registered, look what it does, and then decide I don't want them and
>> simply remove them ?
>
>> Or would I have to hunt them down everywhere else to remove them ?
>
> To have this, you must select a group, eg
> 'include the permissions of group' Registered
> when you define 'Editors'
>
> a) if fyou didn't select to include the perms of any group, Registered may
> have tiki_p_blog_post, Editors may have tiki_p_blog_post, and when you remove
> tiki_p_blog_post from Registered, Editors keep it.
>
> b) If you selected to 'include perms of: Registered', when you remove
> tiki_p_blog_post from Registered, Editors loose it also.
>
> as it is now, i's always b), you cannot have a) by no means.

So if we have 'include the permissions of group' Registered into 'Editors'.

Currently, if I give tiki_p_blog_post to Registered, 'Editors'
inherits it, but I am prevented to give it directly to Editors
(because it already has it by inheritance).

If I understand correctly, the change you suggest, is that I should
still be allowed to give tiki_p_blog_post to Editors. This way, when I
remove tiki_p_blog_post from Registered, Editors still has
tiki_p_blog_post.

Did I understand correctly the change you suggest ?

If so, I like it.

Jyhem

>> I don't like very much the idea that if I set a permission somewhere,
>> other stuff happen in other places and if I unset it, I don't get back
>> to the previous situation. But I'm not sure that is what you suggest.
>>
>> Jyhem
>>
>> On Tue, Dec 22, 2009 at 1:46 PM, Giancarlo Pinerolo <giancapin@...>
> wrote:
>> >> Hi,
>> >>
>> >> Is it a problem to let groups inherit permissions, and when making a new
>> >> group, be aware of how permissions are being inherited?
>> >> This avoids the
>> >> need to set permissions separately. Then if a permission is removed from
>> >> an inherited-from group, the second part of the removal action is to
>> >> restore the permission for the group(s) that previously inherited it.
>> >
>> > Avoiding to click on perms that would be inherited is an useful, faster
>> > and logical suggestion aid.
>> > If, when sublitting the form, these were also written in the
>> > grouppermissions table, that would also avoid the second part: having to
>> > restore them for all groups in case of removal from the inherited-from
>> > Registered and Anonymous.
>> >
>> > Giancarlo
>> >
>> > -------------------------------------------------------------------------
>> >----- This SF.Net email is sponsored by the Verizon Developer Community
>> > Take advantage of Verizon's best-in-class app development support A
>> > streamlined, 14 day to market process makes app distribution fast and
>> > easy Join now and get one step closer to millions of Verizon customers
>> > http://p.sf.net/sfu/verizon-dev2dev
>> > _______________________________________________
>> > Tikiwiki-devel mailing list
>> > Tikiwiki-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
>

dev.tikiwiki.org is down

2009-12-22T11:21:14Z

And has been for 10 mins now.

Re: sendStructureEmailNotifications in notificationemaillib.php

2009-12-22T09:33:51Z

Il martedì 22 dicembre 2009 12:56:38 Sylvie Greverend ha scritto:
> The line above
> global $structlib; include_once('lib/structures/structlib.php');
> should do the trick.
> If not it means there is an include strucltlip.php without a global
> structlib somewhere . To find out put a debug_print_backtrace in
> structlib.php
> Good luck

What I say is that this error is withing structlib.php itself, in function
s_create_page()

...
if ($prefs['feature_user_watches'] == 'y') {
include_once('lib/notifications/notificationemaillib.php');
sendStructureEmailNotification(array(.....
}
....

then notificaionemaillib.php (which does not create a class, is only a set of
functions) does:

function sendStructureEmailNotification($params) {
global $tikilib, $smarty, $prefs;
global $structlib; include_once('lib/structures/structlib.php');
if ($params['action'] == 'move_up' || $params['action']
== 'move_down') {
$nots = $structlib->get_watches('', $params['parent_id'],
^^^^^^^^^^^
false);
} else {
....

>
> On Tue, 2009-12-22 at 13:45 +0000, Giancarlo Pinerolo wrote:
> > Is seems that function
> > sendStructureEmailNotifications() in notificationemaillib.php
> > (which is not a class but a series of functions), both in svn trunk and
> > 3.3, gets only included/called from
> >
> > lib/structures/structlib.php
> >
> > Thus, notificationemaillib.php not having a class, it becomes a series of
> > function inside structlib.
> > But then the sendStructureEmailNotifications() function uses:
> >
> > $structlib->get_watches
> > instead of :
> > $this->get_watches
> >
> > thus creating an
> >
> > Fatal error: Call to a member function get_watches() on a non-object
> > in /var/www/edu.tikiwiki.org/lib/notifications/notificationemaillib.php
> > on line 488
> >
> > Giancarlo
> >
> >
> > -------------------------------------------------------------------------
> >----- This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support A
> > streamlined, 14 day to market process makes app distribution fast and
> > easy Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Tikiwiki-devel mailing list
> > Tikiwiki-devel@...
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: tiki-assignermissions.php

2009-12-22T09:18:44Z

Il martedì 22 dicembre 2009 14:15:41 Jean-Marc Libs ha scritto:
> I'm not sure I understand, so I have a question:
> Under your proposal, can I still try to set some permissions for
> Registered, look what it does, and then decide I don't want them and
> simply remove them ?

> Or would I have to hunt them down everywhere else to remove them ?

To have this, you must select a group, eg
'include the permissions of group' Registered
when you define 'Editors'

a) if fyou didn't select to include the perms of any group, Registered may
have tiki_p_blog_post, Editors may have tiki_p_blog_post, and when you remove
tiki_p_blog_post from Registered, Editors keep it.

b) If you selected to 'include perms of: Registered', when you remove
tiki_p_blog_post from Registered, Editors loose it also.

as it is now, i's always b), you cannot have a) by no means.

>
> I don't like very much the idea that if I set a permission somewhere,
> other stuff happen in other places and if I unset it, I don't get back
> to the previous situation. But I'm not sure that is what you suggest.
>
> Jyhem
>
> On Tue, Dec 22, 2009 at 1:46 PM, Giancarlo Pinerolo <giancapin@...>
wrote:

> >> Hi,
> >>
> >> Is it a problem to let groups inherit permissions, and when making a new
> >> group, be aware of how permissions are being inherited?
> >> This avoids the
> >> need to set permissions separately. Then if a permission is removed from
> >> an inherited-from group, the second part of the removal action is to
> >> restore the permission for the group(s) that previously inherited it.
> >
> > Avoiding to click on perms that would be inherited is an useful, faster
> > and logical suggestion aid.
> > If, when sublitting the form, these were also written in the
> > grouppermissions table, that would also avoid the second part: having to
> > restore them for all groups in case of removal from the inherited-from
> > Registered and Anonymous.
> >
> > Giancarlo
> >
> > -------------------------------------------------------------------------
> >----- This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support A
> > streamlined, 14 day to market process makes app distribution fast and
> > easy Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Tikiwiki-devel mailing list
> > Tikiwiki-devel@...
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: {img} - regression 4.0

2009-12-22T09:07:08Z

+1 for both, although people who are already relying on this (i.e. assuming that , and | are separators, instead of none) should make amends as a consequence.

Paulo

On Tue, Dec 22, 2009 at 5:56 PM, Sylvie Greverend <sgreverend@...> wrote:

In tiki3 it was possible to have
{img src="http://chart.apis.google.com/chart?cht=p3&chd=t:11,23|Available&chtt=Disk+Usage"}
Notice the url has some , and |
Now it is not possible because the src is split to display multiple images. Separators are , and |

1/ Do we agree to have a parameter in {img} that specifically gives the separators? I do not fill nice to be obliged to code , with %2C...
Usually this url are painful and automatically generated
2/ for previous compatibility can separators be default to none?

Thanks
sylvie

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

{img} - regression 4.0

2009-12-22T08:56:32Z

In tiki3 it was possible to have
{img src="http://chart.apis.google.com/chart?cht=p3&chd=t:11,23|Available&chtt=Disk+Usage"}
Notice the url has some , and |
Now it is not possible because the src is split to display multiple images. Separators are , and |

1/ Do we agree to have a parameter in {img} that specifically gives the separators? I do not fill nice to be obliged to code , with %2C...
Usually this url are painful and automatically generated
2/ for previous compatibility can separators be default to none?

Thanks
sylvie

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: tiki-assignermissions.php

2009-12-22T06:15:41Z

I'm not sure I understand, so I have a question:
Under your proposal, can I still try to set some permissions for
Registered, look what it does, and then decide I don't want them and
simply remove them ?
Or would I have to hunt them down everywhere else to remove them ?

I don't like very much the idea that if I set a permission somewhere,
other stuff happen in other places and if I unset it, I don't get back
to the previous situation. But I'm not sure that is what you suggest.

Jyhem

On Tue, Dec 22, 2009 at 1:46 PM, Giancarlo Pinerolo <giancapin@...> wrote:

>> Hi,
>>
>> Is it a problem to let groups inherit permissions, and when making a new
>> group, be aware of how permissions are being inherited?
>> This avoids the
>> need to set permissions separately. Then if a permission is removed from
>> an inherited-from group, the second part of the removal action is to
>> restore the permission for the group(s) that previously inherited it.
>
> Avoiding to click on perms that would be inherited is an useful, faster and
> logical suggestion aid.
> If, when sublitting the form, these were also written in the grouppermissions
> table, that would also avoid the second part: having to restore them for all
> groups in case of removal from the inherited-from Registered and Anonymous.
>
> Giancarlo
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

Re: sendStructureEmailNotifications in notificationemaillib.php

2009-12-22T04:56:38Z

The line above
global $structlib; include_once('lib/structures/structlib.php');
should do the trick.
If not it means there is an include strucltlip.php without a global
structlib somewhere . To find out put a debug_print_backtrace in
structlib.php
Good luck

On Tue, 2009-12-22 at 13:45 +0000, Giancarlo Pinerolo wrote:

> Is seems that function
> sendStructureEmailNotifications() in notificationemaillib.php
> (which is not a class but a series of functions), both in svn trunk and 3.3,
> gets only included/called from
>
> lib/structures/structlib.php
>
> Thus, notificationemaillib.php not having a class, it becomes a series of
> function inside structlib.
> But then the sendStructureEmailNotifications() function uses:
>
> $structlib->get_watches
> instead of :
> $this->get_watches
>
> thus creating an
>
> Fatal error: Call to a member function get_watches() on a non-object
> in /var/www/edu.tikiwiki.org/lib/notifications/notificationemaillib.php on
> line 488
>
> Giancarlo
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

sendStructureEmailNotifications in notificationemaillib.php

2009-12-22T04:45:31Z

Is seems that function
sendStructureEmailNotifications() in notificationemaillib.php
(which is not a class but a series of functions), both in svn trunk and 3.3,
gets only included/called from

lib/structures/structlib.php

Thus, notificationemaillib.php not having a class, it becomes a series of
function inside structlib.
But then the sendStructureEmailNotifications() function uses:

$structlib->get_watches
instead of :
$this->get_watches

thus creating an

Fatal error: Call to a member function get_watches() on a non-object
in /var/www/edu.tikiwiki.org/lib/notifications/notificationemaillib.php on
line 488

Giancarlo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: tiki-assignermissions.php

2009-12-22T03:45:45Z

> Hi,
>
> Is it a problem to let groups inherit permissions, and when making a new
> group, be aware of how permissions are being inherited?
> This avoids the
> need to set permissions separately. Then if a permission is removed from
> an inherited-from group, the second part of the removal action is to
> restore the permission for the group(s) that previously inherited it.

Avoiding to click on perms that would be inherited is an useful, faster and
logical suggestion aid.
If, when sublitting the form, these were also written in the grouppermissions
table, that would also avoid the second part: having to restore them for all
groups in case of removal from the inherited-from Registered and Anonymous.

Giancarlo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Jonny Bradley nominated to the Tiki Admin Team

2009-12-21T18:32:24Z

Way to go Jonny!!!!

2009/12/21 Sébastien Lord-Jetté <slordjette@...>

Congrats to Jonny!

—S.

Sébastien Lord-Jetté

http://TikiWiki.org/slordjette
http://TikiWiki.org/CGCOM
http://Twitter.com/slordjette
http://Twitter.com/TikiWiki_org

On 19-Dec-09, at 8:02 PM, Marc Laporte wrote:

> http://info.tikiwiki.org/article82
>
> --
> Marc Laporte
>
> http://MarcLaporte.com
> http://TikiWiki.org/MarcLaporte
> http://AvanTech.net
> http://OurWiki.net
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast
> and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: user account disabled

2009-12-21T16:13:00Z

Thanks Sylvie,

That did work. You're the cat's pyjama.

-- Bernd

On 12/21/2009 6:21 PM, Sylvie Greverend wrote:

> Try
> http://tikiwiki.org/ReleaseNotes40
> known issues
> Seems there is a case/cases ? I missed
> The security fix about clear password was hard to fix - a little bumpy
> - sorry about that - tell me if the query does not work ... - there
> are about 15 scenario to register / renew login in tw...
> The way it works in tw4 now is
> In the users_users table
> - if the column waiting has some value .. means the account is disabled
> - can be admin validation, user validation... the log-in is blocked
> - valid should contains the last tricky code the user received to
> validate his account
> - hash should contains the password encoded value.
> Thanks for your feedback
> sylvie
>
>

Re: user account disabled

2009-12-21T15:21:47Z

Try
http://tikiwiki.org/ReleaseNotes40
known issues
Seems there is a case/cases ? I missed
The security fix about clear password was hard to fix - a little bumpy
- sorry about that - tell me if the query does not work ... - there
are about 15 scenario to register / renew login in tw...
The way it works in tw4 now is
In the users_users table
- if the column waiting has some value .. means the account is disabled
- can be admin validation, user validation... the log-in is blocked
- valid should contains the last tricky code the user received to
validate his account
- hash should contains the password encoded value.
Thanks for your feedback
sylvie

On Mon, 2009-12-21 at 17:26 -0500, Bernd Prager wrote:

> Hi,
>
> After upgrading to TikiWiki 4.1 today I got "account disabled" on my
> normal user account when I try to log in.
> I can still log in as admin and switch to this particular user.
>
> Any idea on how re-enable this account maybe in the database?
> There is apparently no disabled flag in the table users_users. Where
> else can I look?
>
> Thanks for any help,
> -- Bernd
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T15:03:04Z

what about a tiki-ask_language .tpl for whatever you need to fill -
language is used in articles too.
so the tpl will do
- if not multilingual out
- if I have to ask <select..
- if it is predefined <.. input hidden...

On Mon, 2009-12-21 at 17:32 -0500, Desilets, Alain wrote:

> I guess I could always do it as follows:
>
> -- tiki-editpage.tpl:
> {if $need_lang == 'y'}
> {include file=tiki-editpage-ask_language.tpl}
> {else}
> {include file=tiki-editpage-edit.tpl}
> {/if}
> ---
>
> Then in tiki-editpage-edit.tpl, I would put the 515 lines that are
> currently in tiki-editpage.tpl , and in tiki-editpage-ask_language.tpl,
> I would put the new dialog which asks the user for the new page's
> language.
>
> Is that a "kosher" way to do it?
>
> Thx
>
> Alain
>
> -----Original Message-----
> From: Desilets, Alain [mailto:Alain.Desilets@...]
> Sent: Monday, December 21, 2009 4:17 PM
> To: sgreverend@...; Tikiwiki developers
> Subject: Re: [Tikiwiki-devel] Adding a new .tpl file
>
> Thx Sylvie.
>
> > You need in tiki-editpage.tpl to
> > {include file=your_file.tpl}
> > display() is reserved for all the page
>
> I would prefer not to do it this way, because I think it will make
> tiki-editpage.tpl even harder to read than it already is (and it's
> pretty hard to read as it is).
>
> If I was to do this the way you suggest, I would have to have an {if}
> statement at the beginning of tiki-editpage.tpl that would looke like
> this:
>
> ---
> {if $nedd_lang == 'y'}
> Put a short dialog here asking the user to choose the language.
> {else}
> Put the bulk of the 515 lines of code in tiki-editpage.tpl here
> {if}
> ---
>
> The problem I see with this is that having an {else} clause that is 515
> lines long makes the .tpl hard to read. It's VERY difficult to know
> where the clause starts and ends when it's that long.
>
> So, I would prefer to modularize things a bit more, and have the PHP
> file (tiki-editpage.php) display an altogether separate .tpl file, for
> the case where it needs to ask the user to choose a language.
>
> Is there way to do this in Tiki? If not, would be possible for
> tiki-editpage.php to forward the request to a new PHP script
> tiki-choose_page_language.php, which would display
> tiki-choose_page_language.tpl.
>
> Thx.
>
> Alain
>
> ------------------------------------------------------------------------
> ------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Ajax save draft and auto save features

2009-12-21T14:41:48Z

Hi,

I've been trying out the ajax auto-save feature and the save draft
features in trunk, and...

1) 1st of all they don't work unless I add <input type="hidden"
name="page" value="{$page}" /> to the form, because it needs to read
that to work. I was going to commit that... Any objection? It
duplicate the page=xxxxx in the query string, but I suppose hat's ok.
It does not need to be escaped, right? (for a hidden form input var)

2) Secondly I don't understand the purpose of the "Save draft"
feature. What is saved is a "personal" draft which is not viewable by
anyone else except the person saving it, and the next time you edit
the page it shows the draft contents and "Draft last edited xxxxxxx".
This is really confusing if someone else has edited the page since...,
even if it says "Warning: new versions of this page have been made
after this draft". Is anyone using this feature? If yes, how to
improve it...., if no, can it be removed?

3) As for the auto-save feature, it works but it auto-saves to a
temporary file and is not a real auto-save. Well, I suppose this might
work for edit lost protection, but again it is confusing because when
I edit the page again, it says: If you want the saved version instead
of this autosaved one Click Here. And if I view the page, it shows the
non-autosaved one. The problem is that this is just very different
from what other apps' auto-save does. But I can understand we may not
want to make the wiki history full of auto-saves....

Any suggestion?

I am actually suggesting that the above 2 features be combined into
one, called "auto-save" that behaves more like other apps and also
saves it to the wiki page. This will provide lost edit protection and
have some additional features as follows:

This new auto-save will save to the wiki history. There are two modes
that can be set by the admin.

Mode 1: all edits are saved to wiki history (simple)

Mode 2: only final edit is saved to wiki history. In the second mode,
there will be something in the history that indicates that this is an
auto-save. So when it auto-saves again, the wiki history will be
checked to see if it is in fact the same person auto-saving again. If
yes, then it will replace that history entry instead of adding one.

Any comments?

Nelson.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T14:32:39Z

I guess I could always do it as follows:

-- tiki-editpage.tpl:
{if $need_lang == 'y'}
{include file=tiki-editpage-ask_language.tpl}
{else}
{include file=tiki-editpage-edit.tpl}
{/if}
---

Then in tiki-editpage-edit.tpl, I would put the 515 lines that are
currently in tiki-editpage.tpl , and in tiki-editpage-ask_language.tpl,
I would put the new dialog which asks the user for the new page's
language.

Is that a "kosher" way to do it?

Thx

Alain

-----Original Message-----
From: Desilets, Alain [mailto:Alain.Desilets@...]
Sent: Monday, December 21, 2009 4:17 PM
To: sgreverend@...; Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Adding a new .tpl file

Thx Sylvie.

> You need in tiki-editpage.tpl to
> {include file=your_file.tpl}
> display() is reserved for all the page

I would prefer not to do it this way, because I think it will make
tiki-editpage.tpl even harder to read than it already is (and it's
pretty hard to read as it is).

If I was to do this the way you suggest, I would have to have an {if}
statement at the beginning of tiki-editpage.tpl that would looke like
this:

---
{if $nedd_lang == 'y'}
Put a short dialog here asking the user to choose the language.
{else}
Put the bulk of the 515 lines of code in tiki-editpage.tpl here
{if}
---

The problem I see with this is that having an {else} clause that is 515
lines long makes the .tpl hard to read. It's VERY difficult to know
where the clause starts and ends when it's that long.

So, I would prefer to modularize things a bit more, and have the PHP
file (tiki-editpage.php) display an altogether separate .tpl file, for
the case where it needs to ask the user to choose a language.

Is there way to do this in Tiki? If not, would be possible for
tiki-editpage.php to forward the request to a new PHP script
tiki-choose_page_language.php, which would display
tiki-choose_page_language.tpl.

Thx.

Alain

------------------------------------------------------------------------
------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and
easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

user account disabled

2009-12-21T14:26:47Z

Hi,

After upgrading to TikiWiki 4.1 today I got "account disabled" on my
normal user account when I try to log in.
I can still log in as admin and switch to this particular user.

Any idea on how re-enable this account maybe in the database?
There is apparently no disabled flag in the table users_users. Where
else can I look?

Thanks for any help,
-- Bernd

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T13:16:36Z

Thx Sylvie.

> You need in tiki-editpage.tpl to
> {include file=your_file.tpl}
> display() is reserved for all the page

I would prefer not to do it this way, because I think it will make
tiki-editpage.tpl even harder to read than it already is (and it's
pretty hard to read as it is).

If I was to do this the way you suggest, I would have to have an {if}
statement at the beginning of tiki-editpage.tpl that would looke like
this:

---
{if $nedd_lang == 'y'}
Put a short dialog here asking the user to choose the language.
{else}
Put the bulk of the 515 lines of code in tiki-editpage.tpl here
{if}
---

The problem I see with this is that having an {else} clause that is 515
lines long makes the .tpl hard to read. It's VERY difficult to know
where the clause starts and ends when it's that long.

So, I would prefer to modularize things a bit more, and have the PHP
file (tiki-editpage.php) display an altogether separate .tpl file, for
the case where it needs to ask the user to choose a language.

Is there way to do this in Tiki? If not, would be possible for
tiki-editpage.php to forward the request to a new PHP script
tiki-choose_page_language.php, which would display
tiki-choose_page_language.tpl.

Thx.

Alain

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T13:05:34Z

You need in tiki-editpage.tpl to
{include file=your_file.tpl}
display() is reserved for all the page
On Mon, 2009-12-21 at 15:55 -0500, Desilets, Alain wrote:

> Actually, it works, sort of. The new .tpl file IS being displayed, but none of the Tiki layout appears. In other words, I only see a blank page with the stuff that I added in tiki-choose_page_language.tpl.
>
> How can I display that .tpl, but inside the normal Tiki container? If some can guide me, I promise to add a Code Howto about this here:
>
> http://dev.tikiwiki.org/Code+Maps+and+Howtos
>
> -----Original Message-----
> From: Desilets, Alain
> Sent: Monday, December 21, 2009 3:51 PM
> To: Desilets, Alain; 'Tikiwiki developers'
> Subject: RE: [Tikiwiki-devel] Adding a new .tpl file
>
> Hum... it started working all of a sudden. Maybe a cache issue.
>
> Alain
>
> -----Original Message-----
> From: Desilets, Alain
> Sent: Monday, December 21, 2009 3:31 PM
> To: 'Tikiwiki developers'
> Subject: RE: [Tikiwiki-devel] Adding a new .tpl file
>
> Oh, btw J-M. Do you see what I am doing wrong in terms of adding the new .tpl file?
>
> Alain
>
> -----Original Message-----
> From: Jean-Marc Libs [mailto:jeanmarc.libs@...]
> Sent: Monday, December 21, 2009 3:22 PM
> To: Tikiwiki developers
> Subject: Re: [Tikiwiki-devel] Adding a new .tpl file
>
> It sounds dangerous to me. Pages labelled in the default language by
> mistake would be near impossible to find and correct afterwards.
> Unlabelled pages, on the opposite, can be listed and corrected.
>
> Jyhem
>
> On Mon, Dec 21, 2009 at 9:09 PM, Rick Sapir <rick.sapir@...> wrote:
> > Instead of prompting the user to select a language, should it instead
> > default to the site language?
> >
> > -R
> >
> >
> > ---
> > Greetings from Sanford, NC, USA!
> > ----- Original Message -----
> > From: "Desilets, Alain" <Alain.Desilets@...>
> > To: "Tikiwiki developers" <tikiwiki-devel@...>
> > Sent: Monday, December 21, 2009 2:50 PM
> > Subject: [Tikiwiki-devel] Adding a new .tpl file
> >
> >
> >> Hi folks,
> >>
> >> I am modifying tiki-editpage.php so that if user asked to create a new
> >> page, but its language has not been defined, then the system will prompt
> >> him to choose a language.
> >>
> >> Rather than add yet more code to tiki-editpage.tpl, I want to modularize
> >> that in a separate tpl called tiki-choose_page_language.tpl. To that
> >> effect, I put the following code in tiki-editpage.tpl
> >>
> >> if
> >> ($editlib->user_needs_to_specify_language_of_page_to_be_created($page,
> >> $info)) {
> >> echo "<pre>-- tiki-editpage.php: Language needs to be defined.
> >> Asking the user to do select it.</pre>\n";
> >> $smarty->assign('need_lang', 1);
> >> $smarty->display('tiki-choose_page_language.tpl');
> >> // $smarty->display('error.tpl');
> >> }
> >>
> >> The file tiki-choose_page_language.tpl exists, and is in the templates
> >> directory (and it contains nothing but a stub message). Yet, when I run
> >> this, I see the trace:
> >>
> >> -- tiki-editpage.php: Language needs to be defined. Asking the user
> >> to do select it.
> >>
> >> But tiki still insists on displaying the edit page dialog. What
> >>
> >> Strangely enough, if I comment out the line for displaying error.tpl
> >> instead, it works. Tiki then displays the error screen.
> >>
> >> What am I doing wrong?
> >>
> >> Thx.
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Verizon Developer Community
> >> Take advantage of Verizon's best-in-class app development support
> >> A streamlined, 14 day to market process makes app distribution fast and
> >> easy
> >> Join now and get one step closer to millions of Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >> _______________________________________________
> >> Tikiwiki-devel mailing list
> >> Tikiwiki-devel@...
> >> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Verizon Developer Community
> > Take advantage of Verizon's best-in-class app development support
> > A streamlined, 14 day to market process makes app distribution fast and easy
> > Join now and get one step closer to millions of Verizon customers
> > http://p.sf.net/sfu/verizon-dev2dev
> > _______________________________________________
> > Tikiwiki-devel mailing list
> > Tikiwiki-devel@...
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
> >
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T12:55:47Z

Actually, it works, sort of. The new .tpl file IS being displayed, but none of the Tiki layout appears. In other words, I only see a blank page with the stuff that I added in tiki-choose_page_language.tpl.

How can I display that .tpl, but inside the normal Tiki container? If some can guide me, I promise to add a Code Howto about this here:

http://dev.tikiwiki.org/Code+Maps+and+Howtos

-----Original Message-----
From: Desilets, Alain
Sent: Monday, December 21, 2009 3:51 PM
To: Desilets, Alain; 'Tikiwiki developers'
Subject: RE: [Tikiwiki-devel] Adding a new .tpl file

Hum... it started working all of a sudden. Maybe a cache issue.

Alain

-----Original Message-----
From: Desilets, Alain
Sent: Monday, December 21, 2009 3:31 PM
To: 'Tikiwiki developers'
Subject: RE: [Tikiwiki-devel] Adding a new .tpl file

Oh, btw J-M. Do you see what I am doing wrong in terms of adding the new .tpl file?

Alain

-----Original Message-----
From: Jean-Marc Libs [mailto:jeanmarc.libs@...]
Sent: Monday, December 21, 2009 3:22 PM
To: Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Adding a new .tpl file

It sounds dangerous to me. Pages labelled in the default language by
mistake would be near impossible to find and correct afterwards.
Unlabelled pages, on the opposite, can be listed and corrected.

Jyhem

On Mon, Dec 21, 2009 at 9:09 PM, Rick Sapir <rick.sapir@...> wrote:

> Instead of prompting the user to select a language, should it instead
> default to the site language?
>
> -R
>
>
> ---
> Greetings from Sanford, NC, USA!
> ----- Original Message -----
> From: "Desilets, Alain" <Alain.Desilets@...>
> To: "Tikiwiki developers" <tikiwiki-devel@...>
> Sent: Monday, December 21, 2009 2:50 PM
> Subject: [Tikiwiki-devel] Adding a new .tpl file
>
>
>> Hi folks,
>>
>> I am modifying tiki-editpage.php so that if user asked to create a new
>> page, but its language has not been defined, then the system will prompt
>> him to choose a language.
>>
>> Rather than add yet more code to tiki-editpage.tpl, I want to modularize
>> that in a separate tpl called tiki-choose_page_language.tpl. To that
>> effect, I put the following code in tiki-editpage.tpl
>>
>> if
>> ($editlib->user_needs_to_specify_language_of_page_to_be_created($page,
>> $info)) {
>> echo "<pre>-- tiki-editpage.php: Language needs to be defined.
>> Asking the user to do select it.</pre>\n";
>> $smarty->assign('need_lang', 1);
>> $smarty->display('tiki-choose_page_language.tpl');
>> // $smarty->display('error.tpl');
>> }
>>
>> The file tiki-choose_page_language.tpl exists, and is in the templates
>> directory (and it contains nothing but a stub message). Yet, when I run
>> this, I see the trace:
>>
>> -- tiki-editpage.php: Language needs to be defined. Asking the user
>> to do select it.
>>
>> But tiki still insists on displaying the edit page dialog. What
>>
>> Strangely enough, if I comment out the line for displaying error.tpl
>> instead, it works. Tiki then displays the error screen.
>>
>> What am I doing wrong?
>>
>> Thx.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Tikiwiki-devel mailing list
>> Tikiwiki-devel@...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Tikiwiki-devel mailing list
Tikiwiki-devel@...
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Adding a new .tpl file

2009-12-21T12:50:50Z

Hum... it started working all of a sudden. Maybe a cache issue.

Alain

-----Original Message-----
From: Desilets, Alain
Sent: Monday, December 21, 2009 3:31 PM
To: 'Tikiwiki developers'
Subject: RE: [Tikiwiki-devel] Adding a new .tpl file

Oh, btw J-M. Do you see what I am doing wrong in terms of adding the new .tpl file?

Alain

-----Original Message-----
From: Jean-Marc Libs [mailto:jeanmarc.libs@...]
Sent: Monday, December 21, 2009 3:22 PM
To: Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Adding a new .tpl file

It sounds dangerous to me. Pages labelled in the default language by
mistake would be near impossible to find and correct afterwards.
Unlabelled pages, on the opposite, can be listed and corrected.

Jyhem

On Mon, Dec 21, 2009 at 9:09 PM, Rick Sapir <rick.sapir@...> wrote:

Re: Adding a new .tpl file

2009-12-21T12:31:10Z

Oh, btw J-M. Do you see what I am doing wrong in terms of adding the new .tpl file?

Alain

-----Original Message-----
From: Jean-Marc Libs [mailto:jeanmarc.libs@...]
Sent: Monday, December 21, 2009 3:22 PM
To: Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Adding a new .tpl file

It sounds dangerous to me. Pages labelled in the default language by
mistake would be near impossible to find and correct afterwards.
Unlabelled pages, on the opposite, can be listed and corrected.

Jyhem

On Mon, Dec 21, 2009 at 9:09 PM, Rick Sapir <rick.sapir@...> wrote:

Re: Adding a new .tpl file

2009-12-21T12:30:40Z

I partly agree with you Jyhem. Defaulting to the site language is dangerous in my view, for the same reasons you invoke.

But always defaulting to 'unspecified' is not a solution either, because it the multilingual features quickly become useless when there are too many pages with 'unspecified' language.

As I said in my previous message, there are many situations where we have a pretty good idea of what the language is for a new page. In cases where we don't have such information, we should ask the user to clarify (but only if multilingual features are enabled).

Alain

-----Original Message-----
From: Jean-Marc Libs [mailto:jeanmarc.libs@...]
Sent: Monday, December 21, 2009 3:22 PM
To: Tikiwiki developers
Subject: Re: [Tikiwiki-devel] Adding a new .tpl file

It sounds dangerous to me. Pages labelled in the default language by
mistake would be near impossible to find and correct afterwards.
Unlabelled pages, on the opposite, can be listed and corrected.

Jyhem

On Mon, Dec 21, 2009 at 9:09 PM, Rick Sapir <rick.sapir@...> wrote: