SourceForge logo
SourceForge logo
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

Showing results of 143

<< < 1 2 3 4 5 6 > >> (Page 4 of 6)
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
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: 2004年6月13日 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.

Showing results of 143

<< < 1 2 3 4 5 6 > >> (Page 4 of 6)
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /