phpwiki-talk

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

On Wed, 16 Oct 2002 11:57:28 -0700
Joby Walker <joby@u.washington.edu> wrote:

> Jeff Dairiki wrote:
> >>By "closed" and "open" I ment to distingish 
> >>between the "GroupGroups page" or "search for /^Group/" methods.
> > Aha!  I would vote strongly against supporting both.  We already have
> > a bad enough case of "creeping featuritis".  Pick one a go with it.
> 
> It actually isn't bad and would have no overhead to implement things in 
> multiple ways. 

My complaints about "creeping featuritis" don't really have much to do
with performance overhead issues.   The two big issues I see are
maintainance/debugging, and general simplicity or lack thereof....

Maintainance: the more ways to do things (code paths) there are
the more likely it is that someone (e.g. me) will break one of those
code paths without noticing it.  If we had a (better) test suite,
this would be less of an issue.  Currently we seem to have constant
problems (and support requests) with bugs that show up e.g. only
when USE_PATH_INFO is off, or when a certain theme is selected, etc...

Remote diagnosis of problems is generally made more difficult, too, when
there are lots of ways to do

Simplicity:  Currently any user documentation we have is lagging way
behind
our feature-set, so users already have to learn how to do things either
via code inspection, guessing, or word-of-mouth (word-of-email,
word-of-wiki)...  Introducing a new feature that can work in a variety
of ways, I think, just adds to the confusion unnecessarily.


Of course this doesn't mean that all new features are bad.
But, in this case, introducing multiple group page paradigms doesn't
really seem to me to add much functionality or usability.


 
> Once, I fix a couple things I'll post my lib/WikiGroup.php (which will 
> not be linked to by anything), so you all can get a look...

Cool!

> So with no "Group" magic name should 
> groups be allowed to have anyname?

Other than the issue you bring up (below) I don't see why not.
(User pages aren't named UserJeff...)  (And there's always the
i18n issue: GrupoCampagnolo?)

> This is frought with problems,

Yes, you're right, it is.  Still I don't really like the
magic list syntax --- I can't really think  of better
alternatives though...

> 1) If a WikiWord is used and that page does not exist.  The group could 
> be compromised by the creation of a user with that WikiWord for a name.

Oof. Yes.  Don't do that.

This problem may show up in other cases, too: what if an administrator
deletes a user (and user page)?  Then (if automatic account creation
is enabled) anyone can usurp that name...   Not sure it's a major
problem, but worth noting...

> 2) It looks like a non-homepage can be compromised and turned into a 
> homepage by adding a CategoryHomepage and then trying to login with that
> 
> name.

Okay.  Maybe the CategoryHomepage idea is a bad one...  Let's fallback
(for the sake of discussion) to detecting user pages by the presence
of user meta-data.

> 3) Every link needs to be investigated to determine if it leads to a 
> homepage -- this determination currently requires parsing the page, so 
> instead of parsing one page to determine a group's members it will 
> require N pages be parsed (where N = number of links on a group page).

A) I don't see why a page parse is needed to detect a home page.
   It should only require looking at the page meta-data.

B) In most cases, it is only of interest if the current (viewing)
   user is a member of a particular group (the group of the requested
   page).  In that case, we already know that the username if interest
   is a valid user (and therefore a valid userpage).

> 4) Without the "Group" magic word a homepage can be a grouppage as well,
> 
> which means that user A could not link to user B's homepage without 
> adding B to A's group.  Which seems overlimiting...

True.  One solution is "don't do that".  ("Doctor, doctor...")
(Another solution would be not to allow that: ignore any groups which
have the same name as a user.)

Jeff

[Phpwiki-talk] Re: Stale Locks (was CVS: phpwiki index2.php,NONE,1.1)

[Joby W. <joby@u.washington.edu>]

Thanks Jeff.  They resolved the issue moments after my request.

jbw

Jeff Dairiki wrote:
>>Now, my old commit process still has a lock on the file -- how 
>>do I undo the lock?
> 
> 
> I think the only way is to file a support request with SourceForge.
> See: 
>   http://sf.net/docman/display_doc.php?docid=768&group_id=1#stalelocks

[Phpwiki-talk] Stale Locks (was CVS: phpwiki index2.php,NONE,1.1)

