After installing new modules. My server's response code is 404 on all pages, but I can see them.

I can see that the index file has been replaced in the folders.

index.php


If return to index.html, it works again.

Which modules?

You should download the latest code of the upcoming XOOPS 2.5.11 from GitHub

This latest code will also allow you to use XOOPS on PHP 8,

Please be aware that some older modules might not work correctly on PHP 8, but we're in process of updating them, so if you have issues, please report them on GitHub, and we'll look into it.

Modules: xsitemap, lexicon, waiting .
I see. But XOOPS 2.5.11 not final version - tremble.
I'll try on another site.

XOOPS 2.5.11 is not final, but it's very solid, we're using it here

Thanks so much for this report.

I have been struggling for days to diagnose a problem with my local test site running under WAMP which does not occur (thankfully) on my live website. I have a button in one of my modules which downloads a dynamically constructed XLSX file, and this suddenly started to hang the server. In addition, the Preview buttons on my DHTML Text Area fields started to report "Server Not Responding ... Please Try later".

After completely reconstructing all my self-signed certificates (the live server has a real certificate), and updating my local Apache logging, I realized that almost all requests to the local test site were returning a 404 status, but the pages themselves were still rendering normally. I got some minimal success by changing the code to force a 200 status when returning the preview text and my XLSX file. But still the Software Engineer in me needed to understand why this functionality suddenly stopped working.

My local test server is a development platform and as such it has several Xoops modules installed which are not on the live server.
I had installed xSitemap (1.56 Final) intending to use it to build a list of all my pages as I transition the site to Xoops 2.5.11 and Bootswatch 5.3. This report encouraged me to look more closely at what was installed on the local test site. When I discovered that both xmnews and xSitemap had the new index.php files mentioned in this post, I uninstalled them as a test. And suddenly things were back to normal.

After some additional tracing and testing, I offer the annotated segment from my Apache access log which clearly demonstrates that there is something about xSitemap when installed in Xoops 2.5.10 that causes the erroneous 404 status in the Http Response.


The scenario is as follows:
1. Start with a clean install of Xoops 2510
2. Install xSitemap and press the button to go to the website Home Page
At this point accessing the website still returns a 200 status.
3. Close the browser and reopen the website
At this point almost all requests return the 404 status.

Installing xSitemap in Xoops 2.5.11 does not have the same result.

The xmnews module does not seem to have the same effect, so I do not think the index.php files could be causing the problem. I have done exhaustive debugging through the site startup with xSitemap installed and I can't see anything that might shed any light on the cause. But something in xSitemap is not playing well with Xoops 2510.

Hi, The problem most likely comes from the index.php file which is in the preloads folder.

Can you verify that the modules/xsitemap/preloads/ folder does not contain the index.php file?

If in this folder there is the index.php file, it is absolutely necessary to remove it and put the index.html file in its place.

You have to check all your modules and do the same manipulation.

The problem should go away.

Yes, indeed the xsitemap (1.56 FINAL) module does have the preloads/index.php file and replacing it with the preloads/index.php file from the profile module cures the problem. Thank you.

I had suspected the issue was with something in the autoload mechanism, but not fully understanding the details there, I could not make any specific connection. Would you be able to explain why the index.php file with its setting of the header status causes problems whereas the index.html file which just updates the history does not? Where do these files fit into the startup sequence?

Thanks again for your assistance.

The problem is relatively simple. The .php files which are in the "preloads" folder are loaded automatically by xoops. When we moved from index.html to index.php, we modified core (2.5.11) to not include the index.php file. But on version 2.5.10 there is no this modification.
Including the index.php file generates 404 errors (not in navigation) but on robots or internal scripts on the site.

Several weeks ago, I discovered that one of my websites was no longer referenced by google, the robots were blocked (error 404). I searched (very long) and found this problem. It is for this reason that all modules are modified with index.html in the "preloads" folder.
On xoops 2.5.11 there is no problem but before yes...

OK. That clears things up. I can imagine it took a long time to find the issue. I've been at this over a week, with much Apache research and several frustrating sessions with Wireshark before I clued in that the 404 was bogus.

So modifying the Xoops 2.5.11 autoload process to exclude the index.php file was not the resolution, and now all modules that use preloads must use the index.html file and not index.php for protection in their preloads/ directory. Is that correct?

Thank you so much for your work here.

Quote:
No, that's not correct.

XOOPS 2.5.11 works correctly with index.php in the /preloads folder, because it excludes it automatically.

The only problem with index.php in /preloads folder is with XOOPS 2.5.10 and older. So if you're using XOOPS 2.5.10, replace the index.php in /preloads folder with index.html that contains:


You should check on GitHub for the latest versions of your modules:
https://github.com/orgs/XoopsModules25x/repositories?type=source

On February 20th, we have updated several of the modules that included the index.php in /preloads and replaced it with index.html, so they would still work on your XOOPS 2.5.10 installation.

If you still have issues, please let us know.