-
2012-10-10
Zcippy
Hi we just upgraded to Adora Belle RC1 and have realized that when searching for a header and clicking that result (seem like it wants to bring you directly to that header) the page turns up blank. Editing the page is fine, the text is still there, and if one goes directly to that page (not directly to header through search function) it works perfectly.
Example:
Works: doku.php?id=network:vpnsetup
Does not work(link/result from search function): doku.php?id=network:vpnsetup&s[]=vpn&s[]=guides
Running on RHEL v5.4 with Apache v2.2.3
Tested on: Firefox v15.0.1 & Chrome v22.0.1229.92 m
-
2012-10-10
andi
Please provide the error message found in your PHP/Webserver logs.
-
2012-10-10
Zcippy
I couldn't find any default PHP log so i had to set a path to it, restart httpd and then recreate the problem but it didn't give much:
cat /var/log/httpd/php_error_log
[10-Oct-2012 10:15:01] PHP Warning: require_once(/var/www/html/lib/plugins/news/scripts/rss.php): failed to open stream: No such file or directory in /var/www/html/newsfeed.php on line 16
[10-Oct-2012 10:15:01] PHP Fatal error: require_once(): Failed opening required '/var/www/html/lib/plugins/news/scripts/rss.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/newsfeed.php on line 16
But the log for Apache was there (but in a different location then i thought):
cat /var/log/httpd/error_log
[Sun Oct 07 04:02:09 2012] [notice] Digest: generating secret for digest authentication ...
[Sun Oct 07 04:02:09 2012] [notice] Digest: done
[Sun Oct 07 04:02:14 2012] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Sun Oct 07 04:02:15 2012] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
[Wed Oct 10 10:21:01 2012] [notice] caught SIGTERM, shutting down
[Wed Oct 10 10:21:01 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Oct 10 10:21:02 2012] [notice] Digest: generating secret for digest authentication ...
[Wed Oct 10 10:21:02 2012] [notice] Digest: done
[Wed Oct 10 10:21:02 2012] [notice] mod_python: Creating 4 session mutexes based on 256 max processes and 0 max threads.
[Wed Oct 10 10:21:02 2012] [notice] Apache/2.2.3 (Red Hat) configured -- resuming normal operations
I can't really see that there's something that could be related to this problem , do you? Or am I looking in the wrong logs? I'll continue to see if there's any other logs I should look in.
Thanks for such a fast reply btw!
//Ted
-
2012-10-10
ach
That should be it:
[10-Oct-2012 10:15:01] PHP Fatal error: require_once(): Failed opening required '/var/www/html/lib/plugins/news/scripts/rss.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/newsfeed.php on line 16
Disable the news plugin and try again. If it works, report that bug to the plugin author.
-
2012-10-10
Zcippy
I removed the plugin and the error still persists. :/
-
2012-10-10
ach
Any new and/or different errors in the logs since then?
-
2012-10-11
Zcippy
No it's the same :/
-
2012-10-11
ach
How can it be the same if you have removed the plugin?
-
2012-10-11
Zcippy
I mean that it hasn't changed, nothing have been added since the removal , actually the logs doesn't seem to grow at all, should they?
-
2012-10-12
Zcippy
I don't know how to proceed :/ I've tried a numerous amount of scenarios but the problems seems to persist when one is trying to go directly to a header from a search result. :/
-
2012-10-12
andi
A completely blank page (that is what we're talking about here, right?) is nearly always the result of a fatal PHP error. Those are usually logged somewhere (either via syslog, the webservers error log or a dedicated log file configured in php.ini). An exception would be a supressed error report using the magic @ char. This might happen in some plugin. Can you give a list of installed plugins?
Otherwise, without a proper error message this is nearly impossible to debug.
-
2012-10-12
Zcippy
Aha , I understand. We have to following plugins installed:
acl
anewssystem
authorstats
comment
condition
config
edittable
fontface
include
info
issuetracker
loglog
noticeboard
orphanmedia
orphanswanted
plantuml
plugin
popularity
revert
safefnrecode
testing
usermanager
There was a setting for syslog in the php.ini file, should it be turned on?
Thanks for such a great and fast support by the way, it is really appreciated that you take your time to help me!
-
2012-10-12
Zcippy
Sorry I just saw that it was a Windows feature, we're running RHEL 5.4 here. Troubleshooting in the morning :P
-
2012-10-12
andi
hmm none of the pugins' names seem to suggest that they act on search highlighting, but to be sure I'd try disabling all non-default plugins and see if that solves the problem. If it does, turn them on one by one again to find the culprit.
regarding php.ini best configure a dedicated error log so you are sure where to look for errors.
-
2012-10-12
Zcippy
Sorry I forgot to tell you, I tried but it didn't help. :/
-
2012-10-15
Zcippy
Any idea what it could be?
-
2012-10-15
ach
As Andi said, "without a proper error message this is nearly impossible to debug".
It could also be caused by any "tpl_function.php" or any other file included by "@require_once" or similar in your template's main.php. Remove the "@" and see if that brings up any better error messages.
-
2012-10-15
Zcippy
I'll have a look! Thank you! =)
-
2012-10-26
menegazzo
Guys, i'm having exacly the same problem. My DokuWiki is a 100% Adora Belle fresh install.
My PHP error log only says:
"PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/php_gd2.dll' - /usr/lib/php/modules/php_gd2.dll: cannot open shared object file: No such file or directory in Unknown on line 0"
At least for me there are no clues in this message. Any tips?
-
2012-10-29
Zcippy
Great, which PHP version do you run?
According to "php -v" i run PHP 5.1.6
-
2012-10-29
menegazzo
I found that the issue begins at function "html_hilight" on html.php, line 287: for some reason, the callback function ft_snippet_re_preprocess is not working correctly and its making the $phrases array empty. With the phrases array empty, the regex will be wrong, and later a call to preg_replace_callback will clear the html, thus producing no output errors, only a blank page.
http://xref.dokuwiki.org/reference/dokuwiki/nav.html?_functions/ft_snippet_re_preprocess.html (line 388)
At least for me, i commented the line 287 at html.php, and the search results when clicked are displaying content instead of a blank page:
//$phrases = array_map('ft_snippet_re_preprocess', $phrases);
I know that only commenting a line is not the real solution, but let the dokuwiki developers take a look.
-
2012-10-30
Zcippy
WOW! Works great!! :D Thank you so much Marcos! I raise my hat and bow! ;)
//Ted
-
2012-11-04
Michitux
I think this is a problem of missing UTF-8 support in the PCRE library in your PHP installation. I've just added a paragraph to
https://www.dokuwiki.org/requirements that explains how to check if PHP has been compiled with UTF-8 supoort in PCRE. Could you please check if UTF-8 support in PCRE is indeed missing on your systems?
-
2012-11-08
menegazzo
I think its supported:
Compiled with
UTF-8 support
No Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
-
2012-11-08
andi
Could everyone who has these problems please put the file attached to this comment to your wiki root and call it in your browser? then post the output it produces here.
-
2012-11-09
Zcippy
i added it to the root but coulnd\t call it. I tried putting it in the pages dir to but that didn't help.
-
2012-11-09
andi
What do you mean with you couldn't call it? Just put save it as test.php in your wiki directory and open
http://yourserver/dokuwiki/test.php in your browser.
-
2012-11-09
Zcippy
Sorry, here we go: Array ( [0] => missing UTF-8 support ) asian check 1 int(0) asian check 2 int(0)
-
2012-11-09
Michitux
I noticed that "Unicode properties support" is needed, too. I corrected that on the requirements page.
-
2012-11-12
menegazzo
My test.php output:
Array ( [0] => missing Unicode property support ) asian check 1 int(0) asian check 2 int(1)
Thus, sad life... we need to fix our servers in order to dokuwiki search works properly.
I learned a lot about regex and unicode support with this. Thanks guys!
-
2012-11-12
Zcippy
We installed:
PCRE version 6.6 06-Feb-2006
Compiled with
UTF-8 support
Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
And now it works perfectly! Thank you!
//Ted
-
2012-11-12
andi
Thanks for the feedback. Next version will have a check for UTF-8 and Unicode properties in do=check.
I'm still not 100% sure what causes the initial bug. It seems not to be in the function ft_snippet_re_preprocess. At least not in the part that checks for Asian words because this part should simply return always false even if UTF-8 support is missing and not cause any trouble this way.
Marcos' debug output shows only missing Unicode property support, so I guess I need to find out where we use Unicode properties and if we can avoid them there.
-
2012-11-12
Michitux
@Andi: I'm relatively sure that this is the use of unicode properties in ft_snippet_re_preprocess that was introduced in
84e581a6 - a log from an affected system:
http://pastebin.com/h60KfUNr and the user got the same warning in html_highlight() after removing the @ in front of preg_replace_callback, see
http://irc.dokuwiki.org/index.php?d=2012-10-01#msg414983 for the IRC log.
-
2012-11-12
andi
Ah thanks for the pointer Michitux. Fixed in
3161005d