#697 Error on deleting resources

[Roger Appleby]

Hi,
I have been uploading and deleteing many resources recently and I spotted a bug when deleting resources. I am using version 6.9.1, MYSQL 8.0.39 and PHP 8.2.27. Resources ~16000.
The workflow was as follows:

1. Advanced search by import tag
2. Select all resources in list delete (~500) If I recall correctly I get teh same error if I delete 1.
3. The deletion takes place correctly
4. Then returns with an error message as follows:

Deleting resources error

Successfully deleted resource(s)
{"innerHTML":"

Missing input<\/p>"}

1. I then have lost connection and have to restablish it but it does recover
2. There are also entries generated in the log file which is attached

I have tried updating to 6.11 but although the update process runs just fine and I get back to a normal login screen as soon as I login I get a blank page.

Let me know what I can do to help troubleshoot this.

Regards

Roger

[Mark Grimshaw]

Hi Roger,

Sorry to hear you are having problems. If I recall correctly, the erroneous return after deleting might be one of the several bugs solved on the way to 6.11. So, once 6.11 is up and running for you, do let us know if the error persists.

Re 6.11 and the blank page. If memory serves, It might be something to do with config.php, which often undergoes updates along with the code and database. In particular, have a look at '$WIKINDX_URL_BASE'

Is anything written to the error log following the blank page? If you are able to edit the database tables, ensure in the config that the 'configBoolean' column of the 'configErrorReport' line is set to 1.

*Regards,

Mark

[Mark Grimshaw]

Further on this, selecting resources through advanced search then deleting them all produces no errors on my 6.11 test installation.

Mark

[Roger Appleby]

HI Mark,
Just redone the upgrade with the same problem. Still getting a blank page. I looked at $WIKINDX_PATH_AUTO_DETECTION which was set to TRUE with $WIKINDX_URL_BASE = ''. I tried it with FALSE and the correct URL and got the same result. I have attached the php_error_log.
Stephane not sure wheter there is a question or just an observation? PHP is set to 8.2.27.
I have left 6.11 up and so can quickly answer any questions.

Its great the bugs are fixed in 6.11.

Regards

Roger

[Stéphane Aulery]

Hi Roger,

You don't need to tweak those options.

The second PHP log is missing.

Regards,

[Roger Appleby]

Mark,
Quick update as I forgot teh attachment!! I also cleared the log and ran it a second time with eth false setting. Both logs attached. 4 was the initial one with the first run set to TRUE and 5 the one after clearing with FALSE

[Mark Grimshaw]

Hi Roger,

Yes, you have found a bug. The fix is simple if you can get access to the PHP files. In core/libs/SQLSTATEMENTS.php starting at line 87 there is this:

    public function frontSetDays(
        $days,
        $limit,
    ): string
    {

Change it to:

       public function frontSetDays(
        $days,
        $limit,
    ): array
    {

(string —> array)

Let us know whether that works.

Mark

[Roger Appleby]

Hi Mark,
Great that fixed it and it now loads as it should. I logged in and then out again and noticed that the php error log attached contained an error. It might be useful for you.

I will check the deletion once we have cleared these other issues

Regards

Roger

[Mark Grimshaw]

Thanks Roger,

Glad to know it's all working. Re the warning, I cannot duplicate it but I will keep an eye out.

Regards,

Mark

[Roger Appleby]

Hi Mark,
Just logged in deleted some resources and got the same error as with 6.9.1 identified above

Missing input<\/p>"}

I then reinstated the resources and logged out. The log file is attached.

There are a lot of warnings and some fatal errorsbut I am not sure how significant they are. Is it possible to surpress the warning as the log file grows very quickly?

Reagrds

Roger

[Mark Grimshaw]

Hmmm. I cant duplicate. Would it be possible to send me a dump of your database?

@Stéphane: any advice on how to completely disable PHP errors in WIKINDX? php.ini or another way?

Mark

[Stéphane Aulery]

In core/startup/WEBSERVERCONFIG.php, replace error_reporting(E_ALL); by error_reporting(0);.

As of today, the value is still E_ALL.

[Roger Appleby]

Stéphane thanks thats clered out all the error reporting. The error file had grown to 18000 lines in 24hrs so its clear to see that it can get fairly large over a week or two. I also saw in WEBSERVERCONFIG.php that E_all is the default.

So I repeated the test in my previous post and got no php_error_log errors reported.

Just the

Missing input<\/p>"}

after doing the deletion.

I then have to restablish the connection with resend and it recovers.

Mark do you still want a n sql dump?

If you need me to do anything else let me know.

Regards

Roger

[Stéphane Aulery]

Hi Roger,

The log system is equipped with a detection of available disk space and purges the logs when necessary.

Please send me your log. I will try to see what can be fixed or has already been fixed. I am sure we missed some hard to test cases.

Did I have access to the site's FTP and an account on the site? I forgot.

Regards,

[Roger Appleby]

Hi Stéphane,
A week ago I did recieve an email from the provider saying the site was over size and this log was one of the offenders. Mind you I had been doing alot of importing and exporting! The log is currently empty having set teh variable in WEBSERVERCONFIG.php to 0 so that matches with Marks observation as he was seeing no errors. Presumably if you set it back to E_all you will see the same as me.

I can set you up a user account if you wish as you do not have one or happy to send an sqldump. Also happy to provide you with an ftp account just let me know what you prefer. The wikindx is straight out of the tin as I have made no changes and at this time have no attachments.

Regards

Roger

[Stéphane Aulery]

The log system allows up to a certain % of the disk to be filled but is not very restrictive.
I think I'll narrow it down further.

Is the site exposed to the Internet?

If you want me to be able to debug I need FTP access and an account on the site. If you want me to be able to debug I need FTP access and an account on the site. I could do bug hunting for the next release.

[Roger Appleby]

OK I will set both up can you provide some means of sending ftp password please.

[Stéphane Aulery]

Send it to lkppo@users.sourceforge.net

[Mark Grimshaw]

I will leave it in your hands Stéphane,

Mark

[Stéphane Aulery]

Hi Roger,

I applied 4 or 5 fixes that we already made in version 6.12.0, in particular one concerning the consultation of a resource. After that I no longer have any bugs when consulting a resource.

I also discovered a bug in configuration loading (a null parameter) while exploring yours logs.

I also added new code that returns a 404 page to the browser when a resource does not exist. The logs were filling up very quickly because of search engines crawling the site and looking for deleted resources.

To do this properly we need to return a 410 error in case of a deleted resource so that search engines forget about it. This is a different case from a resource that never existed.. So this will be covered separately.

Please continue using WIKINDX normally and I will check in a few days if any new errors have appeared. I am hunting for any remaining errors.

Regards,

[Roger Appleby]

Hi Stephane,

Thanks for that. I knew about the BOTS and had meant to mention it to you but it slipped my mid with the other errors and warnings.

I will do some searches and uploads for a day or two to check I see no errors.

Regards

Roger

[Stéphane Aulery]

Hi Roger,

I put on your site the code to return the 410 code. We will see if in the next few days the visits of dead pages go down.

Regards,

[Stéphane Aulery]

Hi Mark,

I fixed an error in the resource view count increment. It was called too early, before knowing if the resource exists.

Regards,