Menu
▾
▴
phpwiki-bugs — bug reports for PhpWiki
You can subscribe to this list here.
| 2002 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(14) |
Dec
(5) |
| 2004 |
Jan
(11) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(7) |
Aug
(2) |
Sep
(9) |
Oct
(10) |
Nov
(24) |
Dec
(31) |
| 2009 |
Jan
(12) |
Feb
(10) |
Mar
(16) |
Apr
(15) |
May
(34) |
Jun
(19) |
Jul
(30) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
(14) |
| 2010 |
Jan
(5) |
Feb
(6) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <in...@sh...> - 2005-07-22 20:02:29
|
Hello, with Cookies disabled the Problem came up in the German language version where the austrian "Sandkiste" is redirected to "Sandkasten" and the testuser was kicked every time he wanted to enter the sandbox. I just changed the link so it doesn't matter me. Same thing with the search-field, the FindPage and LikePage-Buttons are OK but if I just press the Enter-Key after filling the field the Session-ID gets lost. ALLOW_ANON_USER = false ALLOW_ANON_EDIT = false ALLOW_BOGO_LOGIN = false ALLOW_USER_PASSWORDS = true MySQL ... Also at least MacOSX-Theme-Problems occurs. When using Session-IDs at least the german "signed in as '...' and the 'Sign out'-Button are not displayed by Opera 7.54 and Firefox 1.0 /Win2k Furthermore at least under Opera 7.54/Win2k saving from editing a site isn't possible. The Save-Button doesn't work at all and the Save-Icon ignores saving. Just in Case you didn't know. Kind Regards Guido |
|
From: <har...@gm...> - 2005-01-29 16:26:57
|
Hello! I have a problem with my new wiki, something goes wrong with the mysql database. I dont found this error in the bug-lists. I think the error is in the database_dsn in the config.ini, but i dont can find it, does anyone now what is going wrong? DATABASE_TYPE = sql mysql://user:password@host/databasename thanks Harald |
|
From: <JEB...@ao...> - 2004-12-09 12:22:43
|
One of the people who contributes to my wiki has inexplicably lost the ability to log in under his original user name. Instead, whenever he (and I) tries, it keeps redirecting him to the unmade page "500.shtml". Can anyone help? -James Bowman http://moa.dracandros.com/ PS- I'm not subscribed to the list, so I would appreciate being CC'd on any responses. |
|
From: <xi...@ni...> - 2004-09-21 13:43:59
|
Hi folks, today I received the following error: Fatal PhpWiki Error lib/WikiDB.php:973: Fatal[0]: <br />/var/www/projectdirs/wiki/lib/WikiDB.php:973: : Assertion failed <br /> I get this message when I try to look at pagehistory or diff. What is the problem? This is phpWiki 1.3.10 Thanks, Krisztian |
|
From: Stefan W. <st...@we...> - 2004-06-13 11:49:26
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, The Arianne project wiki (http://arianne.sourceforge.net/wiki) has the problem of sometimes displaying an empty page. Reloading can fix this. Miguel has posted this problem here: http://sourceforge.net/tracker/?func=detail&atid=106121&aid=960786&group_id=6121 We at the PearPC.sf.net project have the same problems with phpWiki. The whole thing seems to be sourceforge.net related. What can we do? Regards, Stefan You can reproduce the problem quite reliably like this: $ telnet arianne.sf.net 80 Trying 66.35.250.209... Connected to arianne.sf.net. Escape character is '^]'. GET /wiki/ HTTP/1.0 Host:arianne.sourceforge.net Connection closed by foreign host. $ telnet arianne.sf.net 80 Trying 66.35.250.209... Connected to arianne.sf.net. Escape character is '^]'. GET / HTTP/1.0 Host:arianne.sourceforge.net HTTP/1.1 200 OK Date: Sun, 13 Jun 2004 11:47:12 GMT Server: Apache/1.3.26 (Unix) PHP/4.1.2 X-Powered-By: PHP/4.1.2 Connection: close Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <...... and so on> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAzD9qqmw8PkQ6cTQRAnC3AJ4x3JRkEQICKg9N2DfUU2/9PuwyhgCeKLWC Ilp2B3p0i1OonwXv/YNLk4I= =Vs4X -----END PGP SIGNATURE----- |
|
From: SourceForge.net <no...@so...> - 2004-06-08 19:53:03
|
Bugs item #969169, was opened at 2004-06-08 12:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=969169&group_id=6121 Category: MySQL Group: User Authentication Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: DBAUTH_AUTH_(CREATE, USER_EXISTS) default values Initial Comment: I'm using an external MySQL for user authentication. I want all users register from another application and make phpwiki an add-on to that program. I got some error messages complaining not able to find specific tables in my external MySQL. Later I realized it's pre-defined config-default.ini but in config.ini it isn't clear whether we should unset some default values. I suggest add after line 539 (config-dist.ini): DBAUTH_AUTH_USER_EXISTS = "SELECT username FROM users WHERE username='$userid'" to remind insaller to properly set it, even if they don't use Unix crypt(). For those who don't want new users to register through phpWiki, either comment out config-default.ini line 66: DBAUTH_AUTH_CREATE = "INSERT INTO user SET passwd=PASSWORD('$password'),userid='$userid'" or add the following line in config.ini to unset the value line 557 DBAUTH_AUTH_CREATE = "" (maybe there is an UNSET function in php but I don't know). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=969169&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-08 19:41:02
|
Bugs item #969156, was opened at 2004-06-08 12:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=969156&group_id=6121 Category: MySQL Group: User Authentication Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: DBAUTH_AUTH_(CREATE, USER_EXISTS) default values Initial Comment: I'm using an external MySQL for user authentication. I want all users register from another application and make phpwiki an add-on to that program. I got some error messages complaining not able to find specific tables in my external MySQL. Later I realized it's pre-defined config-default.ini but in config.ini it isn't clear whether we should unset some default values. I suggest add after line 539 (config-dist.ini): DBAUTH_AUTH_USER_EXISTS = "SELECT username FROM users WHERE username='$userid'" to remind insaller to properly set it, even if they don't use Unix crypt(). For those who don't want new users to register through phpWiki, either comment out config-default.ini line 66: DBAUTH_AUTH_CREATE = "INSERT INTO user SET passwd=PASSWORD('$password'),userid='$userid'" or add the following line in config.ini to unset the value line 557 DBAUTH_AUTH_CREATE = "" (maybe there is an UNSET function in php but I don't know). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=969156&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-06 12:38:24
|
Bugs item #967582, was opened at 2004-06-06 14:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=967582&group_id=6121 Category: version 1.3.x (experimental) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reini Urban (rurban) Assigned to: Reini Urban (rurban) Summary: Various Mac IE problems Initial Comment: At a friends computer I tested 1.3.10 and the current 1.3.11pre on a Mac with Internet Explorer. Various serious problems encountered: * On Edit the Save and Preview buttons were non-functional. Edits wree not stored withotu any explanation. I suspect a wrong redirect. * edit_toolbar: the buttons appeared almost correctly (only the infobutton was garbled), but were non-functional. (besides the save and preview buttons which worked ok, different to the submit buttons below the textarea as described above. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=967582&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-05 16:06:14
|
Bugs item #967150, was opened at 2004-06-05 09:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=967150&group_id=6121 Category: version 1.3.x (experimental) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dot* pagename problem Initial Comment: Hi, I encountered the following problem: If a pagename starts with a dot, a different page permissions are probably used. It ends with calling a member method on a non-object. More precisely, the problem is in the file PagePerm.php at lines 216 and 411 (we use version 1.3.9). I've tried this on your wiki too (not a good idea?..i just wanted to know whether it is only our problem or not..:-(..sorry) and it now shows an error message for example on the RecentChanges page. Peter (om...@ce...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=967150&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 23:08:38
|
Bugs item #966861, was opened at 2004-06-05 01:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966861&group_id=6121 Category: version 1.3.x (experimental) Group: Database Status: Open Resolution: None Priority: 5 Submitted By: Jonas Björnerstedt (nejb) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect sql field name in config.ini Initial Comment: Line 539 in config-dist.ini in 1.3.10 is currently: ; DBAUTH_AUTH_CHECK = "SELECT password FROM user where userid='$userid'" It should probably be: ; DBAUTH_AUTH_CHECK = "SELECT PASSWORD(passwd) FROM user where userid='$userid'" There is no password field in the user table. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966861&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 22:59:45
|
Bugs item #966856, was opened at 2004-06-05 00:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966856&group_id=6121 Category: version 1.3.x (experimental) Group: Installation Status: Open Resolution: None Priority: 5 Submitted By: Jonas Björnerstedt (nejb) Assigned to: Nobody/Anonymous (nobody) Summary: [Enhancement] Separate install script Initial Comment: Installation would be much easier if installation was performed in a separate script. 1) I could not set User Authentication in config.ini on the initial install, as the authentication came before the installation. 2) With a separate install, it is easier to do repeated installs. 3) A separate install script is safer. Once ready, the script can be deleted. 4) The installation script could detect if the MySQL backend had been selected and run sources/mysql.sql. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966856&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 21:47:25
|
Bugs item #966830, was opened at 2004-06-04 23:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966830&group_id=6121 Category: version 1.3.x (experimental) Group: Installation Status: Open Resolution: None Priority: 5 Submitted By: Jonas Björnerstedt (nejb) Assigned to: Nobody/Anonymous (nobody) Summary: No default value for DEBUG level in config.ini Initial Comment: A fresh install of 1.3.10 results in a bunch of warnings that DEBUG is not set. Setting DEBUG=1 fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966830&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 21:44:13
|
Bugs item #966828, was opened at 2004-06-04 23:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966828&group_id=6121 Category: version 1.3.x (experimental) Group: Installation Status: Open Resolution: None Priority: 5 Submitted By: Jonas Björnerstedt (nejb) Assigned to: Nobody/Anonymous (nobody) Summary: Installation fails if DEFAULT_LANGUAGE set initially Initial Comment: The installation skips a bunch of plugins if the Swedish locale is set initially in 1.3.10. To get a proper install, I had to 1) install with the default locale. 2) change the config.ini 3) open the index.php again In step 3, phpwiki notifies that it skips a bunch of modules. Given step 1 however, the links are not broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966828&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 09:56:10
|
Bugs item #966398, was opened at 2004-06-04 11:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966398&group_id=6121 Category: MySQL Group: None Status: Open Resolution: None Priority: 5 Submitted By: Antonio Bonifati (abonifa) Assigned to: Nobody/Anonymous (nobody) Summary: title search doesn't work with the mysql backend Initial Comment: Using phpwiki 1.3.7 (but also 1.3.9) with MySQL 4.1.0-alpha I noticed that the title search doesn't work as expected. This is because field page.pagename is declared as VARCHAR BINARY and then the MySQL LOWER string function is used on it (please see function text_search in lib/WikiDB/backend/PearDB.php). I noticed that the LOWER() string passes a BINARY value unchanged instead of changing it to all lowercase! This way almost all the queries performed on a title search return an empty set! Here is a simple query that make me know LOWER has no effect on BINARY columns: $ mysql phpwiki ... mysql> SELECT LOWER(pagename) FROM page WHERE id=2; +-----------------+ | LOWER(pagename) | +-----------------+ | AddingPages | +-----------------+ ... As a quick fix I removed the BINARY attribute from page.pagename. Reading throughout the MySQL manual I discovered the difference between using BINARY or not: with BINARY the comparisons use the ASCII order of the machine where the MySQL server is running and are case-sensitive, without BINARY they are case-insensitive and use the current client charset (ISO-8859-1 Latin1 by default). I think this could be a MySQL rather than PhpWiki fault and I've posted a related bug report to MySQL developers. http://bugs.mysql.com/4001 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966398&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-06-04 04:53:29
|
Bugs item #966284, was opened at 2004-06-03 23:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966284&group_id=6121 Category: version 1.3.x (experimental) Group: Database Status: Open Resolution: None Priority: 5 Submitted By: Glen Davis (xa_glen) Assigned to: Nobody/Anonymous (nobody) Summary: lib/WikiDB.php:717: : Assertion failed Initial Comment: PhpWiki 1.3.10 MySQL database 3.23.46 PHP 4.3.6 Twice tonight I have had PhpWiki version 1.3.10 fail with the following error: lib/WikiDB.php (In template 'browse') (In template 'body') (In template 'html'):717: Fatal[0]: /lib/WikiDB.php:717: : Assertion failed This happened while logged on as the administrator and trying to rename an entry I had just created (i.e., one with no revisions). In both cases the entries were totally lost (they weren't under the old name or under the new name). In addition to whatever fix you find for this problem, may I suggest not deleting the old entry until the new entry is added to the database? PhpWiki is very useful software. Thanks for all the hard work! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=966284&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-02-17 11:35:48
|
Bugs item #898661, was opened at 2004-02-17 12:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=898661&group_id=6121 Category: DBM Group: PHP error Status: Open Resolution: None Priority: 5 Submitted By: M. Uli Kusterer (witness) Assigned to: Nobody/Anonymous (nobody) Summary: InsertPage for dba may generate wrong warnings Initial Comment: Hi, in dbalib.php, the InsertPage() function is missing two "@" signs to suppress warnings. Below is the fixed version: // Either insert or replace a key/value (a page) function InsertPage($dbi, $pagename, $pagehash) { $pagedata = PadSerializedData(serialize($pagehash)); if (!@dba_insert($pagename, $pagedata, $dbi['wiki'])) { if (!@dba_replace($pagename, $pagedata, $dbi['wiki'])) { ExitWiki("Error inserting page '$pagename'"); } } } If the two "@" signs aren't present, I get a warning whenever editing a page telling me that it couldn't replace the page. (but since, after that warning, it tries replacing the page and that succeeds, this warning is completely unnecessary). Oh yeah: This is with 1.2.2 (which is the last one marked as stable) Cheers, -- M. Uli Kusterer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=898661&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-02-15 12:51:16
|
Bugs item #897424, was opened at 2004-02-15 04:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=897424&group_id=6121 Category: version 1.3.x (experimental) Group: PHP error Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal error when 0 is only content of table field Initial Comment: When you create a table and the only content of a field is 0 (not more not less) then you'll get: Fatal error: Call to a member function on a non-object in /var/www/phpwiki/lib/BlockParser.php on line 633 Example of table: First Row First Collumn| First Row Second Collumn| text| 0| etc| etc| PHPWIKI_VERSION: 1.3.4 Apache/1.3.26 Server ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=897424&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-02-12 10:45:07
|
Bugs item #895617, was opened at 2004-02-12 02:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=895617&group_id=6121 Category: version 1.3.x (experimental) Group: Rendering Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: *Bold* doen't work Initial Comment: If there is a line that just says *Bold* this is rendered: <li>Bold* However if there is text after *bold* e.g. *Bold* some text Then the formatting is correct. __bold__ works fine though Submitted by Lawrence Staff (lo...@ma...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=895617&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-01-31 01:50:24
|
Bugs item #886839, was opened at 2004-01-29 01:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=886839&group_id=6121 Category: version 1.3.x (experimental) Group: Rendering Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tilde (~) character is incorrectly ellided from URLs Initial Comment: Found this on http://insue.com/linux/phpwiki/index.php? pagename=PCG-SRX51P%2FB&action=PageInfo It used to have links on it in the form http://host/~user/path/to/something. The '~user' was being turned into 'user' upon rendering - - both in the text of the URL and in the HREF. I've since edited this particular page to use %7E instead, but it led to broken links on the page. If you need more information, you can get me at roger- php...@di... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=886839&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-01-22 05:54:14
|
Bugs item #881949, was opened at 2004-01-22 16:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=881949&group_id=6121 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Palmer (matt_palmer) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete Italian translation Initial Comment: The search pages FullTextSearch and probably FuzzySearch have no Italian translation, which is a particular problem because the system points you at those non-existant pages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=881949&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-01-18 05:58:44
|
Bugs item #879158, was opened at 2004-01-17 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=879158&group_id=6121 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yaroslav Bulatov (yaroslavvb) Assigned to: Nobody/Anonymous (nobody) Summary: Different TitleSearch problem Initial Comment: In my case, when I do "TitleSearch", I'm taken to a generic (uncreated) page "Title" search instead of seeing results. In other words the following URL index.php/TitleSearch?s=main takes me to generic "TitleSearch" page, whereas ndex.php/FullTextSearch?s=main shows the results as it's supposed to. I tried the "define('USE_PATH_INFO', true);" fix, but it didn't work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=879158&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-01-16 11:32:51
|
Bugs item #878189, was opened at 2004-01-16 11:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=878189&group_id=6121 Category: version 1.3.x (experimental) Group: PHP error Status: Open Resolution: None Priority: 5 Submitted By: Fatman (fatman_uk) Assigned to: Nobody/Anonymous (nobody) Summary: Blank page with CGI Initial Comment: When I have PHP installed as the [Win32] CGI executable, PhpWiki returns a blank page containing the text "<html><body></body></html>". When I install the SAPI modules, the Wiki works fine. Problem is I need to install on a system with the CGI executable. How do I fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=878189&group_id=6121 |
|
From: Rodney K. <ro...@rm...> - 2004-01-13 20:59:29
|
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: SourceForge.net <no...@so...> - 2004-01-13 16:17:45
|
Bugs item #876180, was opened at 2004-01-13 16:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=876180&group_id=6121 Category: version 1.3.x (experimental) Group: User Authentication Status: Open Resolution: None Priority: 5 Submitted By: Roy Laurie (kylratix) Assigned to: Nobody/Anonymous (nobody) Summary: WikiWord Requirements for Bogo Login Initial Comment: Version: 1.3.7 Word on the vine is that bogo's going away. Nonetheless, users aren't allowed to login without (seemingly) a name with two words in it. Eg, Kylratix won't work however KylratixWiki will. Pretty easy to track down: 'lib/WikiUser.php' inside function _pwcheck. Here's the litmus that kills one-word logins: if (ALLOW_BOGO_LOGIN && preg_match('/\A' . $WikiNameRegexp . '\z/', $userid) ) { $this->_authmethod = 'BOGO'; return WIKIAUTH_BOGO; } The preg_match is obviously what kills it. Maybe I'll fix tommorrow. Or look at latest CVS and see if it's worth it. --KX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=876180&group_id=6121 |
|
From: SourceForge.net <no...@so...> - 2004-01-13 10:56:03
|
Bugs item #875995, was opened at 2004-01-13 10:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=875995&group_id=6121 Category: version 1.3.x (experimental) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roy Laurie (kylratix) Assigned to: Nobody/Anonymous (nobody) Summary: passencrypt Bad Salt Initial Comment: PhpWiki 1.3.7 I'm not sure if this is merely local to my host, however the result of passencrypt doesn't work with PhpWiki's admin login. Rather than tinkering with passencrypt, I manually called <?php print(crypt('mypassword')); ?> and pasted it into index.php's ADMIN_PASSWD variable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106121&aid=875995&group_id=6121 |
219 messages has been excluded from this view by a project administrator.