[Jeff D. <da...@da...>]

> Now, my old commit process still has a lock on the file -- how 
> do I undo the lock?

I think the only way is to file a support request with SourceForge.
See: 
  http://sf.net/docman/display_doc.php?docid=768&group_id=1#stalelocks

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

> By "closed" and "open" I ment to distingish 
> between the "GroupGroups page" or "search for /^Group/" methods.

Aha!  I would vote strongly against supporting both.  We already have
a bad enough case of "creeping featuritis".  Pick one a go with it.


Having thought about the issue a bit more while sleeping last night,
I like the CategoryGroups idea even more...  It's fairly "wiki"ish
and avoids introducing new paradigms while minimizing the introduction
of new "magic" page names.  (Note that since all current backends
have a decent link table (if you ignore bugs in the link extraction
code :-/), I don't think there is any performance hit involved in
going this way.)


Maybe even we don't need to impose the

  FooGroup:
  * MemberOne

syntax?  Perhaps saying that any user-pages linked to by a
group page are members of the group is enough.

Still absorbing the days first cup of coffee...
Jeff

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index2.php,NONE,1.1

[Joby W. <joby@u.washington.edu>]

I was in the process of commiting a minor update to index2.php (correct=20
alphabetization), but my linux box lost power, so the commit did not=20
complete. Now, my old commit process still has a lock on the file -- how=20
do I undo the lock?

jbw


Joseph Walker wrote:
> Update of /cvsroot/phpwiki/phpwiki
> In directory usw-pr-cvs1:/tmp/cvs-serv26097
>=20
> Added Files:
> 	index2.php=20
> Log Message:
> Initial split of index.php into three files: index.php (index2.php here=
 to prevent breakage) config/config-dist.php config/config-user.php.  Not=
e: this will break configurator.php.
>=20
> --- NEW FILE: index2.php ---
> <?php // -*-php-*-
>=20
> /*
> Copyright 1999, 2000, 2001, 2002 $ThePhpWikiProgrammingTeam =3D array(
> "Steve Wainstead", "Clifford A. Adams", "Lawrence Akka",=20
> "Scott R. Anderson", "Jon =C5slund", "Neil Brown", "Jeff Dairiki",
> "St=E9phane Gourichon", "Jan Hidders", "Arno Hollosi", "John Jorgensen"=
,
> "Antti Kaihola", "Jeremie Kass", "Carsten Klapp", "Marco Milanesi",
> "Grant Morgan", "Jan Nieuwenhuizen", "Aredridel Niothke",=20
> "Pablo Roca Rozas", "Sandino Araico S=E1nchez", "Joel Uckelman",=20
> "Joseph (Joby) Walker", "Reini Urban", "Tim Voght");
>=20
> This file is part of PhpWiki.
>=20
> PhpWiki is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2 of the License, or
> (at your option) any later version.
>=20
> PhpWiki is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.
>=20
> You should have received a copy of the GNU General Public License
> along with PhpWiki; if not, write to the Free Software
> Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  U=
SA
> */
>=20
> define ('DEBUG', 1);
> /////////////////////////////////////////////////////////////////////
> // Part Null: Don't touch this!
>=20
> define ('PHPWIKI_VERSION', '1.3.4pre');
> require "lib/prepend.php";
> rcs_id('$Id: index2.php,v 1.1 2002/10/16 16:37:05 zorloc Exp $');
>=20
> require "config/config-user.php";
> require "config/config-dist.php";
>=20
> // Tested: Works with CGI also.
> if (defined('VIRTUAL_PATH') and defined('USE_PATH_INFO')) {
>     if ($HTTP_SERVER_VARS['SCRIPT_NAME'] =3D=3D VIRTUAL_PATH) {
>         include "lib/main.php";
>     }
> } else {
>     if (defined('SCRIPT_NAME') and=20
>         ($HTTP_SERVER_VARS['SCRIPT_NAME'] =3D=3D SCRIPT_NAME)) {
>         include "lib/main.php";
>     } elseif (strstr($HTTP_SERVER_VARS['PHP_SELF'],'index.php')) {
>         include "lib/main.php";
>     }
> }
>=20
> // (c-file-style: "gnu")
> // Local Variables:
> // mode: php
> // tab-width: 8
> // c-basic-offset: 4
> // c-hanging-comment-ender-p: nil
> // indent-tabs-mode: nil
> // End:  =20
> ?>
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> phpwiki-checkins mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins

