Loading...
 
Architecture / Installation

Architecture / Installation


Installing 18.0

posts: 65

I had trouble installing 18.0Alpha getting an error msg as below.

“Fatal error: Call to a member function urldecode() on null in /home/mcadamco/public_html/bluebook180.mcadam.org.nz/lib/parser/parserlib.php on line 3671”

I was able to install 18.0beta no problems but decided to wait for 18.0

This now gives me an error msgs as follows.

Fatal error: Call to a member function urldecode() on null in /home/mcadamco/public_html/bluebook180.mcadam.org.nz/lib/parser/parserlib.php on line 3682

It would seem to be the same file or function that is giving problems each time.

I copied in parserlib.php from version 18.0beta but that didnt solve the problem just referenced
a slightly different line.

Why am i the only one to have these problems? no one else reports them :-)

I upload the files by ftp and then install.

Any help would be appreciated :-)

I now have access to the server but its along time since i did command line stuff and would rather not have to
learn again :-)

Rod

posts: 742 United States

Hey Rod, are you installing on your own server or shared hosting or VPN?
I am installing 18.0 via SVN with success on VPN hosting.


posts: 65
Its on shared hosting John on www.ventraip.com.au where i currently have v 17.1 running fine and have had various versions back to 12. or so.

posts: 65

It appears that this is a database issue.
if i install and let it destroy the existing database it installs fine.
if i copy over the old database the programme opens ok but when i go to control panel
i get a message that says the database needs updating. When i rerun install to do that
(as i did originally) of course I get the error message again.


posts: 742 United States
I have had issues when upgrading because of php versions. Come to think of it, I recently was playing with 17.1 migrating it to a different domain and upgrading it to 18 and I got a ton of error messages during the db upgrade, I went into my hosting panel and my php was set at 5.6, I set my php to v7.0 and all seemed to go well after that. Just something else to look at. Try changing your php version to 7.

posts: 65

HI there John
It seems that it is a database problem that i caused a while back by deleting and copying in tables from a previous version.
I am taking the opportunity to totally rebuild my site under 18.0.
A big and somewhat laborious task but it will be worthwhile in the end.
I can copy and paste a lot of material so it wont be too bad really :-)

Thanks for your suggestions. I have upgraded my php version as well as you suggested.

Rod

posts: 742 United States

"I can copy and paste a lot of material so it wont be too bad really "

You are in good company, I am doing just that! My wiki isn't that big, I could have just upgraded, but I figured what the heck, a clean slate is usually best, so, coffee, late nights on the weekend after the family goes to bed, and I'll have it all copied over in no time.
I am really loving 18.


posts: 44

I have this problem also. I am using the Softaculous upgrade tool on a shared webhost. The Site was 1 12.x (12.6 IIRC) upgraded via Softaculous to V15.x, and has failed to upgrade to v18.

The Softaculous panel shows that it is v18 but the General configuration shows the following

General
Global site configuration, date formats, etc.
Database Version Problem
Your database requires an update to match the current Tiki version. Please proceed to the installer. Using Tiki with an incorrect database version usually provokes errors. If you have shell (SSH) access, you can also use the following, on the command line, from the root of your Tiki installation: php console.php database:update
Installer not locked
The installer allows a user to change or destroy the site’s database through the browser so it is very important to keep it locked.
You can re-run the installer (tiki-install.php), skip to the last step and select LOCK THE INSTALLER. Alternatively, you can simply add a lock file (file without any extension) in your db/ folder.

This is the current status from Softaculous

Hi,

Apologies for the delay in reply.

It seems that this is the bug with the script itself. We have found a similar thread discussing over this issue and they shall fix this in the next version.

https://sourceforge.net/p/tikiwiki/mailman/tikiwiki-devel/thread/F2DE8896807BF045932776107E2E783D35097445%40CT20SEXCHP02.FONCIERQC.INTRA/#msg36236145

We request you to wait until then. Also this issue persist when an old Tiki that has been upgraded many times.

Let us know.

Regards,
Softaculous Support

posts: 2428 Czech Republic

Version 18.1 is around the corner. Please be a bit more patient and try later then when it's released. Also make sure when you run the installer there are no "duplicate" or "already exists" SQL errors when doing the database upgrade.

luci

posts: 44

With Version 18.1 I still get the following error on the database upgrade (From 15.x)

Fatal error: Call to a member function urldecode() on null in /home/cha49277/public_html/tiki10/lib/parser/parserlib.php on line 3689


posts: 65

Hi there Jpurssey.

I think this is essentially exactly the same error as I had.

I found a way around this error by updating with a new empty database then deleting the old tables one by one and copying in the previous tables. This works if the site is not too complex and is mainly pages or articles etc. I'm not sure if you have the knowledge of myphpadmin or similar to do this? There are only about 10 tables that need to be copied over. (Backup your database first though :-) and use different names.)

This error seems to be only tested for at initial installation.

I assume that there is a field that is missing or maybe has the wrong properties. I'm not sure if anyone with a knowledge of the code and the required intimate database knowledge can help you with a manual repair?

However the problem will keep occurring with later upgrades.
In my case this error probably was created by some database messing around I did at some stage in the past rather then being spontaneous.

I am solving the problem by completely redoing my site. Copying and pasting articles and pages and reediting at the same time. This is going to take quite a while but will be worthwhile in the end as I am restructuring a number of things at the same time now that I have a better understanding of the software.
I am able to run the existing site on 17.1 and the new one on v18.X at the same time so as to not loose continuity and will only switch over when ready.

Rod

posts: 9 United Kingdom

I have had no joy in upgrading from 17.1 to 18.1 the site having now disappeared from existence. This is the error my hosting support discovered:

Fatal error: Declaration of Zend\Session\Validator\AbstractValidatorChainEM2
attach() must be compatible with Zend\EventManager\EventManagerInterface
attach($eventName, callable $listener, $priority = 1) in /home/whitesun/public_html/cidoc-dswg.org/wiki/vendor_bundled/vendor/zendframework/zend-session/src/Validator/AbstractValidatorChainEM2.php on line 18

I am winding back to 17.1.
I don't have the time or the confidence to rebuild what is a pretty large database as described above.. Can the upgrade not be just made to work or is the site stuck on 17.1 for evermore?

posts: 44

I, too, have created a new instance of 18.1

I found that my wiki pages would not export, and eventually isolated two that would not export and prevented the export function from working. Without them the export works fine.

I would have had to recreate my structures and inheritance permissions eg

  • unregistered < Trainees < trainers < Course Writers <
  • Alumni
  • Board
  • Advisors
  • Staff
  • Newsletter subscribers


but the courses are going to Moodle and the wiki will now not require such a structure