View Issue Details

IDProjectCategoryView StatusLast Update
0033906mantisbtbugtrackerpublic2024-05-12 12:34
Reporterrossh_mb Assigned Todregad  
Status closedResolutionfixed 
Product Version2.26.1 
Target Version2.26.2Fixed in Version2.26.2 
Summary0033906: Failed opening core.php in timeline_inc.php on PHP 8.2 / IIS

With php 8.2, Mantis 2.26.1, Windows, the My View page has INTERNAL APPLICATION ERROR... and display the associated error text.

php error log says

[29-Feb-2024 18:40:00 Asia/Manila] Failed opening required 'core.php' (include_path='.;C:\php\pear')
E:\websites\zzzzzz\www\repairs\my_view_page.php: 166: - - - - include()

Line 166 of that file is include( $g_core_path . 'timeline_inc.php' );

Steps To Reproduce

Visit the page

Additional Information

If I comment out line 166, no more error.

$g_core_path can be set, or not set - no difference. $g_core_path contains a valid path either way. core and all other dirs are in default locations.

TagsNo tags attached.


related to 0033914 resolveddregad Move timeline_inc.php from core to root directory 




2024-02-29 07:25

developer   ~0068612

With php 8.2, Mantis 2.26.1

Was it working before you upgraded to 2.26.1 ? Is it OK with other PHP versions ?

Failed opening required 'core.php'

Looks like the problem is not with my_view_page.php line 166, but inside of timeline_inc.php, which does require_once( 'core.php' ); (line 17).

I assume you've checked that core.php is present and accessible, but I would guess it is because if not you would likely have other errors, as this file is used everywhere.

Additional, debugging information is needed to help understanding the problem. Please follow these steps:

  1. temporarily configure your system as follows:
    $g_display_errors = array(
    E_WARNING => 'halt',
    E_NOTICE => 'halt',
    E_USER_ERROR => 'halt',
    E_USER_WARNING => 'halt',
    E_USER_NOTICE => 'halt'
    $g_show_detailed_errors = ON;

WARNING - SECURITY RISK: the 'show_detailed_errors' config can cause MantisBT to display sensitive information about your system. We recommend to restrict its activation to a Test environment, only for as long as necessary. If possible, do not turn it ON globally, instead limit it for specific user(s) using the Manage Configuration page.

  1. Reproduce the error

If the output does not help you resolving the issue and you need further assistance,

  1. save the output of the error screen, preferably as an HTML page (not a screenshot !)
  2. be careful to remove/mask any confidential information if needed
  3. upload the results here

You could also try to add echo getcwd(); die; in timeline_inc.php just before require_once( 'core.php' ); and see of the path is correct.



2024-02-29 08:17

reporter   ~0068613

Last edited: 2024-02-29 08:18

Before? No errors with 8.26.0 or 8.26.1 and php 7.4. Goes bad with either 8.26.0.or 8.26.1 and php 8.2.
I'm using the the basic 8.2 php, without any fluff added. Just the needed modules enabled.
I thought the actual physical core.php file does not exist. Its a pseudonym and inbuilt to the php engine?

With config extras:

'require_once(core.php): Failed to open stream: No such file or directory' in 'E:\websites\zzzzzz\www\repairs\core\timeline_inc.php' line 17
Please use the "Back" button in .....

Full path: E:\websites\zzzzzz\www\repairs\core\timeline_inc.php
Line number: 17

Stack trace

Filename Line Class Type Function Args

0 E:\websites\zzzzzz\www\repairs\core\timeline_inc.php 17 - - require_once <string>'E:\websites\zzzzzz\www\repairs\core\error_api.php'
1 E:\websites\zzzzzz\www\repairs\my_view_page.php 166 - - include <string>'E:\websites\zzzzzz\www\repairs\core\timeline_inc.php'

timeline_inc.php add line 16 echo getcwd(); die; == C:\Program Files\php\8.2

I went into timeline_inc.php and commented off line 17 //require_once( 'core.php' ); Now it all works. Maybe that's the solution?



2024-02-29 12:14

developer   ~0068614

Last edited: 2024-02-29 12:15

I thought the actual physical core.php file does not exist. Its a pseudonym and inbuilt to the php engine?

No. core.php is an essential part of MantisBT source code [1], being the main include file responsible for initializing everything that's needed for it to run.

No errors with 8.26.0 or 8.26.1 and php 7.4. Goes bad with either 8.26.0.or 8.26.1 and php 8.2.

I guess you meant 2.26.0 or 2.26.1, and the 8 is just a typo ;-)