[Phpwiki-talk] Remove Page removes HomePage fix suggestion

[Oliver B. <ob...@de...>]

Hi All,

removepage.php looks for the actual page name by using

$request->getArg, therefore in HTTP_POST_VARS when hitting the "Remove 
the page now" button.

But HTTP_POST_VARS does not contain the page name (from the URI), at 
least on my system.

Result: the HomePage is deleted.

I inserted another hidden field in the remove form:

HTML::input(array('type' => 'hidden',
                  'name' => 'pagename',
                  'value' => $page->getName())),

It works, but I don't know whether $page->getName() is the best 
approach since I have little knowledge about the interplay of all the 
stuff.

Could this relate to the search functions not working on (some?) 
systems whith USE_PATH_INFO=true? There was also missing the name of 
the search page...

Oliver
-- 
Oliver Betz
DUOmetric GmbH
Buero Muenchen
Stockdorfer Str. 54
D-81475 Muenchen
Tel ++49-89-75967390
Fax ++49-89-75967391

Re: [Phpwiki-talk] GroupWikiPage

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?
> 
> 
> Not sure.  What is the difference, exactly?  Can a "closed group"
> be accomplished just by adjusting page edit/viewing permissions
> (once one can do that, of course...)
> 

Sorry, I was unclear.  By "closed" and "open" I ment to distingish 
between the "GroupGroups page" or "search for /^Group/" methods.

jbw

Re: [Phpwiki-talk] GroupWikiPage

[Jeff D. <da...@da...>]

> I have a method to search for all groups that a particular user is in 
> (for use with searches, etc), and I have been coding it so that it 
> searches for all '/^Group/' pages.  But do we want to do this?  Or 
> should we require that for a Group page to be a recognized group page it
> 
> must be listed on a GroupGroups page?

Not having thought about it much, my inclination is towards the latter.
Mostly because the implementation only introduces one magic page name
instead of a whole class of magic page names.  As I've said before,
I think magic page names are evil.

Maybe instead of being listed in GroupGroups, Group pages could just
link to CategoryGroup.  That maintains most of the advantages of both
of your suggestions.

> Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?

Not sure.  What is the difference, exactly?  Can a "closed group"
be accomplished just by adjusting page edit/viewing permissions
(once one can do that, of course...)

Jeff

[Phpwiki-talk] GroupWikiPage

[Joby W. <joby@u.washington.edu>]

I am working on the GroupWikiPage class and I have a question on 
implementation.  GroupWikiPage is an class that in an implementation of 
Groups for phpwiki, in which the list of group members is in a WikiPage:

GroupAnnoying:
* BobTheBuilder
* TinkyWinky
* BarnyTheDinosaur

I have a method to search for all groups that a particular user is in 
(for use with searches, etc), and I have been coding it so that it 
searches for all '/^Group/' pages.  But do we want to do this?  Or 
should we require that for a Group page to be a recognized group page it 
must be listed on a GroupGroups page?

Advantages of GroupGroups:
1) Better top down management of groups.
2) Quicker/easier generation of grouplists.

Disadvantages:
1) Just searching would involve less management -- which is the halmark 
of the GroupWikiPage method of defining Groups.

Viewpoints?  Should I do both (GroupWikiPageOpen and GroupWikiPageClosed)?

thanks,

jbw

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index.php,1.97,1.98

[Joby W. <joby@u.washington.edu>]

Martin Geisler wrote:
> This annoys me too in my own Wiki - when I update from CVS, I have to
> put my changes to the DB settings back into index.php each time.
> 
> Wouldn't it be better if the file with the local settings was outside
> CVS? That should make it easy for users to update their copy.
> 
> The index.php file could then include the local settings first, and
> then fill in the missing parts along the lines of how lib/config.php
> currently checks the configuration from index.php.
> 

Yes.  We had this discussion as a part of the argument over how to 
implement a configuration scheme.  And pretty much concluded:

1) index.php: would not contain any config data just includes, and 
possibly the invocation of main().

