1
masel
index.php in New modules
  • 2020/11/30 18:21

  • masel

  • Friend of XOOPS

  • Posts: 34

  • Since: 2004/10/6


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

header
('HTTP/1.0 404 Not Found');


If return to index.html, it works again.

2
Mamba
Re: index.php in New modules
  • 2020/11/30 21:39

  • Mamba

  • Moderator

  • Posts: 11381

  • Since: 2004/4/23


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.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

3
masel
Re: index.php in New modules
  • 2020/12/1 14:41

  • masel

  • Friend of XOOPS

  • Posts: 34

  • Since: 2004/10/6


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

4
Mamba
Re: index.php in New modules
  • 2020/12/2 6:06

  • Mamba

  • Moderator

  • Posts: 11381

  • Since: 2004/4/23


XOOPS 2.5.11 is not final, but it's very solid, we're using it here
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

5
dejadingo
Re: index.php in New modules
  • 2022/4/4 23:08

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


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.

================================ start with clean Xoops 2510 ==================================
local-test-site [04/Apr/2022:17:25:45 -0400"GET / HTTP/1.1" 200 15168
================================ install xsitemapgo to home page ============================== 
local-test-site [04/Apr/2022:17:26:30 -0400"GET /admin.php HTTP/1.1" 200 37858
local
-test-site [04/Apr/2022:17:26:35 -0400"GET /modules/system/admin.php?fct=modulesadmin HTTP/1.1" 200 48318
local
-test-site [04/Apr/2022:17:26:38 -0400"GET /modules/system/admin.php?fct=modulesadmin&op=installlist HTTP/1.1" 200 33177
local
-test-site [04/Apr/2022:17:26:44 -0400"GET /modules/system/admin.php?fct=modulesadmin&op=install&module=xsitemap HTTP/1.1" 200 23461
local
-test-site [04/Apr/2022:17:26:48 -0400"POST /modules/system/admin.php HTTP/1.1" 200 33186 
local
-test-site [04/Apr/2022:17:26:52 -0400"GET / HTTP/1.1" 200 15324 
================================ close browser/reopen websiterefresh page ===================== 
local-test-site [04/Apr/2022:17:28:12 -0400"GET / HTTP/1.1" 302 310 
local
-test-site [04/Apr/2022:17:28:12 -0400"GET / HTTP/1.1" 404 15439 
local
-test-site [04/Apr/2022:17:29:33 -0400"GET /themes/xswatch4/js/bootstrap.bundle.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:33 -0400"GET /themes/xswatch4/js/cookieconsent.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:33 -0400"GET /themes/xswatch4/js/js.cookie.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:33 -0400"GET /include/xoops.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:33 -0400"GET / HTTP/1.1" 404 15439 
local
-test-site [04/Apr/2022:17:29:33 -0400"GET /browse.php?Frameworks/jquery/jquery.js HTTP/1.1" 200 86927 
local
-test-site [04/Apr/2022:17:29:34 -0400"GET /themes/xswatch4/images/logo.png HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:34 -0400"GET /themes/xswatch4/images/favicon.png HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:29:34 -0400"GET /themes/xswatch4/images/toolsicon.png HTTP/1.1" 304 
================================ 
close browser/reopen website =================================== 
local-test-site [04/Apr/2022:17:39:28 -0400"GET / HTTP/1.1" 302 310 
local
-test-site [04/Apr/2022:17:39:28 -0400"GET / HTTP/1.1" 404 15439 
================================ uninstall xsitemapgo to home page ============================
 
local-test-site [04/Apr/2022:17:40:34 -0400"GET /admin.php HTTP/1.1" 404 39613 
local
-test-site [04/Apr/2022:17:40:38 -0400"GET /modules/system/admin.php?fct=modulesadmin HTTP/1.1" 404 54733 
local
-test-site [04/Apr/2022:17:40:44 -0400"GET /modules/system/admin.php?fct=modulesadmin&op=uninstall&module=xsitemap HTTP/1.1" 404 24801 
local
-test-site [04/Apr/2022:17:40:47 -0400"POST /modules/system/admin.php HTTP/1.1" 404 2858
local
-test-site [04/Apr/2022:17:40:50 -0400"GET / HTTP/1.1" 200 15053 
================================= close browser/reopen websiterefresh page ====================
local-test-site [04/Apr/2022:17:42:38 -0400"GET / HTTP/1.1" 302 310
local
-test-site [04/Apr/2022:17:42:38 -0400"GET / HTTP/1.1" 200 15168
local
-test-site [04/Apr/2022:17:42:41 -0400"GET /themes/xswatch4/js/cookieconsent.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:41 -0400"GET /themes/xswatch4/js/bootstrap.bundle.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:41 -0400"GET /include/xoops.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:41 -0400"GET /themes/xswatch4/js/js.cookie.min.js HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:41 -0400"GET / HTTP/1.1" 200 15168 
local
-test-site [04/Apr/2022:17:42:41 -0400"GET /browse.php?Frameworks/jquery/jquery.js HTTP/1.1" 200 86927
 local
-test-site [04/Apr/2022:17:42:42 -0400"GET /themes/xswatch4/images/logo.png HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:42 -0400"GET /themes/xswatch4/images/toolsicon.png HTTP/1.1" 304 
local-test-site [04/Apr/2022:17:42:42 -0400"GET /themes/xswatch4/images/favicon.png HTTP/1.1" 304 
==================================================================================================

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.

6
Mage
Re: index.php in New modules
  • 2022/4/5 6:34

  • Mage

  • Core Developer

  • Posts: 207

  • Since: 2009/8/2 1


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.

7
dejadingo
Re: index.php in New modules
  • 2022/4/5 12:43

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


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.

8
Mage
Re: index.php in New modules
  • 2022/4/5 15:15

  • Mage

  • Core Developer

  • Posts: 207

  • Since: 2009/8/2 1


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...

9
dejadingo
Re: index.php in New modules
  • 2022/4/5 15:45

  • dejadingo

  • Just popping in

  • Posts: 71

  • Since: 2004/10/22


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.

10
Mamba
Re: index.php in New modules
  • 2022/4/5 18:00

  • Mamba

  • Moderator

  • Posts: 11381

  • Since: 2004/4/23


Quote:
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?

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:
<script>history.go(-1);script>


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.
Support XOOPS => DONATE
Use 2.5.10 | Docs | Modules | Bugs

Login

Who's Online

204 user(s) are online (70 user(s) are browsing Support Forums)


Members: 0


Guests: 204


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Oct 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits