phpwiki-talk

[Phpwiki-talk] wikiblog - adding time and author stamps

[<sh...@be...>]

Hello All,

I apologize for what may be a silly question.  After a bit of poking around the phpwiki documentation and the mailing list archives, I haven't come across an answer yet.

I've found many examples of wikiblog plugin pages on the web which append a date stamp and author header to every entry.

When I add the wikiblog plugin to a page on our wiki, everything works fine, but the time stamp and author information is missing.

I've tried all the plugin options and none seem to affect this behavior.  

Before I delve into the guts of phpwiki, I figured I'd see if anyone out there knows the trick to getting date stamps to appear.  

I'm using phpwiki "1.3.11 (not yet)"  and WikiBlog v 1.22.

Thanks,
Erik

Re: [Phpwiki-talk] assert failing for page access

[Joel U. <uck...@no...>]

Thus spake Joel Uckelman:
> Just now I discovered something anomalous when using DBA. (I haven't tested
> yet whether this afflicts other backends.) For a while now a wiki I run would
> occasionally be unable to load some (but not all) pages, and would fail as so
> :
> 
> Fatal Error:
> 
> lib/WikiDB.php:661: Error: <br />/home/uckelman/projects/phpwiki/lib/WikiDB.p
> hp:661: : Assertion failed <br />
> 
> The offending assertion is:
> 
>    assert(is_string($pagename) and $pagename != '');
> 
> which I found quite perplexing. The problem isn't database corruption,
> so far as I can see, since I can edit all of the pages which fail this
> assertion and the text in the edit box is correct.
> 
> But when DEBUG is nonzero, this problem does not occur! Why?
> Well, the assert is part of this bit of code:
> 
> if (DEBUG) {
>  if (!(is_string($pagename) and $pagename != '')) {
>   if (function_exists("xdebug_get_function_stack")) {
>    echo "xdebug_get_function_stack(): "; var_dump(xdebug_get_function_stack()
> );
>   } elseif (function_exists("debug_backtrace")) { // >= 4.3.0
>    printSimpleTrace(debug_backtrace());
>   }
>   trigger_error("empty pagename", E_USER_WARNING);
>   return false;
>  }
> } else
>  assert(is_string($pagename) and $pagename != '');
> 
> 
> With DEBUG=1, for example, I get the "empty pagename" warning, but the page
> outputs correctly, and I also get this notice, twice:
> 
> lib/stdlib.php:2028: Notice[8]: Array to string conversion
> 
> When $pagename is nonempty and not a string (the failure case) it comes
> up in my test wiki as 'Array'.
> 
> Something's screwed up here... I'm going to mess with this some more this
> evening. Any idea what might be wrong?
>

I see now in the change log for lib/WikiDB.php that as of 1.137 "getPageLinks
returns now an array of hashes", which explains the change of behavior...
WikiDB_PageIterator::next() doesn't like it that it's getting an array of
hashes instead of an array of page names. getPageLinks calls getLinks, which
is where the WikiDB_PageIterator is constructed. I'm a bit in the dark
about how to fix this, as the note seems to indicate that the change to
getPageLinks was intentional and isn't itself a bug.

-- 
J.

[Phpwiki-talk] Problems with internal links?

[Alan H. <al...@em...>]

I'm running 1.3.11p1 on FC4.

I'm having trouble getting internal links to work for me.  I'm trying
to convert
   http://www.alanhoyle.com/hearts.html
into my wiki:
   http://www.alanhoyle.com/wiki/index.php/Hearts