The very same core.php file is included by my_view_page.php [2] without errors

timeline_inc.php add line 16 echo getcwd(); die; == C:\Program Files\php\8.2

So the behavior changes between the main script (my_view_page.php) and the timeline include. This is really weird. I would expect that to print E:\websites\zzzzzz\www\repairs\core.

Do you get the same behavior when accessing (replace 1 with a valid user ID) ?
What do you get when running PHP 7.4 ?

NOTE: I tried, but am not able to reproduce this error here with PHP 8.2, so I would suspect that something specific to your server's setup is causing the script's current directory to change.

I went into timeline_inc.php and commented off line 17 //require_once( 'core.php' ); Now it all works. Maybe that's the solution?

That's a workaround for this specific problem, and it is probably safe to comment this line out considering that core.php is included by the parent script in both occurrences where it's used. But it should not be necessary to do that.

I'm concerned that you may be facing the problem elsewhere though, so it's probably worth investigating the root cause.



2024-02-29 22:19

reporter   ~0068615

Last edited: 2024-02-29 22:21

Looking deeper, I think the include path and file locations are at issue.

calling echo get_include_path(); die; prior to my_view_page.php 166: include( $g_core_path . 'timeline_inc.php' ) , and also prior to core\timeline_inc.php 17: require_once( 'core.php' );
The result is the same: '.;C:\php\pear'
The files are located in different directories and the current include search path does not step back up one level for the core.php

If I adjust timeline_inc.php 17: require_once( 'core.php' ); to read
require_once( 'E:/websites/zzzzzz/www/repairs/core.php' );
then all is happy.
But the usual trick of '../core.php' fails. and '/websites/zzzzzz/www/repairs/core.php' fails too.

So it looks to me like php 8.x got a lot tougher on the include path and the redirection shortcuts.

I have tried every other page and tab, and no other errors present.

On my system, php.exe and IIS and the system account it runs under, is executing on C:, while all the websites are on E:. Maybe its the assumed include path, and that's the reason why this is somewhat limited to my setup??



2024-03-01 04:10

developer   ~0068616

Thanks for investigating.

calling echo get_include_path(); [...] The result is the same: '.;C:\php\pear'

That is expected. The problem's root cause is IMO not with the include path's definition, but due to the fact that we rely on the . (current directory) part of it, and that (apparently) changes between when core.php is included in my_view_page.php (line 41) and timeline_inc.php.

The files are located in different directories

Right, I forgot that timeline_inc.php is in ./core and not in the MantisBT root directory. Sorry about that.

the usual trick of '../core.php' fails. and '/websites/zzzzzz/www/repairs/core.php' fails too

That is not surprising actually, based on what you stated in 0033906:0068613. Since the current working directory is C:\Program Files\php\8.2,

  • ../core.php is expanded to C:\Program Files\php\core.php
  • /websites/zzzzzz/www/repairs/core.php is actually C:/websites/zzzzzz/www/repairs/core.php and your scripts are on E:

What I don't understand, is why it works for you with PHP 7.4 but not 8.2... Is the server configuration identical (except for PHP version) ?

Could you please check the value of getcwd() for both 7.4 and 8.2, in

  • my_view_page, before include( $g_core_path . 'timeline_inc.php' ); (line 167)
  • timeline_inc.php, before require_once( 'core.php' ); (line 17) as before


2024-03-01 07:14

reporter   ~0068617

