• Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Text Rendering
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 1.0-rc
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Flyspray
Opened by Tabbycat - 20.05.2016
Last edited by peterdd - 07.04.2021

FS#2128 - Geshi (part of dokuwiki plugin for code blocks) uses deprecated /e modifier on preg_replace

The dokuwiki plugin uses a very old version of geshi for syntax highlighting which uses the deprecated /e modifier in preg_replace in two places rather than preg_replace_callback.

This can trigger warnings such as the following when initially parsing content which uses dokuwiki syntax and includes code:

PHP message: PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/phpapps/flyspray/plugins/dokuwiki/inc/geshi.php on line 2058

PHP message: PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/phpapps/flyspray/plugins/dokuwiki/inc/geshi.php on line 2067

This affects as well. Several hits came up on google when I search for the following due to the warnings having been displayed ahead of the page content (seen screenshot): flyspray preg_replace_callback

Because flyspray caches the results of processing dokuwiki content then the warnings don’t get emitted if the content has already been cached (so you may find that when you access the url in the screenshot that it doesn’t show the warnings unless you clear the cache entry for that task). Previews can get the warnings spat out as well if there are tagged code sections in the content.

I had a look at a more recent version of geshi ( from sourceforge) and they had fixed that issue in it (presumably along with a lot of other stuff) so I tried replacing plugins/dokuwiki/inc/geshi.php and plugins/dokuwiki/inc/geshi/* with the versions and that stopped the warnings. I haven’t extensively tested it, but it was processing stuff in code blocks correctly still on the couple of samples I tried.

I guess it’s a separate issue but the new flyspray theme doesn’t have any css styles to apply to the syntax highlighting (if you look at  FS#1107  you can see that, and in fact you can see it with the css bit below - if you inspect them with a browser dom inspector you can see that the genshi plugin has parsed and tagged the bits, but no styles are applied so its all just in the default colour). I can raise that as a separate task if worth doing? The following section in bluey stylesheet covered it I think:

.code .br0 {color:#6c6;}
.code .es0 {color:#009;font-weight:700;}
.code .kw1 {color:#b1b100;}
.code .kw2 {color:#000;font-weight:700;}
.code .kw3 {color:#006;}
.code .kw4 {color:#933;}
.code .me0 {color:#060;}
.code .nu0 {color:#c6c;}
.code .re4 {color:#099;}
.code .sc0 {color:#0bd;}
.code .sc1 {color:#db0;}
.code .sc2 {color:#090;}
.code .st0 {color:red;}
.code .co1,.code .co2,.code .coMULTI {color:gray;font-style:italic;}
.code .kw5,.code .re0,.code .re1,.code .re2 {color:#00f;}
Closed by  peterdd
07.04.2021 16:30
Reason for closing:  Complete
Additional comments about closing:  

thinks its fixed meanwhile, reopen if issues reappear

Project Manager

Missing css added as geshi.css to the CleanFS folder. see

There are current two active Geshi projects on github. Dokuwiki project uses, but seems to be the original project. Both do releases.. Would you like to do some more testing to be confident to update the files in Flyspray?

Sorry about the slow reply - I have a mail filter on mails from postmaster at any domain (due to backscatter/spam) to send them to a different folder, and as uses postmaster for its automated messages and I don't check the folder frequently I hadn't noticed for a while!

The version I'd given a quick try was the download on the sourceforge page as that seemed to be the most recent packaged "download" referenced on does point to the github project though as being where geshi's code repository has moved to and that seems to have a version tagged in November 2014. Nothing seemed to have happened then since 2014 until February 2016 when BenBE brought in some contributed patches and made a few other tweaks, so it looks like there's a release in the pipeline but no changes since February so who knows if it'll get tagged for release!

The version used by Dokuwiki (I'll call it "easybook fork") is based on from sourceforge, have made some changes of their own, but also (on 10th May 2014) did bring in some of the subsequent changes from the original project (but not all of what went into the original project's as there were some further changes after 10th May). The easybook fork seems to be continuing to update the version numbers from (latest is so it's no longer tracking the original project except potentially in an ad-hoc manner (but given how infrequent changes have been in the original project, that's unsurprising).

The easybook fork claims to have some fixes to support php7 in the release. The original project has a fix to support php7 in the 1.8.13 release if/when that gets made. The easybook fork removes the php close tags from the files. The easybook fork is updated more frequently. I noticed that

From the flyspray change log I see that on April 22nd you brought in a patch someone had submitted for the dokuwiki plugin to fix PHP7 issues, so probably best to make sure the geshi version used is good with PHP7 (so if using the original project rather than the easybook fork, maybe just grab the latest from master).

I also see you submitted an issue for the original project, so I don't know if you're inclined to go with that version out of the two?


Available keyboard shortcuts


Task Details

Task Editing