Menu
▾
▴
phpwiki-talk
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(103) |
Jul
(105) |
Aug
(16) |
Sep
(16) |
Oct
(78) |
Nov
(36) |
Dec
(58) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(100) |
Feb
(155) |
Mar
(84) |
Apr
(33) |
May
(22) |
Jun
(77) |
Jul
(36) |
Aug
(37) |
Sep
(183) |
Oct
(74) |
Nov
(235) |
Dec
(165) |
| 2002 |
Jan
(187) |
Feb
(183) |
Mar
(52) |
Apr
(10) |
May
(15) |
Jun
(19) |
Jul
(43) |
Aug
(90) |
Sep
(144) |
Oct
(144) |
Nov
(171) |
Dec
(78) |
| 2003 |
Jan
(113) |
Feb
(99) |
Mar
(80) |
Apr
(44) |
May
(35) |
Jun
(32) |
Jul
(34) |
Aug
(34) |
Sep
(30) |
Oct
(57) |
Nov
(97) |
Dec
(139) |
| 2004 |
Jan
(132) |
Feb
(223) |
Mar
(300) |
Apr
(221) |
May
(171) |
Jun
(286) |
Jul
(188) |
Aug
(107) |
Sep
(97) |
Oct
(106) |
Nov
(139) |
Dec
(125) |
| 2005 |
Jan
(200) |
Feb
(116) |
Mar
(68) |
Apr
(158) |
May
(70) |
Jun
(80) |
Jul
(55) |
Aug
(52) |
Sep
(92) |
Oct
(141) |
Nov
(86) |
Dec
(41) |
| 2006 |
Jan
(35) |
Feb
(62) |
Mar
(59) |
Apr
(52) |
May
(51) |
Jun
(61) |
Jul
(30) |
Aug
(36) |
Sep
(12) |
Oct
(4) |
Nov
(22) |
Dec
(34) |
| 2007 |
Jan
(49) |
Feb
(19) |
Mar
(37) |
Apr
(16) |
May
(9) |
Jun
(38) |
Jul
(17) |
Aug
(31) |
Sep
(16) |
Oct
(34) |
Nov
(4) |
Dec
(8) |
| 2008 |
Jan
(8) |
Feb
(16) |
Mar
(14) |
Apr
(6) |
May
(4) |
Jun
(5) |
Jul
(9) |
Aug
(36) |
Sep
(6) |
Oct
(3) |
Nov
(3) |
Dec
(3) |
| 2009 |
Jan
(14) |
Feb
(2) |
Mar
(7) |
Apr
(16) |
May
(2) |
Jun
(10) |
Jul
(1) |
Aug
(10) |
Sep
(11) |
Oct
(4) |
Nov
(2) |
Dec
|
| 2010 |
Jan
(1) |
Feb
|
Mar
(13) |
Apr
(11) |
May
(18) |
Jun
(44) |
Jul
(7) |
Aug
(2) |
Sep
(14) |
Oct
|
Nov
(6) |
Dec
|
| 2011 |
Jan
(2) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(11) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(1) |
| 2015 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2016 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
(11) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joaquin A. M. <ja...@re...> - 2004-01-20 16:59:26
|
I have installed: Postnuke 0.726 (Phoenix) MySql 4.0.17 Php 4.3.4 Windows 2000 Server Apache 2.0.48 I have downloaded a module Phpwiki for Postnuke from = http://stuff.kling.nu I have made the instructions, but when from Administration Menu Phpwiki = type the path for PEAR, I get a error that says: Failed to load module phpWiki ( At function: "view" ) When I make click on phpwiki at Main Menu, I get a white screen. I don't = see anything. Thanks a lot |
|
From: Dan R. <dr...@th...> - 2004-01-20 15:32:59
|
On Mon, Jan 19, 2004 at 07:13:37PM -0600, Dan Rue wrote: > Hi, > > I'm trying to get an install of 1.3.7 going on at a hosting facility > (1and1.com). I have set up 1.3.7 numerous times on my own servers, but > I am having a pesky problem with 1and1.com's setup. They are using > standard linux/apache/mysql/php (LAMP). In fact, I can get 1.2.2 running > without a hitch. > > After setting up all the config stuff, I go to the page and it loads the > default pages from pgsrc just fine. But, when I click or refresh to go > to my new homepage, it comes up blank. If I view source, I just see > <html><body></body></html>. No error messages. > > I have scoured the code trying to find the silent error. Any > troubleshooting tips? I know that it's connecting fine to the DB > backend (which is on a seperate server, btw), because I see that the DB > gets populated. Any hints/suggestions much appreciated, > dan Solved - Thanks to a suggestion in the forums, I set the compress output line in index.php to false: define('COMPRESS_OUTPUT', false); Still not sure what the deal was, but happy to be up and running again. Dan |
|
From: Alec T. <li...@sw...> - 2004-01-20 11:38:31
|
Hi Dan, On Mon, Jan 19, 2004 at 07:13:37PM -0600, Dan Rue wrote: > After setting up all the config stuff, I go to the page and it loads the > default pages from pgsrc just fine. But, when I click or refresh to go > to my new homepage, it comes up blank. If I view source, I just see > <html><body></body></html>. No error messages. I can't help you with what is causing your error without more information, but the source you see is generated by Mozilla as a result of a dud response from the server. More than likely, you will see the actual error in your web servers error logs. Alec -- Evolution: Taking care of those too stupid to take care of themselves. |
|
From: Bob A. <apt...@cy...> - 2004-01-20 02:16:10
|
Hi, I'm moving my wiki from one machine to another and two problems arise when restoring straight from a wikidb.dump. First, I don't want to overwrite parts of the new (empty) wiki, especially the admin pages, documentation, etc. Second, restoring from the wiki dump only pulls in the first version of each page, leaving the most recent revisions to be imported manually -- very bad. I have 541 unique pages, many with multiple versions, and manually clicking "merge edit" or "restore anyway" for the most recent versions of the pages is wholly unmanagable. Basically, I want all versions of my original, locally-produced content pulled into the new wiki without a lot of manual editing and I don't want to break any of the new generic infrastructure by importing archiac docs, admin pages, etc. If I could do that, the only piece of manual administration is making minor edits to the home page. Any suggestions on how to gracefully upgrade without a lot of clicking, losing history, or breaking all the new generic pages? -- Bob |
|
From: Dan R. <dr...@th...> - 2004-01-20 00:09:04
|
Hi, I'm trying to get an install of 1.3.7 going on at a hosting facility (1and1.com). I have set up 1.3.7 numerous times on my own servers, but I am having a pesky problem with 1and1.com's setup. They are using standard linux/apache/mysql/php (LAMP). In fact, I can get 1.2.2 running without a hitch. After setting up all the config stuff, I go to the page and it loads the default pages from pgsrc just fine. But, when I click or refresh to go to my new homepage, it comes up blank. If I view source, I just see <html><body></body></html>. No error messages. I have scoured the code trying to find the silent error. Any troubleshooting tips? I know that it's connecting fine to the DB backend (which is on a seperate server, btw), because I see that the DB gets populated. Any hints/suggestions much appreciated, dan |
|
From: bishop <bi...@pl...> - 2004-01-19 17:54:26
|
Folks, I'm running a tiny wiki, right now mainly used to quickly record and edit some doc as I ramp up into a new group at work. For some odd reason, when I click https://site/wiki/bishop/work/buildpi/ccase/bestPractice?action=create , it takes me to https://www.platypus.bc.ca/wiki/bishop/work/buildpi/ccase/bishop/work/buildpi/ccase/bestPractice to describe the page. Notice, in the link above, that the '/bishop/work/buildpi' part is doubled. Drop that shorter URL into your own wiki, and see if the page it wants you to edit has the longer name? I swear the link in the referring page looks tip-top. Anyone seen anything like this? Also, I haven't yet found a facility for moving a page about yet. You know, a renamer that moves a page label (refusing if the destination label already has a page) and also alters all referring pages. While such a tool would be no good for outsiders linking in (maybe it puts a redirect/notice page in there?), it would make the odd movement of pages a bit better. - bish perplexed -- At one time it was rare to find US citizens, in the safest and most prosperous country in the world, jumping at their own shadows. Now we only note how high. -- Andrew Orlowski http://www.theregister.co.uk/content/28/34776.html |
|
From: Alec T. <li...@sw...> - 2004-01-19 11:52:12
|
Hello, I have written a couple of plugins for PhpWiki, is there somewhere I can contribute them? The plugins are SyntaxHighlighter which, as you might suspect, syntax highlights blocks of code. The second plugin is DirectoryIndex, which generates hyperlinks to a list of files in a directory on the server. Useful for a download list, or whatever. The code for both of these is available at http://swapoff.org/Projects. You can also see examples of their use. Regards, Alec -- Evolution: Taking care of those too stupid to take care of themselves. |
|
From: Robert D. <rob...@ya...> - 2004-01-18 04:25:03
|
Hello Reini, Thanks very much for your comments. You wrote in part: -------- begin quotation -------- the current version supports: internal auth: ALLOW_BOGO_LOGIN and REQUIRE_SIGNIN_BEFORE_EDIT external auth: LDAP, IMAP REQUIRE_SIGNIN_BEFORE_EDIT stores the password either in the cookie or the metadata of the users homepage. (if it exists) ALLOW_BOGO_LOGIN asks for no password, it just requires that the username is valid wikiword. then access is granted. --------- end quotation --------- What I don't understand here, is how the passwords are assigned for REQUIRE_SIGNIN_BEFORE_EDIT. That password which is stored in a cookie or metadata -- where did it comes from? It seems that to get nontrivial authentication it is necessary to set ALLOW_BOGO_LOGIN to "false". Otherwise, anyone can log in with no password, which seems to defeat the purpose of REQUIRE_SIGNIN_BEFORE_EDIT. Thanks again for your help. I appreciate it very much! Robert Dodier __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Doyce T. <sm...@av...> - 2004-01-17 20:59:58
|
Okay, I'm going to be particularly slow about this.
If I were going to use this line:
ini_set("max_execution_time",240);
which my host assures me I have the clearance to set... where would I
put it? I'm assuming in the index.php in my wiki directory, but where?
Addendum to this. My host tells me that I can set these settings simply
by including lines in my .htaccess directory, the format being:
php_value (phpvalue)=(parameter)
So, for example, to change the max_execution_time to 240, you would add the line:
php_value max_execution_time=240
Except, when I add this to my .htaccess file, the whole site (not just
the phpwiki, but the WHOLE site) switches to a 500 Internal Server
Error. Anyone familiar enough with .htaccess to know what I'm doing wrong?
Reini Urban wrote:
> Joby Walker schrieb:
>
>> http://us2.php.net/manual/en/function.ini-set.php
>>
>> I have:
>>
>> max_execution_time = 300
>> max_input_time = 60
>> memory_limit = 16M
>>
>> The 300s max_execution_time is a bit high, but I have some other
>> administrative webapplications that take a long time.
>
>
> only for such pages I override it explicitly with
> ini_set("max_execution_time",240);
>
> (download, upload and other similar stuff)
>
> for the normal pages it's a pain to wait longer than ~8 seconds on any
> error.
--
Doyce Testerman ~ sm...@av... ~ www.average-bear.com
"Teenagers these days are out of control, they eat like pigs, they are disrespectful of adults, they interrupt and contradict their parents, and they terrorize their teachers" -Aristotle
|
|
From: Reini U. <ru...@x-...> - 2004-01-17 15:29:37
|
Robert Dodier schrieb: > I have another security-related question. This mailing list > doesn't appear to be archived, and reading through the FAQ, > change log, and index.php, I wasn't able to resolve this > question, so here it is. > > How does one set up PhpWiki internal authentication? > (Assuming that there is such a thing.) > > I've tried some permutations of the settings in index.php -- > specifically ALLOW_USER_LOGIN, ALLOW_BOGO_LOGIN, and > REQUIRE_SIGNIN_BEFORE_EDIT. It seems that setting these to > true, false, and true, respectively, would invoke authentication. > But how are usernames and passwords assigned? I don't see > a "Create User" or whatever on the wiki administration page. > > Can username/password pairs be created by some MySQL commands? > There are some comments about that in index.php, but they > seem to apply specifically to IMAP authentication. the code in index.php relates to the upcoming auth code which is currently rewritten. the current version supports: internal auth: ALLOW_BOGO_LOGIN and REQUIRE_SIGNIN_BEFORE_EDIT external auth: LDAP, IMAP REQUIRE_SIGNIN_BEFORE_EDIT stores the password either in the cookie or the metadata of the users homepage. (if it exists) ALLOW_BOGO_LOGIN asks for no password, it just requires that the username is valid wikiword. then access is granted. the upcoming release will supports more external auth and preferences: http auth, database, files. > I'm trying to figure out a simple scheme for assigning > usernames and passwords. Any advice that you might have is > greatly appreciated. PhpWiki rocks! Thanks for creating > such a great project. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Reini U. <ru...@x-...> - 2004-01-17 15:23:42
|
Robert Dodier schrieb: > I have another question about security. Have there been any known > attacks against PhpWiki wikis? Excluding vandalism of pages. Has > it ever happened that someone successfully obtained a database > password and (1) really messed up the wiki -- e.g., in such a way > that it couldn't be reloaded from an archive, or > (2) got access to stuff other than the wiki content? the sceptical party is wrong. 1) I know of no phpwiki abuse so far, but other wikis had been reportedly abused. but not massively and not that they couldn't be restored from the daily database backup. the typical wiki abuse is not via the db directly (db password and host security abuse), it is done by writing a short script which does the necessary POST requests to the system. it makes no sense and is typically deleted by the next visitor or by the admin, whoever detects first. we have no such robot detection code yet included, because then we have to analyse the sessions, store the visitor IP and timestamp. but I once had some code to prevent from abusive robots, which got caught in a loop. now it is not needed anymore. ward's wiki has such code included, which was needed then. 2) not to my knowledge. but every system intruder has access to everything else than the wiki content. and there are dozens of intrusions worldwide per day. > Sorry to ask so many questions -- I am trying to convince a > skeptical third party that it's safe to run PhpWiki. Thanks for > your help. I appreciate it very much. the sceptical party is right. it's not safe to run phpwiki such it is not safe to run any service which is accessible to the world, such as a webserver, fileserver or mail server. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
|
From: Ben J. <be...@ea...> - 2004-01-17 02:42:58
|
I am in the process of moving my site from one host to another. Both servers are running FreeBSD 4.x and MySQL 3.x. After importing the MySQL data and all the files for phpWiki, I load the page. At the top of the page I get a long list of errors (see below), but underneath the errors it does render the homepage. Have I set something up wrong? The only difference I can see between the two hosts is that the new one has MySQL on a different server than my home directory, whereas the old one was on the localhost. Thanks, Ben. ---- The errors: Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php on line 1096 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php on line 1097 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of explodelist(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php on line 1114 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/WikiUser.php on line 335 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/WikiUser.php on line 353 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/WikiUser.php on line 362 Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in /usr/www/users/bjudson/wiki.eatworms/lib/WikiUser.php on line 372 lib/Request.php:240: Warning[2]: session_start(): Cannot send session cookie - headers already sent by (output started at /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php:1096) lib/Request.php:240: Warning[2]: session_start(): Cannot send session cache limiter - headers already sent (output started at /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php:1096) lib/display.php:135: Warning[2]: Cannot modify header information - headers already sent by (output started at /usr/www/users/bjudson/wiki.eatworms/lib/stdlib.php:1096) -- eatworms.org // burn the lines of the city // |
|
From: Zot O'C. <zo...@wh...> - 2004-01-17 00:55:25
|
On Fri, 2004-01-16 at 12:34, Robert Dodier wrote: > Hello again, > > I have another question about security. Have there been any known > attacks against PhpWiki wikis? Excluding vandalism of pages. Has > it ever happened that someone successfully obtained a database > password and (1) really messed up the wiki -- e.g., in such a way > that it couldn't be reloaded from an archive, or I have not heard of this. > (2) got access to stuff other than the wiki content? > 2 easy ways to prevent this: 1) Run this on a web site with a user and group that is different than the norm. Have a wikiuser and wikigroup. Put apache in the wiki group. Then use flatfiles (gdbm). The most that can happen is the files is trashed/removed. 2) Do that anyway, but when creating the tables create them as wikidba and grant permissions to wikiwebuser. Never use these these users for anything else. The most that can happen, happen to the wikiwebuser accessible data. All the rest of your tables are owned by non-owner web users, right? If not tell the concerned party to stop looking for trouble, you've already found it! > Sorry to ask so many questions -- I am trying to convince a > skeptical third party that it's safe to run PhpWiki. Thanks for > your help. I appreciate it very much. Ask them what their worry is, then find it on their stuff..... If they are non-technical, do not suffer the arguments very long, it is not worth it. People who are paranoid, are, well paranoid. -- Zot O'Connor http://www.ZotConsulting.com http://www.WhiteKnightHackers.com |
|
From: Robert D. <rob...@ya...> - 2004-01-16 20:35:05
|
Hello again, I have another question about security. Have there been any known attacks against PhpWiki wikis? Excluding vandalism of pages. Has it ever happened that someone successfully obtained a database password and (1) really messed up the wiki -- e.g., in such a way that it couldn't be reloaded from an archive, or (2) got access to stuff other than the wiki content? Sorry to ask so many questions -- I am trying to convince a skeptical third party that it's safe to run PhpWiki. Thanks for your help. I appreciate it very much. Robert Dodier __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: Robert D. <rob...@ya...> - 2004-01-16 20:12:34
|
Hello, I have another security-related question. This mailing list doesn't appear to be archived, and reading through the FAQ, change log, and index.php, I wasn't able to resolve this question, so here it is. How does one set up PhpWiki internal authentication? (Assuming that there is such a thing.) I've tried some permutations of the settings in index.php -- specifically ALLOW_USER_LOGIN, ALLOW_BOGO_LOGIN, and REQUIRE_SIGNIN_BEFORE_EDIT. It seems that setting these to true, false, and true, respectively, would invoke authentication. But how are usernames and passwords assigned? I don't see a "Create User" or whatever on the wiki administration page. Can username/password pairs be created by some MySQL commands? There are some comments about that in index.php, but they seem to apply specifically to IMAP authentication. I'm trying to figure out a simple scheme for assigning usernames and passwords. Any advice that you might have is greatly appreciated. PhpWiki rocks! Thanks for creating such a great project. Robert Dodier __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
|
From: John C. <joh...@ua...> - 2004-01-16 16:10:50
|
I was looking for a way to put plugin's into a table (which would be a nice feature btw) and ran across the RichTable plugin http://phpwiki.sourceforge.net/phpwiki/RichTablePlugin <http://phpwiki.sourceforge.net/phpwiki/RichTablePlugin> . Looks great, but there is a problem with the TransformText function in BlockParser.php in the cvs version where it will not parse plugins and wiki words at all. If you load the RichTable plugin and use the sample code on the cvs phpwiki http://www.it.iitb.ac.in/~sameerds/phpwiki/index.php/RichTablePlugin <http://www.it.iitb.ac.in/~sameerds/phpwiki/index.php/RichTablePlugin> , you will see that the plugin and the links don't work, but the image and the lists do. You can also see from the demo site that the plugin does work on previous versions. This would be a very nice plugin to have working correctly again. Thanks, John Cole ------------------------------------- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. |
|
From: Stanislaw B. <sb...@po...> - 2004-01-15 21:48:29
|
When opening the PhpWiki page for the first time with Mozilla 1.2.1, the
following problem is reported at the top of the page by Wiki (IE shows
only erro message-see below):
<div class="error"><p>lib/Request.php:136: Warning[2]: ob_start():
output handler 'ob_gzhandler' cannot be used after 'URL-Rewriter'</p>
</div>
Here's what I have found on Google:
Error: "ob_start(): output handler 'ob_gzhandler' cannot be used after
'URL-Rewriter'"
Reason: You call ob_start('ob_gzhandler'); after session_start hs been
called and trans_sid is used.
Solution: Call ob_start('ob_gzhandler'); before session_start().
I have no idea how to apply this "advice". I don't know PHP and also it
might be more a configuration problem rather than a code bug. Please, help.
IE: 6.0 on WinME
OS: Red Hat Linux
PHP: 4.3.4
MySQL: 4.0.15-stand
PhpWiki: 1.3.4
If I use IE 6.0 instead of Mozilla, the message is even more cryptic:
>>> Error reported by IE:
The XML page cannot be displayed
Cannot view XML input using XSL style sheet. Please correct the error
and then click the Refresh button, or try again later.
--------------------------------------------------------------------------------
Cannot have a DOCTYPE declaration outside of a prolog. Error processing
resource 'http://www.saintclarechurch.org/phpwiki/index.php'. Line 4,
Position 11
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
----------^
>>> End Error
|
|
From: Ricardo G. <ax...@uk...> - 2004-01-15 14:06:46
|
Hi All, This is my first contribution to phpwiki. I've devised a useful and interesting new plugin called CollatePages. It takes an index page - a list of links to other pages - and collates them into one large page. It's very useful for compiling many wiki articles into a larger document so you can copy-and-paste it into a word processor. I have no idea how to submit this to the phpwiki project so I'm sending it here. I've also been working on a TextBox plugin. I'm having some trouble getting TextBox to parse the text within through the wiki text parser. Any ideas? TIA... -- Ricardo Gladwell President, Free Roleplaying Community http://www.freeroleplay.org/ pre...@fr... |
|
From: <plu...@ya...> - 2004-01-14 12:02:37
|
<ÆÒ><MÒ> CtT|[g óMÛ·éêÍ»Ì|ð k9...@ya... ÜÅB ¨æèîñðMû¾¯ÉB ®S³¿Å¨Í¯µÜ·I ¶üãÉð§ÂàeªMbVÅ·I ¡·®±¿ç𲺳¢B http://www.interq.or.jp/wild/yorutomo/ ¨lÑBFlÌAhXÍsÌÌ\tgðpµ ûW³¹Ä¸«Üµ½BOÌûÉzM³ê½êͨµº³¢B |
|
From: Sascha C. <sc...@it...> - 2004-01-14 06:38:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, and a happy new year. Today I discovered the WikiBlog plugin, but unfortunatly I cannot get it to work the way it's supposed to be. I've included the plugin in a page of my wiki. Then I can add blog entries, no problems here. But when I try to edit an entry, phpwiki somehow redirects me to Homepage. URL's are: Page with Plugin: http://www.iuw-darmstadt.de/wiki/index.php/SaschaCarlin After click on edit: http://www.iuw-darmstadt.de/wiki/index.php/SaschaCarlin/Blog/2004-01-14/07%3A31%3A40%2B01%3A00?action=edit This last URL brings me to an edit view of HomePage. Any hints are welcome ;-) PS: WikiBlog.php is version $Id: WikiBlog.php,v 1.7 2003/11/17 16:23:55 carstenklapp Exp $ - that should be latest. Regards, Sascha - -- Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt http://www.itst.org/ ** http://wwworker.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFABOPtYZjV7qYA+LARAlRTAJ4i/0gqcVMweAXEI3Uvm1y/WLWtQwCfW1Za vLSN2Hdt6LKDCWLoelEaMkc= =7p/8 -----END PGP SIGNATURE----- |
|
From: Roy L. <rl...@bi...> - 2004-01-14 04:59:37
|
Hi, I noticed that passencrypt.php had a few bugs. I've fixed it and uploaded attached to bug report 875995 ( http://sourceforge.net/tracker/index.php?func=detail&aid=875995&group_id=6121&atid=106121 ). Recommended for inclusion into the CVS. -- KX |
|
From: Doyce T. <sm...@av...> - 2004-01-14 03:27:06
|
Hmm. I'm not seeing where you would set that. aphid wrote: > > On Jan 10, 2004, at 2:40 PM, Doyce Testerman wrote: > >> Okay, here's another hint: I almost always get these assertion >> errors when I try to save, view Diffs, or Page history on larger >> pages -- smaller pages almost always work -- is there some time limit >> I'm running into? >> > I ran into this problem on OS X.. it only happened using the old > markup system. I changed my interface to not give people the option > of using old markup and it went away. > > A > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > -- Doyce Testerman ~ sm...@av... ~ www.average-bear.com Eagles may soar, but weasels don't get sucked into jet engines. |
|
From: aphid <sp...@ap...> - 2004-01-14 02:47:11
|
On Jan 10, 2004, at 2:40 PM, Doyce Testerman wrote: > Okay, here's another hint: I almost always get these assertion errors > when I try to save, view Diffs, or Page history on larger pages -- > smaller pages almost always work -- is there some time limit I'm > running into? > I ran into this problem on OS X.. it only happened using the old markup system. I changed my interface to not give people the option of using old markup and it went away. A |
|
From: Rodney K. <ro...@rm...> - 2004-01-13 20:47:45
|
Whenever I edit the Homepage for my PhpWiki installation, I get the following error: lib/WikiDB.php:787: Fatal[0]: <br />/home/rmaia/public_html/phpwiki/lib/WikiDB.php:787: : Assertion failed <br /> What can be causing this problem? I have not received this error on any other pages yet. PhpWiki is set up using the flat file system, and is running on SUSE 9.0. |
|
From: Reini U. <ru...@x-...> - 2004-01-13 11:18:40
|
Joby Walker schrieb: > http://us2.php.net/manual/en/function.ini-set.php > > I have: > > max_execution_time = 300 > max_input_time = 60 > memory_limit = 16M > > The 300s max_execution_time is a bit high, but I have some other > administrative webapplications that take a long time. only for such pages I override it explicitly with ini_set("max_execution_time",240); (download, upload and other similar stuff) for the normal pages it's a pain to wait longer than ~8 seconds on any error. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
207 messages has been excluded from this view by a project administrator.