I've tried following the instructions in:
    http://www.alanhoyle.com/wiki/index.php/TextFormattingRules

 Named anchors:
    #[foo]: An anchor around the text "foo" with id "foo".
    #[|foo]: An empty anchor with id "foo".
    #[howdy|foo]: An anchor around the text "howdy" with id "foo".
 References to name anchors are made thusly:
    [##hyperlinks], [OtherPage#foo], [named|OtherPage#foo].

but they don't seem to work.

--
   Alan Hoyle  -  al...@un...  -  http://www.alanhoyle.com/
     "I don't want the world, I just want your half." -TMBG
                Get Horizontal, Play Ultimate.

[Phpwiki-talk] assert failing for page access

[Joel U. <uck...@no...>]

Just now I discovered something anomalous when using DBA. (I haven't tested
yet whether this afflicts other backends.) For a while now a wiki I run would
occasionally be unable to load some (but not all) pages, and would fail as so:

Fatal Error:

lib/WikiDB.php:661: Error: <br />/home/uckelman/projects/phpwiki/lib/WikiDB.php:661: : Assertion failed <br />

The offending assertion is:

   assert(is_string($pagename) and $pagename != '');

which I found quite perplexing. The problem isn't database corruption,
so far as I can see, since I can edit all of the pages which fail this
assertion and the text in the edit box is correct.

But when DEBUG is nonzero, this problem does not occur! Why?
Well, the assert is part of this bit of code:

if (DEBUG) {
 if (!(is_string($pagename) and $pagename != '')) {
  if (function_exists("xdebug_get_function_stack")) {
   echo "xdebug_get_function_stack(): "; var_dump(xdebug_get_function_stack());
  } elseif (function_exists("debug_backtrace")) { // >= 4.3.0
   printSimpleTrace(debug_backtrace());
  }
  trigger_error("empty pagename", E_USER_WARNING);
  return false;
 }
} else
 assert(is_string($pagename) and $pagename != '');


With DEBUG=1, for example, I get the "empty pagename" warning, but the page
outputs correctly, and I also get this notice, twice:

lib/stdlib.php:2028: Notice[8]: Array to string conversion

When $pagename is nonempty and not a string (the failure case) it comes
up in my test wiki as 'Array'.

Something's screwed up here... I'm going to mess with this some more this
evening. Any idea what might be wrong?

-- 
J.

Re: [Phpwiki-talk] Converting all pages from old markup to new markup

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

2006/1/10, asko <ask...@ku...>:
> Reini Urban wrote:
> > There's a new plugin called WikiAdminMarkup, which does just this.
> > But there's the action page missing.
> > Create the page PhpWikiAdministration/Markup and set it to
> > <?plugin WikiAdminMarkup ?>
> Hi Reini,
>
> thank you for your answer. WikiAdminMarkup currently seems to set the
> page type to new markup, but without converting data.
>
> For the archive, I managed to accomplish what i needed, replacing the lin=
e
>
> "$text =3D $current->getPackedContent();" in
>
> lib/plugin/WikiAdminMarkup.php with
>
> $text =3D ConvertOldMarkup($current->getPackedContent());
>
> It did the trick. Maybe the WikiAdminMarkup plugin should have a button,
> whether to convert the data or not..

Oops, Thanks for testing this.

--
Reini Urban
http://spacemovie.mur.at/

Re: [Phpwiki-talk] 1.3.11p1: bug in .jpeg handling

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

2006/1/8, Alan Hoyle <al...@em...>:
> I've added it to the INLINE_IMAGES line and I still have the same problem=
.
>
> $ grep jpeg config.ini
> INLINE_IMAGES =3D "png|jpg|gif|jpeg|swf|wrl|svg|class"
> PLUGIN_CACHED_IMGTYPES =3D "png|gif|gd|gd2|jpeg|wbmp|xbm|xpm"
> $

Hmm, I deleted one of the two spaces before the closing "]" and now it work=
s.
Thanks for the report, will be fixed ASAP.

> On 1/7/06, Reini Urban <ru...@x-...> wrote:
> > You have to allow every inlinable extension in config.ini
> > default is INLINE_IMAGES =3D "png|jpg|gif|svg|swf|class|wrl"
> > add jpeg and your are fine.
> >
> > 2006/1/6, Alan Hoyle <al...@em...>:
> > > I recently upgraded my wiki to 1.3.11p1.  I was playing around trying
> > > to get inline images to work by playing in the sandbox.
> > >
> > > http://www.alanhoyle.com/wiki/index.php/SandBox
> > >
> > > If I use .png, .gif or .jpg as the file extension they work fine, but
> > > if I use .jpeg, it fails.
> > >
> > > http://www.alanhoyle.com/tmp/php-jpeg-bug.png
> > >
> > > Here is the wiki text:
> > >
> > > -----------------
> > > You can try out Wiki in here.
> > >
> > > Have fun :-)
> > >
> > > hello world.
> > >
> > > [ http://www.alanhoyle.com/images/val-bmh2001.jpg ]
> > >
> > > [ http://www.alanhoyle.com/images/val-bmh_doctored.jpeg  ]

Re: [Phpwiki-talk] Converting all pages from old markup to new markup

[asko <ask...@ku...>]

Reini Urban wrote:
> There's a new plugin called WikiAdminMarkup, which does just this.
> But there's the action page missing.
> Create the page PhpWikiAdministration/Markup and set it to
> <?plugin WikiAdminMarkup ?>
Hi Reini,

thank you for your answer. WikiAdminMarkup currently seems to set the 
page type to new markup, but without converting data.

For the archive, I managed to accomplish what i needed, replacing the line

"$text = $current->getPackedContent();" in

lib/plugin/WikiAdminMarkup.php with

$text = ConvertOldMarkup($current->getPackedContent());

It did the trick. Maybe the WikiAdminMarkup plugin should have a button, 
whether to convert the data or not..


--
asko

Re: [Phpwiki-talk] 1.3.11p1: bug in .jpeg handling

[Alan H. <al...@em...>]

I've added it to the INLINE_IMAGES line and I still have the same problem.

$ grep jpeg config.ini
INLINE_IMAGES =3D "png|jpg|gif|jpeg|swf|wrl|svg|class"
PLUGIN_CACHED_IMGTYPES =3D "png|gif|gd|gd2|jpeg|wbmp|xbm|xpm"
$



On 1/7/06, Reini Urban <ru...@x-...> wrote:
> You have to allow every inlinable extension in config.ini
> default is INLINE_IMAGES =3D "png|jpg|gif|svg|swf|class|wrl"
> add jpeg and your are fine.
>
> 2006/1/6, Alan Hoyle <al...@em...>:
> > I recently upgraded my wiki to 1.3.11p1.  I was playing around trying
> > to get inline images to work by playing in the sandbox.
> >
> > http://www.alanhoyle.com/wiki/index.php/SandBox
> >
> > If I use .png, .gif or .jpg as the file extension they work fine, but
> > if I use .jpeg, it fails.
> >
> > http://www.alanhoyle.com/tmp/php-jpeg-bug.png
> >
> > Here is the wiki text:
> >
> > -----------------
> > You can try out Wiki in here.
> >
> > Have fun :-)
> >
> > hello world.
> >
> > [ http://www.alanhoyle.com/images/val-bmh2001.jpg ]
> >
> > [ http://www.alanhoyle.com/images/val-bmh_doctored.jpeg  ]
> > -----------------
> >
> > --
> >    Alan Hoyle  -  al...@un...  -  http://www.alanhoyle.com/
> >      "I don't want the world, I just want your half." -TMBG
> >                 Get Horizontal, Play Ultimate.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> > _______________________________________________
> > Phpwiki-talk mailing list
> > Php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> >
>
>
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>


--
   Alan Hoyle  -  al...@un...  -  http://www.alanhoyle.com/
     "I don't want the world, I just want your half." -TMBG
                Get Horizontal, Play Ultimate.

Re: [Phpwiki-talk] 1.3.11p1: bug in .jpeg handling

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

You have to allow every inlinable extension in config.ini
default is INLINE_IMAGES =3D "png|jpg|gif|svg|swf|class|wrl"
add jpeg and your are fine.

2006/1/6, Alan Hoyle <al...@em...>:
> I recently upgraded my wiki to 1.3.11p1.  I was playing around trying
> to get inline images to work by playing in the sandbox.
>
> http://www.alanhoyle.com/wiki/index.php/SandBox
>
> If I use .png, .gif or .jpg as the file extension they work fine, but
> if I use .jpeg, it fails.
>
> http://www.alanhoyle.com/tmp/php-jpeg-bug.png
>
> Here is the wiki text:
>
> -----------------
> You can try out Wiki in here.
>
> Have fun :-)
>
> hello world.
>
> [ http://www.alanhoyle.com/images/val-bmh2001.jpg ]
>
> [ http://www.alanhoyle.com/images/val-bmh_doctored.jpeg  ]
> -----------------
>
> --
>    Alan Hoyle  -  al...@un...  -  http://www.alanhoyle.com/
>      "I don't want the world, I just want your half." -TMBG
>                 Get Horizontal, Play Ultimate.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>


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

Re: [Phpwiki-talk] Converting all pages from old markup to new markup

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

There's a new plugin called WikiAdminMarkup, which does just this.
But there's the action page missing.

Create the page PhpWikiAdministration/Markup and set it to
<?plugin WikiAdminMarkup ?>


2006/1/6, asko <ask...@ku...>:
> I am migrating from phpwiki 1.3.0pre to phpwiki 1.3.11.
>
> Is there a way to convert all pages to new markup format before or after
> restoring the dumped files?
>
> I could do it manually one by one, Convert button next to "Use old
> markup" in Edit page seems to convert my tables just fine. But i have a
> lot of tables .. Is there a better way?
>
> There's a ConvertOldMarkup function in lib/stdlib.php, but i'm not sure
> what to do with it ;-)
--
Reini Urban

[Phpwiki-talk] converting all pages from old markup to new

[asko <as...@ku...>]

Hi,

I'm migrating from phpwiki 1.3pre version and I need my old tables to 
new format. Is there a way to convert all pages at once, rather than 
editing them all one at a time and using Convert button..

There's a ConvertOldMarkup function in lib/stdlib.php, but I'm not quite 
sure how to use it..

thanks
asko

[Phpwiki-talk] 1.3.11p1: bug in .jpeg handling

[Alan H. <al...@em...>]

I recently upgraded my wiki to 1.3.11p1.  I was playing around trying
to get inline images to work by playing in the sandbox.

http://www.alanhoyle.com/wiki/index.php/SandBox

If I use .png, .gif or .jpg as the file extension they work fine, but
if I use .jpeg, it fails.

http://www.alanhoyle.com/tmp/php-jpeg-bug.png

Here is the wiki text:

-----------------
You can try out Wiki in here.

Have fun :-)

hello world.

[ http://www.alanhoyle.com/images/val-bmh2001.jpg ]

[ http://www.alanhoyle.com/images/val-bmh_doctored.jpeg  ]
-----------------

--
   Alan Hoyle  -  al...@un...  -  http://www.alanhoyle.com/
     "I don't want the world, I just want your half." -TMBG
                Get Horizontal, Play Ultimate.

[Phpwiki-talk] Converting all pages from old markup to new markup

[asko <ask...@ku...>]

Hi,

I am migrating from phpwiki 1.3.0pre to phpwiki 1.3.11.

Is there a way to convert all pages to new markup format before or after 
restoring the dumped files?

I could do it manually one by one, Convert button next to "Use old 
markup" in Edit page seems to convert my tables just fine. But i have a 
lot of tables .. Is there a better way?

There's a ConvertOldMarkup function in lib/stdlib.php, but i'm not sure 
what to do with it ;-)

thanks,

asko

[Phpwiki-talk] Delete Pages

[Ben H. <ph...@gr...>]

Hi,

I am looking at the 'delete page' button, and am curious about how it
works.

If I delete a page, what really happens? =20

The root of my question is this - there are times when I delete a page
that I want the data to become inaccessible, rather than just unlinked.

After deleting a page, it seems that
* links to the page are now links to create the page, and I get a blank
  slate
* the page no longer shows up in page lists (owned by me, etc.)
* if I address the page directly by URL, I can see the 'deleted'
  content.

Is this accurate? =20

I also see a button to irrecoverably delete orphaned pages.  Would this
get rid of the 'deleted' content? =20

How does the purge button relate with the Calendar plugin and sub pages?
Many of the calendar plugin pages don't have a direct link to them
(especially after 1 month), so would they get deleted by the purge
button?

Thanks,

-ben

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Phpwiki-talk] ACLs

[Ben H. <ph...@gr...>]

To all who helped implement ACLs - Thank You!  I am very glad to have
this feature. =20

A few questions=20

* Is it possible to disable read access for non-signed in
users?  I would like to protect a few pages from guests.  I have found
the dot-pages notation (name a page .CantBeReadByAnon), but it would be
nice to apply this same restriction to regular pages at will.  I tried
removing "Every" view permisisons through the ACL page, but it didn't
seem to take effect - non-signed in users could still see the page.  Is
there any relation to the dot-page and the real-page?  i.e. does a page
named FooBarBaz have any relation to one named .FooBarBaz? =20

* Is it possible to make groups of users (boys girls) and allow the boys
to create a page that the girls can't read, and vice versa?  In other
words, is it possible to define access based on *who* you are rather
than your authentication status (bogouser, authenticated user, etc.)?  I
see a reference too it, but not quite enough for me to figure out how to
actually do it. (and the note to self to explain better.  :)


Hmm....  After looking at /wiki/index.php/PagePermissions (didn't find
it at first - I was looking at the ACL page which was empty / didn't
load), I see that there is some info there on how it works. =20

Is there any chance at someone who knows what's going on doing a little
more / better documentation?  I don't mean to insult in any way the
author of the current documentation - I just don't see the whole picture
yet and I'm having a hard time finding all the pieces.  I know
documenting sucks and is hard...  :/


Thanks,

-ben

--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Phpwiki-talk] upgrade from 1.3.10 to 1.3.11p1

[Ben H. <ph...@gr...>]

Hi all,

I am upgrading a phpwiki installation from 1.3.10 to 1.3.11p1.  I am
reading the upgrade instructions, and I am missing something.

Here is the begining of the upgrade file:

> To migrate to a new phpwiki installation you have to backup your old page=
s=20
> (best via a zip dump), configure your new installation, and restore the o=
ld=20
> pages in PhpWikiAdministration. Or just upgrade your configuration as=20
> described below.
>=20
> UPGRADING since 1.3.10
>=20
> To upgrade default pages, the database and some config settings=20
> add "?action=3Dupgrade" to your HomePage url and press "Enter", which will
> do most of the upgrades automatically.
> You might need to enter the DBADMIN_USER and DBADMIN_PASSWD in=20
> config/config.ini for SQL databases and default permissions.

As I understand it, you can rephrase the first paragraph as follows:

> There are two ways to upgrade an existing PhpWiki installation. =20
>=20
> 1) Backup your pages (via a zip dimp), configure your new installation,
> and restore the old pages in PhpWikiAdministration.
>=20
> 2) Upgrade your installation as described below.

Is this a correct restatement of the first paragraph, or am I
misinterpreting what is written there?

I am choosing to follow the second path rather than the first, but I
think it might be helpful to include a reference to a page describing
how to backup pages and how to restore pages from a backup, for those
interested in pursuing the first option.

Getting on to the second option, we come to the second paragraph quoted
above:

> UPGRADING since 1.3.10
>
> To upgrade default pages, the database and some config settings add
> "?action=3Dupgrade" to your HomePage url and press "Enter", which will
> do most of the upgrades automatically.  You might need to enter the
> DBADMIN_USER and DBADMIN_PASSWD in config/config.ini for SQL databases
> and default permissions.

There's a step missing - what is the best way to get the new files into
place?  I have my wiki installation sitting in /a/b/c/phpwiki-1.3.10/.
The new one, presumably, will sit at /a/b/c/phpwiki-1.3.11/. =20

Should I:

* rename phpwiki-1.3.10 to phpwiki-1.3.11 then untar the tgz file over
the existing directory, thereby replacing the files that have changed?
If so, what files should I remove (configurator?) so as to avoid the
possibility of someone reinitializing my installation?

* untar phpwiki-1.3.11 to a new place, and selectively copy over files
(such as config.ini)?  Which files should I copy over?  I think I'm
going to try this approach, and hope that config.ini is the only file I
need to copy over, but I still wonder if there are any files that the
configurator removes so as to protect itself.

At some point after the new files are in the right place, I should do as
it says (add ?action=3Dupgrade) to my URL, but I wonder when...


I appreciate having the docs to help the upgrade, but I think answers to
the questions above might help improve the document.  :)

Thanks!

-ben



--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Phpwiki-talk] upgrade from 1.3.10 to 1.3.11p1

[Ben H. <tr...@gr...>]

Hi all,

I am upgrading a phpwiki installation from 1.3.10 to 1.3.11p1.  I am
reading the upgrade instructions, and I am missing something.

Here is the begining of the upgrade file:

> To migrate to a new phpwiki installation you have to backup your old page=
s=20
> (best via a zip dump), configure your new installation, and restore the o=
ld=20
> pages in PhpWikiAdministration. Or just upgrade your configuration as=20
> described below.
>=20
> UPGRADING since 1.3.10
>=20
> To upgrade default pages, the database and some config settings=20
> add "?action=3Dupgrade" to your HomePage url and press "Enter", which will
> do most of the upgrades automatically.
> You might need to enter the DBADMIN_USER and DBADMIN_PASSWD in=20
> config/config.ini for SQL databases and default permissions.

As I understand it, you can rephrase the first paragraph as follows:

> There are two ways to upgrade an existing PhpWiki installation. =20
>=20
> 1) Backup your pages (via a zip dimp), configure your new installation,
> and restore the old pages in PhpWikiAdministration.
>=20
> 2) Upgrade your installation as described below.

Is this a correct restatement of the first paragraph, or am I
misinterpreting what is written there?

I am choosing to follow the second path rather than the first, but I
think it might be helpful to include a reference to a page describing
how to backup pages and how to restore pages from a backup, for those
interested in pursuing the first option.

Getting on to the second option, we come to the second paragraph quoted
above:

> UPGRADING since 1.3.10
>
> To upgrade default pages, the database and some config settings add
> "?action=3Dupgrade" to your HomePage url and press "Enter", which will
> do most of the upgrades automatically.  You might need to enter the
> DBADMIN_USER and DBADMIN_PASSWD in config/config.ini for SQL databases
> and default permissions.

There's a step missing - what is the best way to get the new files into
place?  I have my wiki installation sitting in /a/b/c/phpwiki-1.3.10/.
The new one, presumably, will sit at /a/b/c/phpwiki-1.3.11/. =20

Should I:

* rename phpwiki-1.3.10 to phpwiki-1.3.11 then untar the tgz file over
the existing directory, thereby replacing the files that have changed?
If so, what files should I remove (configurator?) so as to avoid the
possibility of someone reinitializing my installation?

* untar phpwiki-1.3.11 to a new place, and selectively copy over files
(such as config.ini)?  Which files should I copy over?  I think I'm
going to try this approach, and hope that config.ini is the only file I
need to copy over, but I still wonder if there are any files that the
configurator removes so as to protect itself.

At some point after the new files are in the right place, I should do as
it says (add ?action=3Dupgrade) to my URL, but I wonder when...


I appreciate having the docs to help the upgrade, but I think answers to
the questions above might help improve the document.  :)

Thanks!

-ben



--=20
Ben Hartshorne
email: be...@ha...
http://ben.hartshorne.net

[Phpwiki-talk] admin.php problem

[Russell J. <rj...@my...>]

Hello,

 

I have a cPanel/Fantastico client who has installed PhpWiki 1.2.10 and
cannot log into the admin.php page.  The problem lies in $PHP_AUTH_USER and
$PHP_AUTH_PW.  Both of those variables are empty after attempting to enter
the username/password in the HTTP authentication box.

 

Because of the variable emptiness the conditionals of course fail.  The
conditionals I'm referring to are:

 

// From the manual, Chapter 16   

if (($PHP_AUTH_USER != $wikiadmin  )  ||

    ($PHP_AUTH_PW   != $adminpasswd)) {

 

As a result no matter what I try the following executes:

 

echo gettext("You entered an invalid login or password.");

exit;

 

I suspect there is some sort of server, perhaps simply php, configuration
which is preventing those two variables from being populated.  If someone
can please shed some light on my issue I will be extremely grateful.

 

Russell

[Phpwiki-talk] Re: phpwiki error + correction

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

SGkgTWljaGFsLApDVlMgU291cmNlIGlzIGN1cnJlbnRseSB2ZXJ5IHVuc3RhYmxlLgpUaGVyZSBh
cmUgZXZlbiBtb3JlIGVycm9ycyB0aGF0IEkgY291bGRuJ3QgZml4IHlldC4KRG9uJ3QgdXNlIHRo
ZSBuZXcgOjogYW5kIDotIHN5bnRheCB1bmxlc3MgeW91IGFyZSBpbiBBRE9EQi4KCjIwMDYvMS8y
LCBNaWNoYWwgS/hpdmthIDxrcml2a2FAY2VudHJ1bS5jej46Cj4gV29ya2luZyB3aXRoIENWUyBz
b3VyY2UsIEkgZm91bmQgZXJyb3JzIHdoaWxlIGxvYWRpbmcgdmlyZ2luIHBocHdpa2kKPgo+IDEu
KSBUZXh0Rm9ybWF0dGluZ1J1bGVzICBhbmQgT2xkVGV4dEZvcm1hdHRpbmdSdWxlcyBwYWdlcyBj
YW5ub3QgYmUgbG9hZC4KPiAgICAgRXJyb3IgaW4gL2xpYi9sb2Fkc2F2ZS5waHAsIGxpbmUgMTI3
MywgaGVscCBzdWJkaXIgaXMgbmV3IDoKPgo+IGZvcmVhY2gKPiAoYXJyYXlfbWVyZ2UoZXhwbG9k
ZSgnOicsJ0hlbHAvT2xkVGV4dEZvcm1hdHRpbmdSdWxlczpIZWxwL1RleHRGb3JtYXR0aW5nUnVs
ZXM6UGhwV2lraUFkbWluaXN0cmF0aW9uJyksCj4KPiAyLikgU29tZSBwYWdlcyByZXBvcnRzOgo+
Cj4gbGliL2xvYWRzYXZlLnBocDoxMjkwOiBXYXJuaW5nOiBNYW5kYXRvcnkgZmlsZSBSYXRlSXQg
Y291bGRuJ3QgYmUgbG9hZGVkIQo+Cj4gdGhlcmUgYXJlIG1vcmUgcGFnZXMgcmVwb3J0ZWQgd2l0
aCB0aGUgc2FtZSBiZWhhdmlvci4KPgo+IFdoZW4gaGlzIGZpcnN0IHJ1biBlbmRzLCBIb21lIHBh
Z2UgaXMgbm90IGxvYWRlZCBhbmQgbmV4dCBydW4gaXMgYXMKPiB2aXJnaW4gcnVuLgo+ICBJIGhh
dmUgbm90IHNvbHV0aW9uIG9mIHRoaXMgcHJvYmxlbSB5ZXQuCi0tClJlaW5pIFVyYmFuCg==

[Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #1579 - 4 msgs

[Tom E. <ro...@te...>]

Hi,

> > > If not possible you may have to purge the WikiDB cache, yes.
> > How would I do that with file DB ?
> As with any other DB backend.
> Login as Administrator.
> At the PhpWikiAdministration page is button called "Purge Cache".

That assumes I can login, however I receive the error for any and 
every page, including the very first one ;-)

I was looking for something like rm `find . -name something`...

Any ideas ?

Thanks, Tom.

Re: [Phpwiki-talk] PHPWiki Install Nightmare

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

2005/12/29, GrasshopperQ <sl...@gm...>:
> I have been having exactly NO luck installing PHPWiki on any web server.
>
> I keep getting the following message(s) when I first open index.php....
>
> Warning: Failed opening 'lib/setupwiki.php' for inclusion
> (include_path=3D'..') in
> C:\Adam\WebSite\public_html\Martial\PHPWiki\lib\display.php
> on line 21
>
> What could be causing this?

Which version of 1.2.x are you using?
I believe it must be an old phpwiki 1.2.x version with php register_globals=
=3Doff

> I've double-checked server and database information.  I did notice that
> hitcount.hits is being incremented with each attempt at loading.  But it
> fails on the above error.

Re: [Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #1578 - 2 msgs

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

2005/12/29, Tom Eicher <ro...@te...>:
> > > Fatal error: Call to undefined function: zipreader() in
> > > /export/home/wiki/phpwiki-1.3.11rc3/lib/CachedMarkup.php on line 61
> > This caught a yet undetected error in the gzip workaround.
> > "new " ZipReader is missing there.
>
> Any quick manual patch for me to fix this ?

Sorry, no.
I can only think of a mnaul zip workaround, but no gzip workaround yet.

> > Looks like your php has no gzip support (zlib) anymore.
> > This is bad. I don't know if SUSE allows php_zlib to be dlopened
> > dynamicall=3D y.
>
> But it was there before. I force-reinstalled all "*zlib*" packages
> but that did not help.
>
> > Not needed if you find the proper php-zlib.so
>
> It's all there, but cannot be found anymore (with identical
> settings, it seems...). Yuck.
>
> > If not possible you may have to purge the WikiDB cache, yes.
>
> How would I do that with file DB ?

As with any other DB backend.
Login as Administrator.
At the PhpWikiAdministration page is button called "Purge Cache".

[Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #1578 - 2 msgs

[Tom E. <ro...@te...>]

Hello,

> > Fatal error: Call to undefined function: zipreader() in
> > /export/home/wiki/phpwiki-1.3.11rc3/lib/CachedMarkup.php on line 61
> This caught a yet undetected error in the gzip workaround.
> "new " ZipReader is missing there.

Any quick manual patch for me to fix this ?

> Looks like your php has no gzip support (zlib) anymore.
> This is bad. I don't know if SUSE allows php_zlib to be dlopened
> dynamicall= y.

But it was there before. I force-reinstalled all "*zlib*" packages
but that did not help. 

> Not needed if you find the proper php-zlib.so

It's all there, but cannot be found anymore (with identical
settings, it seems...). Yuck.

> If not possible you may have to purge the WikiDB cache, yes.

How would I do that with file DB ?

Thanks, Tom.

[Phpwiki-talk] PHPWiki Install Nightmare

[GrasshopperQ <sl...@gm...>]

I have been having exactly NO luck installing PHPWiki on any web server.

I keep getting the following message(s) when I first open index.php....

*Warning*: Failed opening 'lib/setupwiki.php' for inclusion
(include_path=3D'..') in *
C:\Adam\WebSite\public_html\Martial\PHPWiki\lib\display.php* on line *21*
*
*What could be causing this?

I've double-checked server and database information.  I did notice that
hitcount.hits is being incremented with each attempt at loading.  But it
fails on the above error.

Any help you could provide would be most appreciated.

Thanks!

--
GQ
"...into the Shadow with teeth bared..."

Re: [Phpwiki-talk] undefined function: zipreader()

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

2005/12/27, Tom Eicher <ro...@te...>:
>
> Hello,
> due to instability of SuSE 10.0 on my hardware, I had
> to step back to my SuSE 9.2 installation, which I had
> preserved on a separate partition.
>
> This old installation used to run phpwiki 1.3.11rc3
> successfully for some time, however after stepping
> back I get the following error for every page:
>
> Fatal error: Call to undefined function: zipreader() in
> /export/home/wiki/phpwiki-1.3.11rc3/lib/CachedMarkup.php on line 61

Thanks!
This caught a yet undetected error in the gzip workaround.
"new " ZipReader is missing there.

> Maybe the new Linux (with newer PHP or libs or anything) running
> the very same phpwiki installation (in the same directory)
> created some zipped files that the old one cannot read ?

Looks like your php has no gzip support (zlib) anymore.
This is bad. I don't know if SUSE allows php_zlib to be dlopened dynamicall=
y.

FYI,
If gzuncompress() is not found, our own ziplib functions will be used.
phpwiki is independent of php-zip (ZZIPlib).

> Should I / How can I delete the cache ? I am running
> "file" DB.

Not needed if you find the proper php-zlib.so
If not possible you may have to purge the WikiDB cache, yes.

--
Reini