2) config-dist.php: configuration file with default include/variable values.

3) config-user.php: a particular wiki's config data (only includes 
values if different from config-dist.php.

The discussion was how to generate config-user.php.  I proposed that 
there also be a config-valid.php, which would include classes to provide 
potential values or ranges of values and validate a config setting. 
This file would be the single authoritative source for config variables 
(can generate config-dist.php and config-user.php), which could be used 
by Configurator.php (web-based config) or a command line interface 
configurator (cli-config.php).  This would profide:

1) Seperation between user settings and defaults
2) No parsing to get user or default settings (this is ok for a daemon, 
but for a script that has to reparse for each pageview, it is just more 
overhead).
3) One authoritative source for config variables and the potential 
values for those variables.
4) Clean interfaces which increase flexability and will decrease 
breakage over time.

jbw

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index.php,1.97,1.98

[Martin G. <gim...@gi...>]

Reini Urban <ru...@x-...> writes:

> One note on this:
> If someone commits a changed index.php,
> he has to manually check it out on sf.net/demo and fix the cvs merges
> which break the whole wiki otherwise.

This annoys me too in my own Wiki - when I update from CVS, I have to
put my changes to the DB settings back into index.php each time.

Wouldn't it be better if the file with the local settings was outside
CVS? That should make it easy for users to update their copy.

The index.php file could then include the local settings first, and
then fill in the missing parts along the lines of how lib/config.php
currently checks the configuration from index.php.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index.php,1.97,1.98

[Lawrence A. <la...@20...>]

Reini,

I  realised  this  too  late.  I logged into sf, and tried to edit the
file,  but  I  couldn't  because  Steve  had  not given it group write
privileges. I sent him an email yesterday asking him to chmod it.

Thanks for fixing it! I didn't think of your solution.

Lawrence

-- 
Regards,


Lawrence                            

mailto:la...@20...

On Tuesday, October 15, 2002 at 9:27:15 AM, you wrote:

> One note on this:
> If someone commits a changed index.php,
> he has to manually check it out on sf.net/demo and fix the cvs merges 
> which break the whole wiki otherwise.

> cd /home/groups/p/ph/phpwiki/htdocs/demo
> cvs up
> joe index.php

> If he does nothing,
> Steve's script updates it automatically,
> the cvs merge breaks the wiki,
> and anyone who likes to fix it has to deal a permission
> problem for this file.
>    index.php 644 wainstea.phpwiki

> I did it by patching:

> mv index.php index.php.broken
> cvs up -f index.php
> diff -bu index.php index.php.broken > index.patch
> less index.patch
> patch -p0 < index.patch


> Lawrence Akka schrieb:
>> Update of /cvsroot/phpwiki/phpwiki
>> In directory usw-pr-cvs1:/tmp/cvs-serv22719
>> 
>> Modified Files:
>>       index.php 
>> Log Message:
>> Added RSS Auto-discover - see comments for details
>> 
>> Index: index.php
>> ===================================================================
>> RCS file: /cvsroot/phpwiki/phpwiki/index.php,v
>> retrieving revision 1.97
>> retrieving revision 1.98
>> diff -u -2 -b -p -d -r1.97 -r1.98
>> --- index.php 18 Sep 2002 18:34:13 -0000      1.97
>> +++ index.php 12 Oct 2002 19:11:42 -0000      1.98
>> @@ -625,4 +625,18 @@ define('INTERWIKI_MAP_FILE', "lib/interw
>>  //if (!defined('VIRTUAL_PATH')) define('VIRTUAL_PATH', '/SomeWiki');
>>  
>> +/////////////////////////////////////////////////////////////////////
>> +//
>> +// Part Seven:
>> +// Miscellaneous settings
>> +//
>> +/////////////////////////////////////////////////////////////////////
>> +
>> +/*
>> + * Page name of RecentChanges page.  Used for RSS Auto-discovery
>> + */
>> + 
>> +if (!defined('RECENT_CHANGES')) define ('RECENT_CHANGES', 'RecentChanges');
>> +
>> +


==========NOTICE==========

Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.

This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.

Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.

Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki index.php,1.97,1.98

[Reini U. <ru...@x-...>]

One note on this:
If someone commits a changed index.php,
he has to manually check it out on sf.net/demo and fix the cvs merges 
which break the whole wiki otherwise.

cd /home/groups/p/ph/phpwiki/htdocs/demo
cvs up
joe index.php

If he does nothing,
Steve's script updates it automatically,
the cvs merge breaks the wiki,
and anyone who likes to fix it has to deal a permission
problem for this file.
   index.php 644 wainstea.phpwiki

I did it by patching:

mv index.php index.php.broken
cvs up -f index.php
diff -bu index.php index.php.broken > index.patch
less index.patch
patch -p0 < index.patch


Lawrence Akka schrieb:
> Update of /cvsroot/phpwiki/phpwiki
> In directory usw-pr-cvs1:/tmp/cvs-serv22719
> 
> Modified Files:
> 	index.php 
> Log Message:
> Added RSS Auto-discover - see comments for details
> 
> Index: index.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/index.php,v
> retrieving revision 1.97
> retrieving revision 1.98
> diff -u -2 -b -p -d -r1.97 -r1.98
> --- index.php	18 Sep 2002 18:34:13 -0000	1.97
> +++ index.php	12 Oct 2002 19:11:42 -0000	1.98
> @@ -625,4 +625,18 @@ define('INTERWIKI_MAP_FILE', "lib/interw
>  //if (!defined('VIRTUAL_PATH')) define('VIRTUAL_PATH', '/SomeWiki');
>  
> +/////////////////////////////////////////////////////////////////////
> +//
> +// Part Seven:
> +// Miscellaneous settings
> +//
> +/////////////////////////////////////////////////////////////////////
> +
> +/*
> + * Page name of RecentChanges page.  Used for RSS Auto-discovery
> + */
> + 
> +if (!defined('RECENT_CHANGES')) define ('RECENT_CHANGES', 'RecentChanges');
> +
> +
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Workaround Re: [Phpwiki-talk] Yesterday CVS snapshot

[Carsten K. <car...@ya...>]

I found a workaround for this problem.

Edit the BackLinks Page and change the checkbox to use New Markup. 
(/wiki/BackLinks?action=edit)

Alternatively you can change the single quotes '' to double quotes "" 
like this:

<?plugin BackLinks exclude||="" include_self||=1 noheader||=0 page||="" 
info||="" ?>


So the problem may be narrowed down to the code which parses plugins on 
non-new markup pages. No idea how to fix it :( but at least it's 
working.

Carsten

On Sturdau, October 12, 2002, at 04:31  am, Carsten Klapp wrote:

> This is a strange one. Well at least there is nothing wrong with the 
> database or the BackLinks plugin (there is no reindex anyway).
>
> Maybe this will help figure out what needs to be fixed?
>
> doesn't work:  /wiki/HomePage?action=BackLinks
> works:         /wiki/BackLinks?page=HomePage
>
> Carsten

On Monday, October 7, 2002, at 02:30  pm, Rodolfo Pilas wrote:

>
> I have just installed yesterday CVS snapshot and I has the following
> problems:
>
> 1) Each page shows:
> 	PHP Warnings
> 	phpwiki/lib/config.php:402:Notice[8]:Undefined index: dsn
>
>
> 2) The BackLinks do not work.  Any backlink page shows:
> 	No pages link to <?em>
> Is there are something like reindex?
>
>
> Any suggestion.


On Monday, October 7, 2002, at 02:30  pm, Rodolfo Pilas wrote:

> I have just installed yesterday CVS snapshot and I has the following
> problems:
>
> 1) Each page shows:
> 	PHP Warnings
> 	phpwiki/lib/config.php:402:Notice[8]:Undefined index: dsn
>
>
> 2) The BackLinks do not work.  Any backlink page shows:
> 	No pages link to <?em>
> Is there are something like reindex?
>
>
> Any suggestion.

Re: [Phpwiki-talk] wiki plugin-form question

[Lawrence A. <la...@us...>]

On Monday 14 Oct 2002 11:54 pm, Jeff Dairiki wrote:
> > What I had in mind was:
> >
> > data posted to plugin : plugin uploads file
> > plugin called as form (eg with ?show=3Dform or something like that):
> > plugin shows form, allowing file to be chosen for upload
> > plugin called in any other way:  plugin displays list of attachments =
on
> > this (or another specified) page.
>
> How about:
>
> Normal invocation: plugin lists attachments, and also includes form
> to upload a new attachment (as well as delete current attachments...).

Hmmm...  It would be good to be able to have a list of attachments withou=
t a=20
form at the end.  Perhaps we could have an option which supresses the for=
m.

As for deletion, my current intention is to keep all old revisions of a f=
ile. =20
I guess "deleted" files could be hidden by default.  I'll have to think a=
 bit=20
more, but too tired now ... (midnight).  Off to bed.

Lawrence

Re: [Phpwiki-talk] wiki plugin-form question

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>Is it possible to create a plugin-form which has an input box of
>>type="file"?
> 
> 
> In spite of the dregs of code in WikiPlugin::makeForm which would hint
> otherwise, I don't think you can do it (without code changes).  (The
> remnant code seems to be completely my fault, but at this point, I have
> no recollection of why it's there...)
> 
> I'm not sure exactly about what kind of user interface you're thinking of,
> but I'm thinking it would be best if the FileUpload plugin produced the
> file upload form itself.  (Rather than using <?plugin-form?> which really 
> is supposed to produce a "link" to a plugin...)
> 
> Sorry for the confusion...
> Jeff
> 

I concur.  For my wiki I expanded WikiPlugin to be able to generate a 
textbox and/or a select box.  It is not too hard to do...

jbw

Re: [Phpwiki-talk] wiki plugin-form question

[Jeff D. <da...@da...>]

> What I had in mind was:
> 
> data posted to plugin : plugin uploads file
> plugin called as form (eg with ?show=form or something like that): 
> plugin shows form, allowing file to be chosen for upload
> plugin called in any other way:  plugin displays list of attachments on
> this (or another specified) page.

How about:

Normal invocation: plugin lists attachments, and also includes form
to upload a new attachment (as well as delete current attachments...).

Re: [Phpwiki-talk] wiki plugin-form question

[Lawrence A. <la...@us...>]

On Monday 14 Oct 2002 11:35 pm, Jeff Dairiki wrote:
> > Is it possible to create a plugin-form which has an input box of
> > type=3D"file"?
>
> In spite of the dregs of code in WikiPlugin::makeForm which would hint
> otherwise, I don't think you can do it (without code changes).  (The
> remnant code seems to be completely my fault, but at this point, I have
> no recollection of why it's there...)
>

Aha.  I wondered if I was missing something.


> I'm not sure exactly about what kind of user interface you're thinking =
of,
> but I'm thinking it would be best if the FileUpload plugin produced the
> file upload form itself. =20

Last night, I had coded this.  Then I decided I really ought to use the=20
plugin-form api since it was there.  Good job I only commented out my ear=
lier=20
code, rather than deleting it then!

What I had in mind was:

data posted to plugin : plugin uploads file
plugin called as form (eg with ?show=3Dform or something like that):  plu=
gin=20
shows form, allowing file to be chosen for upload
plugin called in any other way:  plugin displays list of attachments on t=
his=20
(or another specified) page.

Lawrence

Re: [Phpwiki-talk] wiki plugin-form question

[Jeff D. <da...@da...>]

> Is it possible to create a plugin-form which has an input box of
> type="file"?

In spite of the dregs of code in WikiPlugin::makeForm which would hint
otherwise, I don't think you can do it (without code changes).  (The
remnant code seems to be completely my fault, but at this point, I have
no recollection of why it's there...)

I'm not sure exactly about what kind of user interface you're thinking of,
but I'm thinking it would be best if the FileUpload plugin produced the
file upload form itself.  (Rather than using <?plugin-form?> which really 
is supposed to produce a "link" to a plugin...)

Sorry for the confusion...
Jeff

[Phpwiki-talk] wiki plugin-form question

[Lawrence A. <la...@us...>]

Anyone (Jeff?)

Is it possible to create a plugin-form which has an input box of type=3D"=
file"?

WikiPlugin.php line 203:     $i->setAttr('type', 'text'); =20

looks promising, but its too late in the day for me to figure out how to =
make=20
use of it.  Help, anyone?

