First, it is nice to see that Phpwiki is alive again.
I wanted to give you some feedback of upgrading to the latest version of Phpwiki. (1.5.5)
I needed to move to another server, and I wanted now to run on the latest version of PHP.
(5.6.20 or 7).
Phpwiki runs on IIS on a Windows server, and it uses file (DATABASE_TYPE = file) to store the information.
I finaly managed to may the system to work (Setting the Debug option is useful for this) after fixing a few bugs that I would like to mention:
Problem #1 : Custumized pluggins needs to be declared explicitly.
Authorized plugins need to be declared in the file
lib/IniConfig.php:
line 597
global $AllAllowedPlugins;
$AllAllowedPlugins = $ActionPages;
// Add plugins that have no corresponding action page
$AllAllowedPlugins[] = 'AddComment';
BUG #1
Notice: "Undefined index: SERVER_ADDR"
lib/stdlib.php
line: 1952
function is_localhost() {
return $_SERVER['SERVER_ADDR'] == '127.0.0.1';
}
$_SERVER['SERVER_ADDR'] is not defined on IIS
Use instead:
function is_localhost(){
// return $_SERVER['SERVER_ADDR'] == '127.0.0.1'; // BUG: "Undefined index: SERVER_ADDR" on Windows IIS
return in_array( $_SERVER['REMOTE_ADDR'], array( '127.0.0.1', '::1' ) );
}
Bugs reports are always welcome as I cannot test every configuration.
I test mostly with PearDB (DATABASE_TYPE = SQL) and Apache.
Phpwiki should run with PHP 5.6. I am not sure it will run with PHP 7.
It cannot run in PHP 7 with DATABASE_TYPE = SQL and MySQL since mysql is deprecated (it is replaced by mysqli).
Did you manage to run it with PHP 7 and DATABASE_TYPE = file?
Best regards,
Marc-Etienne Vargenau
--
Marc-Etienne Vargenau marc-etienne.vargenau@nokia.com
Nokia, Route de Villejust, 91620 NOZAY, FRANCE
+33 1 60 40 28 33 OnNet 2103 2833
De : Thierry Nabeth [thierrynabeth@users.sf.net]
Envoyé : jeudi 19 mai 2016 22 h 39
À : [phpwiki:discussion]
Objet : [phpwiki:discussion] Feedback on migrations (inclucing 1 problem & 2 bugs)
Hello,
First, it is nice to see that Phpwiki is alive again.
I wanted to give you some feedback of upgrading to the latest version of Phpwiki. (1.5.5)
I needed to move to another server, and I wanted now to run on the latest version of PHP.
(5.6.20 or 7).
Phpwiki runs on IIS on a Windows server, and it uses file (DATABASE_TYPE = file) to store the information.
I finaly managed to may the system to work (Setting the Debug option is useful for this) after fixing a few bugs that I would like to mention:
Problem #1 : Custumized pluggins needs to be declared explicitly.
Authorized plugins need to be declared in the file
lib/IniConfig.php:
line 597
global $AllAllowedPlugins;
$AllAllowedPlugins = $ActionPages;
// Add plugins that have no corresponding action page
$AllAllowedPlugins[] = 'AddComment';
BUG #1
Notice: "Undefined index: SERVER_ADDR"
lib/stdlib.php
line: 1952
function is_localhost() {
return $_SERVER['SERVER_ADDR'] == '127.0.0.1';
}
$_SERVER['SERVER_ADDR'] is not defined on IIS
Use instead:
function is_localhost(){
// return $_SERVER['SERVER_ADDR'] == '127.0.0.1'; // BUG: "Undefined index: SERVER_ADDR" on Windows IIS
return in_array( $_SERVER['REMOTE_ADDR'], array( '127.0.0.1', '::1' ) );
}
Did you manage to run it with PHP 7 and DATABASE_TYPE = file?
Unfortunatly not.
I have the two version installed, and when I switch to PHP7 I get some errors, that I did not manage to fixe completely.
(I am not a Php expert. I know more about Java)
Here are some of the errors:
PHP7
PhpWiki Warning: (2, Declaration of WikiDB_backend_file::check() should be compatible with WikiDB_backend::check($args = false), D:\inetpub\Test\lib\WikiDB\backend\file.php, 47)
PhpWiki Warning: (2, Declaration of WikiDB_backend_file::rebuild() should be compatible with WikiDB_backend::rebuild($args = false), D:\inetpub\Test\lib\WikiDB\backend\file.php, 47)
Suggested fix:
// function check()
function check($args = false)
// function rebuild()functionrebuild($args=false)
PhpWiki Warning: (8, Only variables should be passed by reference, D:\inetpub\Test\lib\WikiDB\backend\file.php, 550)
Suggested fix:
if ($reversed == false) {
// return new WikiDB_backend_file_iter($this, $this->_loadPageLinks($pagename));
$pageLinks = $this->_loadPageLinks($pagename);
return new WikiDB_backend_file_iter($this, $pageLinks);
}
PhpWiki Warning: (2, preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead, D:\inetpub\Test\lib\Template.php, 72)
Not easy to fix.
And constructors errors (warning)
D:\inetpub\Test\lib\WikiDB\backend.php:777 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; WikiDB_backend_search has a deprecated constructor
Suggested fix:
// function WikiDB_backend_search($search, &$dbh)
function __construct($search, &$dbh)
Note: I am not sure about the &
etc.... (constructors errors)
D:\inetpub\Test\lib\pear\File_Passwd.php:28 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; File_Passwd has a deprecated constructor
D:\inetpub\Test\lib\pear\PEAR.php:87 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; PEAR has a deprecated constructor
D:\inetpub\Test\lib\pear\PEAR.php:796 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; PEAR_Error has a deprecated constructor
D:\inetpub\Test\lib\WikiUser\File.php:23 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; _FilePassUser has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:212 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; WikiTheme has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1720 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; Button has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1755 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; ImageButton has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1793 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; SubmitButton has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1819 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; SubmitImageButton has a deprecated constructor
etc.
Even after having tried to apply the fixes, I did not manage to make it work.
(blank page).
Best regards
Thierry
Last edit: Thierry Nabeth 2016-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just an addition to my previous posting, and with the objectif of making the PHP 5 code "more compatible" with PHP 7.
Note: I remind you that I am still not able to make PHP 7 to work. (But PHP 5.6.20 is now ok)
There is some need to update the constructors in the different class, and using
"__construct()" instead of the name of the class that is now obsolete
However, a direct substitution of the name of the function with '__construct()' will not work in different cases such as the class that Inherit HtmElement in the WikiTheme file such as Button.
// function __construct($text, $url, $class = '', $options = array()) // error: Notice: "Array to string conversion" ###functionButton($text,$url,$class='',$options=array())
because of the way that function construct() is defined in HtmElement.php .
function construct($tagname / , $attr_or_content , .../)
{
$this->_init(func_get_args());
$this->_properties = HTML::getTagProperties($tagname);
}
More change will have to be done.
(as I told you my expertise of PHP is very limited, so I do not make suggestion here)
Thierry
Last edit: Thierry Nabeth 2016-05-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PHP4-style constructors (functions with the same name as the class) are deprecated in PHP7, but they are still valid.
They will be removed in PHP8.
Anyway, I will remove them in the next release of Phpwiki.
Best regards,
Marc-Etienne
--
Marc-Etienne Vargenau marc-etienne.vargenau@nokia.com
Nokia, Route de Villejust, 91620 NOZAY, FRANCE
+33 1 60 40 28 33 OnNet 2103 2833
De : Thierry Nabeth [thierrynabeth@users.sf.net]
Envoyé : samedi 21 mai 2016 16 h 49
À : [phpwiki:discussion]
Objet : [phpwiki:discussion] Feedback on migrations (inclucing 1 problem & 2 bugs)
Hello,
Just an addition to my previous posting, and with the objectif of making the PHP 5 code "more compatible" with PHP 7.
Note: I remind you that I am still not able to make PHP 7 to work. (But PHP 5.6.20 is now ok)
There is some need to update the constructors in the different class, and using
construct() instead of the name of the class that is now obsolete.
However, a direct substitution of the name of the function with construct() will not work
in different cases such as the class that Inherit HtmElement in the WikiTheme file such as Button.
// function __construct($text, $url, $class = '', $options = array()) // error: Notice: "Array to string conversion" ###
function Button($text, $url, $class = '', $options = array())
because of the way that function construct() is defined in HtmElement.php .
function __construct($tagname / , $attr_or_content , .../)
{
$this->_init(func_get_args());
$this->_properties = HTML::getTagProperties($tagname);
}
More change will have to be done.
(as I told you my expertise of PHP is very limited, so I I not suggestion here)
I continue with the description of another bugs;
(hopefully this will be the last one.)
Note: In any case I would like to remind you that PhpWiki is running ok on PHP 5.6.20, with the
(DATABASE_TYPE = file), but not working on PHP 7.
Here the #BUG,
Generation of an "Illegal string offset" message
in function get_links()
in file lib/WikiDB/backend/file.php
I do not remember if it happens only in DEBUG mode.
I am not sure I have properly fixed it, (I probably only have hiden the error)
if (is_array($val2)) { // #### Quick fix (not sure it is correct)
if ($val2['linkto'] == $pagename) // BUG Illegal string offset 'linkto'. $val2 is a String and not an array?
array_push($out, $key);
}
Error in lib/WikiDB/backend/file.php
/** * Find pages which link to or are linked from a page. * * @param string $pagename Page name. * @param bool $reversed True to get backlinks. * @param bool $include_empty True to get empty pages * @param string $sortby * @param string $limit * @param string $exclude Pages to exclude. * @param bool $want_relations True to get relations. * * FIXME: array or iterator? * @return object A WikiDB_backend_iterator. */functionget_links($pagename,$reversed=true,$include_empty=false,$sortby='',$limit='',$exclude='',$want_relations=false){if($reversed==false)returnnewWikiDB_backend_file_iter($this,$this->_loadPageLinks($pagename));$this->_loadLatestVersions();$pagenames=$this->_latest_versions;// now we have an array with the key is the pagename of all pages$out=array();// create empty out arrayforeach($pagenamesas$key=>$val){$links=$this->_loadPageLinks($key);foreach($linksas$key2=>$val2){if(is_array($val2)){// #### Quick fix (not sure it is correct)if($val2['linkto']==$pagename)// BUG Illegal string offset 'linkto'. $val2 is a String and not an array?array_push($out,$key);}}}returnnewWikiDB_backend_file_iter($this,$out);}
Thierry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Last comment about the migration in a config (DATABASE_TYPE = file).
All the Wiki data directories have been copied between two different machines.
In the case that a Wiki page include a special character (e.g. é, è &, etc.)
The wiki properly displays the file correctly, but the edition of the file displays an empty content.
When I reenter the exact same content (with thez special characters), everything seems to work again.
It is not clear what is happening, but I guess that after the deserialisation, something is getting wrong when the content is copied into the editor? Hopefully, the problem will not exist with the new version (when copying from a machine to another).
To finish, I have to admit, I do not tottally understand how the files are really stored, and in particular what is the exact role of the folder 'page_data/' which seems to play the role of a cache, and which content can be deleted (I have done it several times, because is records all the traffic, and leads to thousands of files at the end.).
I will however problably not spend more additional effort on PHPWiki, since the Wikis that are being transfered are for archiving porpose only.
(Having say that, I have to admit I found PHPwiki very usefull, powerful, and lighter than of the solutions such as MediaWiki. Curious to know if a similar Wiki system exists in Node.js )
Example of Web sites: (old version not migrated yet): http://www.calt.insead.edu/ http://www.calt.insead.edu/Encyclopedia/ http://www.calt.insead.edu/LivingLab/AtGentive/Wiki/
Best regards,
Thierry
Last edit: Thierry Nabeth 2016-05-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, has anyone managed to get phpwiki to work with php7? My provider is deprecating php 5.x and I need to move asap.
Currently I'm using a phpwiki 1.5.5 in mysql and I understand it is not going to be usable in php7. I tried to setup a new phpwiki with db=file but couldn't make it run at all (blank page).
Any suggestion?
As an alternative, are there other, current wikis that run on php and allow to import phpwiki content?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
First, it is nice to see that Phpwiki is alive again.
I wanted to give you some feedback of upgrading to the latest version of Phpwiki. (1.5.5)
I needed to move to another server, and I wanted now to run on the latest version of PHP.
(5.6.20 or 7).
Phpwiki runs on IIS on a Windows server, and it uses file (DATABASE_TYPE = file) to store the information.
I finaly managed to may the system to work (Setting the Debug option is useful for this) after fixing a few bugs that I would like to mention:
Problem #1 : Custumized pluggins needs to be declared explicitly.
Authorized plugins need to be declared in the file
lib/IniConfig.php:
line 597
BUG #1
Notice: "Undefined index: SERVER_ADDR"
lib/stdlib.php
line: 1952
function is_localhost() {
return $_SERVER['SERVER_ADDR'] == '127.0.0.1';
}
$_SERVER['SERVER_ADDR'] is not defined on IIS
Use instead:
function is_localhost(){
// return $_SERVER['SERVER_ADDR'] == '127.0.0.1'; // BUG: "Undefined index: SERVER_ADDR" on Windows IIS
return in_array( $_SERVER['REMOTE_ADDR'], array( '127.0.0.1', '::1' ) );
}
BUG #2:
Notice: "Undefined index: relation"
lib\WikiDB\backend\file.php
line 756
function next()
{
...
if (is_array($e[1])) {
// $rec['linkrelation'] = $e[1]['relation']; // BUG: Notice: "Undefined index: relation"
$rec['linkrelation'] = $e[1]['linkto'];
}
...
}
Well, that's all for now.
I hope the problem can be documented, and the bugs fixed.
Bye,
Thierry
Hello Thierry,
Thank you for your interest in Phpwiki.
Bugs reports are always welcome as I cannot test every configuration.
I test mostly with PearDB (DATABASE_TYPE = SQL) and Apache.
Phpwiki should run with PHP 5.6. I am not sure it will run with PHP 7.
It cannot run in PHP 7 with DATABASE_TYPE = SQL and MySQL since mysql is deprecated (it is replaced by mysqli).
Did you manage to run it with PHP 7 and DATABASE_TYPE = file?
Best regards,
Marc-Etienne Vargenau
--
Marc-Etienne Vargenau marc-etienne.vargenau@nokia.com
Nokia, Route de Villejust, 91620 NOZAY, FRANCE
+33 1 60 40 28 33 OnNet 2103 2833
De : Thierry Nabeth [thierrynabeth@users.sf.net]
Envoyé : jeudi 19 mai 2016 22 h 39
À : [phpwiki:discussion]
Objet : [phpwiki:discussion] Feedback on migrations (inclucing 1 problem & 2 bugs)
Hello,
First, it is nice to see that Phpwiki is alive again.
I wanted to give you some feedback of upgrading to the latest version of Phpwiki. (1.5.5)
I needed to move to another server, and I wanted now to run on the latest version of PHP.
(5.6.20 or 7).
Phpwiki runs on IIS on a Windows server, and it uses file (DATABASE_TYPE = file) to store the information.
I finaly managed to may the system to work (Setting the Debug option is useful for this) after fixing a few bugs that I would like to mention:
Problem #1 : Custumized pluggins needs to be declared explicitly.
Authorized plugins need to be declared in the file
lib/IniConfig.php:
line 597
global $AllAllowedPlugins;
$AllAllowedPlugins = $ActionPages;
// Add plugins that have no corresponding action page
$AllAllowedPlugins[] = 'AddComment';
BUG #1
Notice: "Undefined index: SERVER_ADDR"
lib/stdlib.php
line: 1952
function is_localhost() {
return $_SERVER['SERVER_ADDR'] == '127.0.0.1';
}
$_SERVER['SERVER_ADDR'] is not defined on IIS
Use instead:
function is_localhost(){
// return $_SERVER['SERVER_ADDR'] == '127.0.0.1'; // BUG: "Undefined index: SERVER_ADDR" on Windows IIS
return in_array( $_SERVER['REMOTE_ADDR'], array( '127.0.0.1', '::1' ) );
}
BUG #2:
Notice: "Undefined index: relation"
lib\WikiDB\backend\file.php
line 756
function next()
{
...
if (is_array($e[1])) {
// $rec['linkrelation'] = $e[1]['relation']; // BUG: Notice: "Undefined index: relation"
$rec['linkrelation'] = $e[1]['linkto'];
}
...
}
Well, that's all for now.
I hope the problem can be documented, and the bugs fixed.
Bye,
Thierry
Feedback on migrations (inclucing 1 problem & 2 bugs)https://sourceforge.net/p/phpwiki/discussion/18928/thread/ff98ecb0/?limit=25#84d2
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/phpwiki/discussion/18928/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Hello Marc Etienne,
Unfortunatly not.
I have the two version installed, and when I switch to PHP7 I get some errors, that I did not manage to fixe completely.
(I am not a Php expert. I know more about Java)
Here are some of the errors:
PHP7
PhpWiki Warning: (2, Declaration of WikiDB_backend_file::check() should be compatible with WikiDB_backend::check($args = false), D:\inetpub\Test\lib\WikiDB\backend\file.php, 47)
PhpWiki Warning: (2, Declaration of WikiDB_backend_file::rebuild() should be compatible with WikiDB_backend::rebuild($args = false), D:\inetpub\Test\lib\WikiDB\backend\file.php, 47)
Suggested fix:
// function check()
function check($args = false)
PhpWiki Warning: (8, Only variables should be passed by reference, D:\inetpub\Test\lib\WikiDB\backend\file.php, 550)
Suggested fix:
if ($reversed == false) {
// return new WikiDB_backend_file_iter($this, $this->_loadPageLinks($pagename));
$pageLinks = $this->_loadPageLinks($pagename);
return new WikiDB_backend_file_iter($this, $pageLinks);
}
PhpWiki Warning: (2, preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead, D:\inetpub\Test\lib\Template.php, 72)
Not easy to fix.
And constructors errors (warning)
D:\inetpub\Test\lib\WikiDB\backend.php:777 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; WikiDB_backend_search has a deprecated constructor
Suggested fix:
// function WikiDB_backend_search($search, &$dbh)
function __construct($search, &$dbh)
Note: I am not sure about the &
etc.... (constructors errors)
D:\inetpub\Test\lib\pear\File_Passwd.php:28 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; File_Passwd has a deprecated constructor
D:\inetpub\Test\lib\pear\PEAR.php:87 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; PEAR has a deprecated constructor
D:\inetpub\Test\lib\pear\PEAR.php:796 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; PEAR_Error has a deprecated constructor
D:\inetpub\Test\lib\WikiUser\File.php:23 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; _FilePassUser has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:212 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; WikiTheme has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1720 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; Button has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1755 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; ImageButton has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1793 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; SubmitButton has a deprecated constructor
D:\inetpub\Test\lib\WikiTheme.php:1819 Warning[8192]: Methods with the same name as their class will not be constructors in a future version of PHP; SubmitImageButton has a deprecated constructor
etc.
Even after having tried to apply the fixes, I did not manage to make it work.
(blank page).
Best regards
Thierry
Last edit: Thierry Nabeth 2016-05-20
Other (small errors I had to fix with PHP 5.6.20 when migrating from my old version of PhpWiki):
Note: the problems do not exist in the new PhpWiki code. !
===== PHP 5.6.20
Pb #1
Function rcs_id() no longer exist
rcs_id('$Id: calendar.tmpl,v 1.5 2005/08/06 13:26:26 rurban Exp $');
Fix: Just delete the line
Pb #2
in theme/(..)/themeinfo.php
Theme replaced by WikiTheme
Fix:Replace Theme by WikiTheme in the (old) themeinfo.php files
Pb #3
in signin.tmpl
replace
accept-charset="<?=$charset?>"
by
accept-charset="UTF-8"
I hope this helps.
Hello,
Just an addition to my previous posting, and with the objectif of making the PHP 5 code "more compatible" with PHP 7.
Note: I remind you that I am still not able to make PHP 7 to work. (But PHP 5.6.20 is now ok)
There is some need to update the constructors in the different class, and using
"__construct()" instead of the name of the class that is now obsolete
However, a direct substitution of the name of the function with '__construct()' will not work in different cases such as the class that Inherit HtmElement in the WikiTheme file such as Button.
because of the way that function construct() is defined in HtmElement.php .
function construct($tagname / , $attr_or_content , .../)
{
$this->_init(func_get_args());
$this->_properties = HTML::getTagProperties($tagname);
}
More change will have to be done.
(as I told you my expertise of PHP is very limited, so I do not make suggestion here)
Thierry
Last edit: Thierry Nabeth 2016-05-21
Hi Thierry,
Thank you for all your input.
PHP4-style constructors (functions with the same name as the class) are deprecated in PHP7, but they are still valid.
They will be removed in PHP8.
Anyway, I will remove them in the next release of Phpwiki.
Best regards,
Marc-Etienne
--
Marc-Etienne Vargenau marc-etienne.vargenau@nokia.com
Nokia, Route de Villejust, 91620 NOZAY, FRANCE
+33 1 60 40 28 33 OnNet 2103 2833
De : Thierry Nabeth [thierrynabeth@users.sf.net]
Envoyé : samedi 21 mai 2016 16 h 49
À : [phpwiki:discussion]
Objet : [phpwiki:discussion] Feedback on migrations (inclucing 1 problem & 2 bugs)
Hello,
Just an addition to my previous posting, and with the objectif of making the PHP 5 code "more compatible" with PHP 7.
Note: I remind you that I am still not able to make PHP 7 to work. (But PHP 5.6.20 is now ok)
There is some need to update the constructors in the different class, and using
construct() instead of the name of the class that is now obsolete.
However, a direct substitution of the name of the function with construct() will not work
in different cases such as the class that Inherit HtmElement in the WikiTheme file such as Button.
// function __construct($text, $url, $class = '', $options = array()) // error: Notice: "Array to string conversion" ###
function Button($text, $url, $class = '', $options = array())
because of the way that function construct() is defined in HtmElement.php .
function __construct($tagname / , $attr_or_content , .../)
{
$this->_init(func_get_args());
$this->_properties = HTML::getTagProperties($tagname);
}
More change will have to be done.
(as I told you my expertise of PHP is very limited, so I I not suggestion here)
Thierry
Feedback on migrations (inclucing 1 problem & 2 bugs)https://sourceforge.net/p/phpwiki/discussion/18928/thread/ff98ecb0/?limit=25#dbd1
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/phpwiki/discussion/18928/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Hello,
I continue with the description of another bugs;
(hopefully this will be the last one.)
Note: In any case I would like to remind you that PhpWiki is running ok on PHP 5.6.20, with the
(DATABASE_TYPE = file), but not working on PHP 7.
Here the #BUG,
Generation of an "Illegal string offset" message
in function get_links()
in file lib/WikiDB/backend/file.php
I do not remember if it happens only in DEBUG mode.
I am not sure I have properly fixed it, (I probably only have hiden the error)
if (is_array($val2)) { // #### Quick fix (not sure it is correct)
if ($val2['linkto'] == $pagename) // BUG Illegal string offset 'linkto'. $val2 is a String and not an array?
array_push($out, $key);
}
Error in lib/WikiDB/backend/file.php
Thierry
Hello,
Last comment about the migration in a config (DATABASE_TYPE = file).
All the Wiki data directories have been copied between two different machines.
In the case that a Wiki page include a special character (e.g. é, è &, etc.)
The wiki properly displays the file correctly, but the edition of the file displays an empty content.
When I reenter the exact same content (with thez special characters), everything seems to work again.
It is not clear what is happening, but I guess that after the deserialisation, something is getting wrong when the content is copied into the editor? Hopefully, the problem will not exist with the new version (when copying from a machine to another).
To finish, I have to admit, I do not tottally understand how the files are really stored, and in particular what is the exact role of the folder 'page_data/' which seems to play the role of a cache, and which content can be deleted (I have done it several times, because is records all the traffic, and leads to thousands of files at the end.).
I will however problably not spend more additional effort on PHPWiki, since the Wikis that are being transfered are for archiving porpose only.
(Having say that, I have to admit I found PHPwiki very usefull, powerful, and lighter than of the solutions such as MediaWiki. Curious to know if a similar Wiki system exists in Node.js )
Example of Web sites: (old version not migrated yet):
http://www.calt.insead.edu/
http://www.calt.insead.edu/Encyclopedia/
http://www.calt.insead.edu/LivingLab/AtGentive/Wiki/
Best regards,
Thierry
Last edit: Thierry Nabeth 2016-05-23
So, has anyone managed to get phpwiki to work with php7? My provider is deprecating php 5.x and I need to move asap.
Currently I'm using a phpwiki 1.5.5 in mysql and I understand it is not going to be usable in php7. I tried to setup a new phpwiki with db=file but couldn't make it run at all (blank page).
Any suggestion?
As an alternative, are there other, current wikis that run on php and allow to import phpwiki content?