[01-Mar-2024 20:06:41 Asia/Manila] PHP v8.2.16, cwd = C:\Program Files\php\8.2 from line 166 in /repairs/my_view_page.php
[01-Mar-2024 20:06:41 Asia/Manila] PHP v8.2.16, cwd = C:\Program Files\php\8.2 from line 17 in /repairs/core/timeline_inc.php

[01-Mar-2024 20:10:32 Asia/Manila] PHP v7.4.33, cwd = C:\Program Files\php\7.4 from line 166 in /repairs/my_view_page.php
[01-Mar-2024 20:10:32 Asia/Manila] PHP v7.4.33, cwd = C:\Program Files\php\7.4 from line 17 in /repairs/core/timeline_inc.php

[01-Mar-2024 20:12:43 Asia/Manila] PHP v7.4.33 includepath = .;C:\php\pear
[01-Mar-2024 20:13:49 Asia/Manila] PHP v8.2.16 includepath = .;C:\php\pear



2024-03-02 06:40

developer   ~0068618

Thanks for the feedback. So at least the behavior is consistent and as expected.

Unfortunately, that does not give me any clue as to why it works with PHP 7.4 and not with 8.2 :-/

Anyway I don't think it's worth spending any more time on this. I'll remove the unnecessary require_once in timeline_inc.php.



2024-03-03 00:55

reporter   ~0068619

I found one other page affected by this, with same "internal error" message:

The logged error is:
[03-Mar-2024 13:46:27 Asia/Manila] count(): Argument 0000001 ($value) must be of type Countable|array, null given
E:\websites\zzzzzz\www\repairs\admin\test_langs.php: 512: - - - - print_admin_menu_bar()

And the line of code at 512: print_admin_menu_bar( 'test_langs.php' );



2024-03-03 05:41

developer   ~0068620

The actual error occurs in html_api.php print_admin_menu_bar() function at line 953. The include_once( 'schema.php' ); fails for the same reason as before, resulting in $g_upgrade to be null, and the subsequent call to count() throws the Argument must be of type Countable | array error on PHP 8.

So it indeed appears to be the same root cause, the only difference being the included file is present in the same directory as the calling script.

Again, I can fix the symptoms (i.e. make sure that count() is not called with null), and/or work around the problem either by setting an absolute path when including schema.php in print_admin_menu_bar() or including the file in test_langs.php like it's done for the other admin helper scripts, but that does not address the root cause.

According to the PHP documentation for include

Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include will finally check in the calling script's own directory and the current working directory before failing.

There is definitely something strange going on with your system (or maybe it's specific to IIS, but I don't have access to an instance of it to test), and you need to figure out what it is and fix it, i.e. why is your CWD not that of the script being called.



2024-03-03 05:50

developer   ~0068621

@rossh_mb please test these possible solutions

Workaround 1

diff --git a/admin/test_langs.php b/admin/test_langs.php
index c99a6878c..5fcd95734 100644
--- a/admin/test_langs.php
+++ b/admin/test_langs.php
@@ -29,6 +29,9 @@ $t_mantis_dir = dirname( __FILE__, 2 ) . '/';

 require_once( $t_mantis_dir . 'core.php' );

+# Load schema version needed to render admin menu bar
+require_once( 'schema.php' );
  * Class CheckLangFile.

Workaround 2

diff --git a/core/html_api.php b/core/html_api.php
index 609d70609..8805ac9d3 100644
--- a/core/html_api.php
+++ b/core/html_api.php
@@ -948,8 +948,8 @@ function print_admin_menu_bar( $p_page ) {
                # Relative URL up one level to ensure valid links on Admin Checks page
                $t_path = '../';
        } else {
-               global $g_upgrade;
-               include_once( 'schema.php' );
+               global $g_absolute_path, $g_upgrade;
+               require_once( $g_absolute_path . 'admin/schema.php' );
                if( count( $g_upgrade ) - 1 != config_get( 'database_version', -1, ALL_USERS, ALL_PROJECTS ) ) {
                        $t_menu_items['install.php'] = 'Upgrade your installation';


2024-03-03 09:28

reporter   ~0068622

Last edited: 2024-03-03 09:31

..or maybe it's specific to IIS??
The php.exe runs as fast cgi application, from C: and php file extentions are mapped to the fast cgi module. php files are restricted to being scripts, and are not directly "executable". If the script does not shift the CWD, then its where the exe starts.

I ran this script. results below.

echo "<!DOCTYPE html>
echo 'A test of paths and PHP version = ' . phpversion();
echo '. This is run from the mantis web root dir.';
echo "

echo 'get_include_path=' . get_include_path();
echo "

echo 'getcwd=' . getcwd();
echo "

echo 'FILE=' . FILE; << this has double underscore before / after
echo "

echo 'DIR=' . DIR; << this has double underscore before / after
echo "</body></html>";

A test of paths and PHP version = 8.2.16. This is run from the mantis web root dir.
getcwd=C:\Program Files\php\8.2

The php help says the this about include;
Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include will finally check in the calling script's own directory and the current working directory before failing.

Who sets the include path ?? its probably compiled into the windows php binary, or is some default value.

From that... the . (dot) gets us the adjacent php files, and subdir/files. But going back up the path, the .(dot) can't help us. So going up needs the full path and in my case, the drive too as the implied root dir == C: and not E:

I think the issue I'm reporting here, is from a vagueness in paths. The include ('subdir/file.php), injects the subdir/file into the current file making the include call, and any further file locations referenced within subdir/file.php, need to be in the context of calling file (one dir higher).

A solution for Mantis might be to set the cwd to DIR at the common header, and now your on firm ground for location.

***** note the editor has stripped off the double underscore before / after DIR and FILE



2024-03-03 10:09

developer   ~0068623

..or maybe it's specific to IIS??

As I said before, yes maybe. I've never used IIS for PHP myself, but many other Mantis users have, and never reported such problems. Is your 7.4 system also using the same FastCGI configuration ?

It would be interesting to know, what happens to the various paths if you use this code snippet as an include file, depending on how many levels deep it is included, i.e. assuming your script from 0033906:0068622 is named include.php


include 'include.php';


include 'test1.php';


2024-03-03 11:42

reporter   ~0068624

I suggest that you go rent an online server for a month at Kamtera or a hundred other places, and try it out,. Or download the trial server program into a vm. This will help answer all your questions and more. PM me if you want to discuss the setup. Thanks for the adjustments.



2024-03-03 12:26

developer   ~0068625

Well I do this in my spare time, and I'm certainly not going to spend money on that, sorry.



2024-03-10 12:20

developer   ~0068637

Just committed a fix to address the problem with test_lang.php.

Related Changesets

MantisBT: master-2.26 bff76ed9

2024-03-02 06:56


Details Diff
Remove inclusion of core.php in timeline_inc.php

By definition an include file is part of a main script, which will
always include core.php, so it's not necessary to reference it again
in the include.

This actually caused an error on a user's system (PHP 8.2 on IIS). The
problem could not be reproduced, but an easy fix is to remove the
useless require_once.

Fixes 0033906
Affected Issues
mod - core/timeline_inc.php Diff File

MantisBT: master-2.26 70905946

2024-03-10 11:58


Details Diff
Use absolute path to schema.php in html API

print_admin_menu_bar() needs to include schema.php, to determine whether
we have an upgrade pending or not.

This include_once call did not specify the path to the file, resulting
in a failure to include it on IIS with FastCGI, as the current working
directory was not set to that of the currently executing script, but to
where the PHP executable was stored. This caused $g_upgrade to be null,
leading to an error when calling count() on PHP 8.

We now use require_once instead so we get a hard failure if schema.php
could not be included, and we specify the full path to the file to avoid
the problem on IIS/FastCGI.

Fixes 0033906
Affected Issues
mod - core/html_api.php Diff File

MantisBT: master-2.26 131a3d8f

2024-03-10 11:59


Details Diff
Remove unnecessary require_once

schema.php is included by print_admin_menu_bar()

Issue 0033906
Affected Issues
mod - admin/email_queue.php Diff File
mod - admin/index.php Diff File
mod - admin/system_utils.php Diff File