Lawrence

Re: [Phpwiki-talk] accents/umlauts in file names

[Oliver B. <ob...@de...>]

Last week I wrote:

> there are some files with non-ascii-characters converted to hex 
> codes, especially some buttons in the Spanish and German MacOSX 
> theme. I think that's not a good idea since one can't upload them via 
> FTP.

Reading RFC959 I found that it wasn't a problem of FTP but a 
"unusual" configuration of my ISP.

Sorry for posting nonsense.

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Upload Mechanism

[Lawrence A. <la...@us...>]

On Sunday 13 Oct 2002 5:39 pm, Reini Urban wrote:
> Paul Pearson schrieb:
> > Going a little beyond that, I would like the ability to have the
> > uploaded files assigned to the page they were uploaded to - something
> > like attaching a file to a page and having the page list all the file=
s
> > that are attached to it.
>

I am working on something like this at the moment.  May be finished in th=
e=20
next few days.

There are various issues to be addresses, eg should the attachments be st=
ored=20
in the filesystem, or in the DB?  Should users have the ability to delete=
=20
files? etc

Lawrence

Re: [Phpwiki-talk] Upload Mechanism

[Reini U. <ru...@x-...>]

Wandrer schrieb:
> At 06:39 PM 10/13/2002 +0200, you wrote:
> 
>> Paul Pearson schrieb:
>>
>>> Going a little beyond that, I would like the ability to have the 
>>> uploaded files assigned to the page they were uploaded to - something 
>>> like attaching a file to a page and having the page list all the 
>>> files that are attached to it.
>>
>> Automatically?
>> As subpage or as dynamic list of attached files?
>> This could be a fine extension to UpLoad.
>> I would just add a
>>   "* UploadedFileUrl\n"
>> to the page on a certain parameter.
> 
> 
> Lets say that someone creates a new page (SolarSystem) in phpwiki on 
> their website. The ability for the individual to upload a flash 
> animation file (SolarSystemInMotion.swf) and 'attach' it to the page 
> would be a benefit. The link would appear at the bottom of the page with 
> the file(s) name and allow people to download the file by clicking on 
> it. Then, being able to edit/delete/create additional links so that when 
> a better SolarSystem animation file is produced, he could delete the old 
> file and upload the newer file. Does that make sense ?

Yes. Like a blog.

See also http://www.advogato.org/article/561.html
* image/file uploading by users to seed new blog entries and create 
thumbnails.
(this is the only missing item for phpwiki to please this folk)

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Upload Mechanism

[Wandrer <wa...@gl...>]

At 06:39 PM 10/13/2002 +0200, you wrote:
>Paul Pearson schrieb:
>>Going a little beyond that, I would like the ability to have the uploaded 
>>files assigned to the page they were uploaded to - something like 
>>attaching a file to a page and having the page list all the files that 
>>are attached to it.
>Automatically?
>As subpage or as dynamic list of attached files?
>This could be a fine extension to UpLoad.
>I would just add a
>   "* UploadedFileUrl\n"
>to the page on a certain parameter.

Lets say that someone creates a new page (SolarSystem) in phpwiki on their 
website. The ability for the individual to upload a flash animation file 
(SolarSystemInMotion.swf) and 'attach' it to the page would be a benefit. 
The link would appear at the bottom of the page with the file(s) name and 
allow people to download the file by clicking on it. Then, being able to 
edit/delete/create additional links so that when a better SolarSystem 
animation file is produced, he could delete the old file and upload the 
newer file. Does that make sense ?

Paul

Re: [Phpwiki-talk] Upload Mechanism

[Reini U. <ru...@x-...>]

Paul Pearson schrieb:
> Going a little beyond that, I would like the ability to have the 
> uploaded files assigned to the page they were uploaded to - something 
> like attaching a file to a page and having the page list all the files 
> that are attached to it. 

Automatically?
As subpage or as dynamic list of attached files?

This could be a fine extension to UpLoad.
I would just add a
   "* UploadedFileUrl\n"
to the page on a certain parameter.

> On a phpwiki that I am working on, we need the 
> ability to assign ZIP/PDF files to the page which get updated every week 
> or so (upload new copy, delete old copy, update wiki with new 
> information)...

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/