Loading...
 
Skip to main content

Features / Usability


Fatal error while trying to rebuild search index

posts: 27

I am running Tiki version 14.2. Using the documentation here (https://doc.tiki.org/Unified+Index#From_the_command_line), I tried to rebuild the search index of my tiki database using the unified console.php command.

php console.php index:rebuild

The response was:

Fatal error: Can't use method return value in write context in /lib/tikilib.php on line 3402

Does anyone have any suggestions?

Since I have had so much trouble rebuilding the search index, I tried setting the MySQL Full-Text Search on instead, but doing that and attempting to run a search brings me to the tiki install error page, which is even worse.

Thanks for any help!

Jen B.

posts: 44 Canada

The reason why you are getting this error is most likely because your PHP version is less than 5.5, which is the minimum PHP requirements of Tiki version 14 (see https://doc.tiki.org/Requirements).

If you upgrade your PHP to 5.5 or higher it should work fine. Note that depending on your server, the web version of PHP as shown in tiki-phpinfo.php (or alternative phpinfo()) could be different from the one used on the command line (shown using php -v).

If you switched to MySQL Full Text Search as the engine for Unified Search, you will still need to rebuild the index before it can be used, but I think you will need PHP 5.5+ nevertheless for Tiki 14 on the whole, otherwise you will run into many unexpected issues.


posts: 27
Hm, thank you for your reply, but that cannot be the problem. I am running PHP 5.6.

posts: 44 Canada

What does "php -v" on the command line give you?

The error "Fatal error: Can't use method return value in write context " is typical of using empty() with a function call, which as far as I know should be allowed from PHP 5.5+.

Does reindexing from the Tiki control panel via the browser work?


posts: 27

No, I can't reindex through the control panel. It runs for about a minute and then I get:

"No route found. Please see http://dev.tiki.org/url+Rewriting+Revamp"

I think it is probably because my database is too large.


Oh, this is strange! I know I'm running PHP 5.6, my host upgraded all of the VPS accounts and I have double checked through my host panel, but running php-v on the command line gave me:

PHP 5.4.36 (cli) (built: Jan 8 2015 13:14:21)

Could this be because it was at 5.4 when I originally installed tiki on this server?

posts: 1563 Germany

Hello Jen,

I positively know that some providers (if not many) offer not only dfferent PHP versions on their servers (what is a good idea), but have different default configuration for different parts.
Thus for example you might have PHP 5.5+ as default in the document root, but in the linux shell of the same server ou might have PHP 5.4 or lower - in one case I have to deal even with PHP 4.x in a shell of a managed server where the websites run on 5.5 by default.

I cannot recon what exactly is the problem on your server, but as you said, your command line shows: "PHP 5.4.36 (cli) (built: Jan 8 2015 13:14:21) ", which points somewehere near what Nelson mentioned - a PHP version prblem on your server.

When a server has PHP 5.3 or 5.4 in the shell and 5.5+ is set for the document root, you can smoothly install and run a Tiki 14 even via svn, BUT you HAVE to change the required PHP version of the setup.sh script from 55 to 54 or 53, which then works, as the comoser (which runs in the shell) needs only 5.3.

But when you install a Tiki 15 on the same server it will not run, as for Tiki 15 we switched from Zend 1 to Zend 2, which relies fully on 5.5+ - A Tiki 15 will not be installable via svn if the shell had only 5.4- .

What you could do in such a case, but needed some time to upload, was to checkout a Tiki 15 on the local machine (like I have an Ubuntu drivate with a very standart PHP 5.5 etc.) ...
Do everything locally until including composer.

Then upload the whole directory to the server in a specific directory which is just to keep this clean and the you could copy (in the shell with cp -R sourcepath targetpath )to several website installations and go from there.

I would not recommend that as a productive workflow, as it is more time consuming than the normal workflow (directly sn on the prductive server) but for development it can help a lot, if you cannot ad hoc get the server updated ... it is obviously a temporary workaround.

I do not know, if all that helps you for your specific issue, as it seems to be not really the same, but maybe my description added to Nelsons hintes could point you somewhere nearer to a solution.

Cross fingers and best regards,
Torsten


posts: 44 Canada

Probably best to get help from your host provider (btw which hosting provider is this?), but you could check (as many Linux servers have all the php versions in there): ls /usr/bin/php*

to see perhaps what versions of PHP are there. Perhaps you will see something like /usr/bin/php56. If so, if you run /usr/bin/php56 -v what do you get? If you find a (cgi) version of php that is 5.6 that is good, if it is a (fcgi) version then it isn't any help. Let me know if that helps. Probably your host did not change the command line php when they upgraded to php 5.6.

The "No route found. " is also interesting. Did rebuilding the index work in the past via the admin panel? Maybe it is not a database size issue but some "bad" content that has been recently added that causes the indexing to fail (just a guess though). If you index via the control panel with the logging option on, you can see the last lines of the log file to see what the last item it tried to index before failing. You can then manually look at that piece of content to see if it has anything special/weird that might cause an issue (some kind of redirection to a non existent page perhaps, which is what No route found would suggest).

posts: 27

Nelson and Torsten, thank you very much for your help!

I was able to change the PHP in my command line with some help from my host (dreamhost is my host provider, and their tech people are very helpful to complete idiots like me), and then the command did go through for me and I was able to rebuild the index.

To answer your other questions, Nelson, when trying to rebuild from the tiki admin panel, I did not get any kind of log file, even when I checked that option, so I'm not sure at what step the problem was. I wonder if part of it might have been that some of my pages were corrupted during an update several years ago and a lot of my non-Roman characters still have not been completely fixed.

I've also never had to rebuild the index before. I inherited the database about four years ago, and the woman running it previously hadn't kept up with the tiki updates, so we had a painful couple of updates from tiki 3 to 9. The search function worked fine until the update to 12, when I noticed that it stopped searching for non-Roman characters, and then with this last update to 14 it started giving me the errors and telling me to rebuild. (Incidentally, I noticed it still isn't searching for all the non-Roman characters correctly, but that is probably a different issue related to above.)

Thanks again!
Jen B.