1. Registered User
Join Date
Feb 2018
Posts
3

Greetings,

I work at a hospital where we've developed an app that covers a lot of ground for it, it used to run on a regular PC with high specs until we finally got a server. But that's where we began running into several issues, the most troubling one is the one mentioned in the title. When I say random I mean random, like, we have an include file with 20 classes and one, just one, at random will suddenly stop being detected. More curious is the fact that if I were to include that missing class right after the include file with all the classes:

ie:
require_once("classes.php");

will throw Fatal error: Class '<classname>' not found in <include file calling a bunch of classes> on line <line number> but, if at the time of this happening I do this:

require_once("classes.php");
require_once("missing class.php");

It will work.

The "solution" so far has been to restart the webserver, we restart IIS and the issue goes away. The IIS settings are verbatim of the ones from the PC where it worked without hitches, the settings for PHP are the same from the PHP on the PC where it worked fine too. I'm fairly convinced that this is a webserver issue but this particular problem does not leave any kind of error or warning on the Windows' event viewer. And as for the PHP logs aside from the fatal error posted above, there's nothing else. I mentioned the word random and that's because the few times this has happened it's been always with a different file; more puzzling is the fact that it's not even a file used at that time as this has happened both at peak times just as well as during late hours when activity decreases a lot.

To be honest, this particular issue is driving me nuts so any kind of feedback or ideas on what could the issue be or if anyone ever experienced something similar would be greatly appreciated.

2. Pretty hard to debug on that info alone. As far as server settings impacting it, all I can think of would be if there is a difference in include_path (I think that's what it's called, anyway) if you're not requiring files with an explicit path -- or something about the directory/file structure on the server is different and needs to be taken into account.
_

3. Show us this include file. More importantly check that each and every statement is properly coded if you are pointing to different paths for these modules that you are collecting.

4. Registered User
Join Date
Feb 2018
Posts
3
Sorry of it sounds vague but to be fair, the issue is vague.

On my development environment I have all errors enabled at PHP level but this issue so far has only happened in the production environment. This is at the header of an ajax file:

require_once($_SERVER['DOCUMENT_ROOT']."/intranet/common/core-settings.php"); require_once($_SERVER['DOCUMENT_ROOT'].'/intranet/higa/libs/db.php');
/* This one includes definitions of tables so I wouldn't have to be writing the table names on each query. */
require_once($_SERVER['DOCUMENT_ROOT'].'/intranet/higa/libs/settings.php'); require_once($_SERVER['DOCUMENT_ROOT']."/intranet/common/core-functions.php");
/* This one includes super classes. */
require_once($_SERVER['DOCUMENT_ROOT'].'/intranet/common/library/clases.php'); /* This one includes instances of some classes. */ require_once($_SERVER['DOCUMENT_ROOT'].'/intranet/higa/objects/clases.php');
require_once(\$_SERVER['DOCUMENT_ROOT'].'/config.php');
The three files I've commented on their purpose have exhibited at one point or another the behavior I mentioned. The reason I have stressed that I believe this to be a server issue is because if it would be an error with the path, then I'd be getting a fatal error at all times. Moreover, as mentioned on my OP, one of the first times it happened, since I was completely baffled over the fact it was telling me a file was missing from its location that I was seeing right in front of my eyes, I included the file outside of the main include file and then it picked it up just fine.

So as to not make this post huge I am including links to the contents of each file:
- library/clases.php (https://pastebin.com/HdfqPsaM)
- objects/clases.php (https://pastebin.com/STHVaHAX)
- settings.php (https://pastebin.com/svrWp2dF)

It's also worth mentioning that it's not that it fails to find the file as a whole but just one of the files included within. Yet restarting the webserver fixes the issue and whatever file that said it couldn't find can be found again.

IIS is known for really stupid crap. As an example there is a bug that we've found on a .Net site where one file would be flagged as having an error by the .Net framework yet there was none nor any changes made to it recently. The "fix" was to edit the file by adding a blank somewhere, whatever it took to update the last modified date and then the file would no longer toss errors.

Again, sorry if I am sounding vague with this but I promise it's not because I'm not considering information that I should share but rather because this is all that I know of given the situation.

5. Hmm...it almost sounds like a race condition, but since PHP is not (normally) multi-threaded, I don't see how that could happen. Then again, I don't have any real experience with IIS, in case maybe it does any kind of caching/threading/whatever that would result in things not being called in the sequence one would expect them to be? (Yes, I'm grasping at straws.)

I suppose this could be an argument for setting up some auto-load processing for class definitions? That could range from fairly easy to a real pain, depending on how your class definition files are named and organized. http://php.net/manual/en/language.oop5.autoload.php
_

6. Do you consistently use the name "clases" instead of "classes"? And if these are php files that you don't want anyone to see why do you store them inside the document root instead of above it?

It must be something else causing this error. If all of these files legitimately exist in the folders that you are refencing and there is no process that periodically removes them or updates them, then there is no reason for the statements to fail. Does the error message give you the detail as to which line and the contents of that line are failing? If so, please show us that too!

7. Registered User
Join Date
Feb 2018
Posts
3
Originally Posted by NogDog
Hmm...it almost sounds like a race condition, but since PHP is not (normally) multi-threaded, I don't see how that could happen. Then again, I don't have any real experience with IIS, in case maybe it does any kind of caching/threading/whatever that would result in things not being called in the sequence one would expect them to be? (Yes, I'm grasping at straws.)

I suppose this could be an argument for setting up some auto-load processing for class definitions? That could range from fairly easy to a real pain, depending on how your class definition files are named and organized. http://php.net/manual/en/language.oop5.autoload.php
_
Hey, the issue is super vague so we are all grasping for straws here; nothing amiss about that. The auto load thing is something to consider but it's something that happens with files. While this hasn't happened since Jan 11th we run into this then:

[11-Jan-2018 08:24:20 America/Argentina/Buenos_Aires] PHP Notice: Use of undefined constant TABLA_PRACTICAS - assumed 'TABLA_PRACTICAS' in C:\inetpub\wwwroot\atsi\rayos\helpers\alta-informe\code.php on line 149

As mentioned on my second post, settings.php contains calls to files with defined constants for database table names. For some reason, it failed to pick up one of those. Restarting IIS brought everything back to normal; I'm fairly convinced this is a IIS issue with either application pools or somesuch (granted the settings I'm running are the same as on the old PC). This begets the question of why am I asking about it here and that's because on the official IIS + PHP forums nobody really seems to care about issues other than the well known bug with fastcgi.

Originally Posted by ginerjm
Do you consistently use the name "clases" instead of "classes"? And if these are php files that you don't want anyone to see why do you store them inside the document root instead of above it?

It must be something else causing this error. If all of these files legitimately exist in the folders that you are refencing and there is no process that periodically removes them or updates them, then there is no reason for the statements to fail. Does the error message give you the detail as to which line and the contents of that line are failing? If so, please show us that too!
I'm a spanish speaking person so my code is a mix between English and Spanish depending on my mood. Clases is the spanish form of classes but yeah, there are no issues on paths there.

As for errors, I listed one above. With classes is more like:

But you know what? It just hit me that this is not a matter of not finding a file per se. If I wouldn't be finding the file then I'd be getting a fatal error about it but instead the error is about either not finding either a class or a constant defined within the file. This is definitely looking like some kind of memory issue on the webserver.

8. What you just posted indicates that it is not the code that you previously posted at issue here. It is something that you must be referring to FROM that code.

9. By any chance to you have a auto_prepend_file setting in your PHP config? (Could be in your applicable php.ini file, or in a local directory [whatever IIS's corollary is to Apache's .htaccess file].) Just wondering if that's what is supposed to load some/all of your config, and for some reason the web server "forgets" to do it for some strange reason, and then when you restart it, it remembers.

grasping at more straws
_

10. You get a server rack ... and you stick windows on it?!?! *facepalm*

Thats issue number one.

You should have a linux distro witrh mysql, php and the other bells, whistles and whatever floats your boat.

Then the system would work with anything.

Have you checked the server logs to get a better understanding of why you are getting this issue in your setup.

last time I used a window box for a server was a long while ago, must be 20 years now. So I would suggest that you check the path settings, if you have any PHP.ini files you can tweak to ensure that everything is battened down and your belts and braces approach will ensurte that theirs no doubt that your setting the right paths.

Now as far as I can recall, paths under windows...

if you have lots of these \ then you are a path on a local machine and I always had issues when \ wasn't \\ in the local paths
if you have lots of these / then you are a path on a remote machine and always had a problem when \\ was returned as a path and it won't mix with /

So if you are getting a "local path" which is returning a path with \\path\\to\\file and you are appending \\path\\to\\file/intranet/common/light_me_up_baby.php to that absolute path with relative addressing, then you are going to have issues if the path can't be resolved properly... so as for calling the required files, why not just use paths relative to the root if your root folder has the "intranet" folder accessible to the other scripts, for example...

require_once("/intranet/common/core-settings.php"); over an absolute path, this is often where problems do arise and best off only using absolute paths when relative paths are not working, this is often a translation of links in servers and best left to the server until it needs a hand.

There are currently 1 users browsing this thread. (0 members and 1 guests)

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

"

"

## X vBulletin 4.2.2 Debug Information

• Page Generation 0.17174 seconds
• Memory Usage 2,971KB
• Queries Executed 15 (?)
Template Usage (33):
• (3)bbcode_quote
• (1)footer
• (1)forumjump
• (1)forumrules
• (1)gobutton
• (10)memberaction_dropdown
• (1)navbar
• (1)navbar_moderation
• (1)navbar_noticebit
• (1)navbar_tabs
• (2)option
• (10)postbit
• (10)postbit_onlinestatus
• (10)postbit_wrapper
• (1)spacer_close
• (1)spacer_open
• (1)tagbit_wrapper

Phrase Groups Available (6):
• global
• inlinemod
• postbit
• posting
• reputationlevel
Included Files (26):
• ./global.php
• ./includes/class_bootstrap.php
• ./includes/init.php
• ./includes/class_core.php
• ./includes/config.php
• ./includes/functions.php
• ./includes/class_friendly_url.php
• ./includes/class_hook.php
• ./includes/class_bootstrap_framework.php
• ./vb/vb.php
• ./vb/phrase.php
• ./includes/functions_calendar.php
• ./includes/functions_bigthree.php
• ./includes/class_postbit.php
• ./includes/class_bbcode.php
• ./includes/functions_reputation.php
• ./includes/functions_notice.php
• ./packages/vbattach/attach.php
• ./vb/types.php
• ./vb/cache.php
• ./vb/cache/db.php
• ./vb/cache/observer/db.php
• ./vb/cache/observer.php

Hooks Called (72):
• init_startup
• friendlyurl_resolve_class
• init_startup_session_setup_start
• database_pre_fetch_array
• database_post_fetch_array
• init_startup_session_setup_complete
• global_bootstrap_init_start
• global_bootstrap_init_complete
• cache_permissions
• fetch_postinfo_query
• fetch_postinfo
• fetch_foruminfo
• global_state_check
• global_bootstrap_complete
• global_start
• style_fetch
• global_setup_complete
• strip_bbcode
• friendlyurl_clean_fragment
• friendlyurl_geturl
• forumjump
• cache_templates
• cache_templates_process
• template_register_var
• template_render_output
• fetch_template_start
• fetch_template_complete
• parse_templates
• notices_check_start
• notices_noticebit
• process_templates_complete
• friendlyurl_redirect_canonical
• bbcode_fetch_tags
• bbcode_create
• postbit_factory
• postbit_display_start
• postbit_imicons
• bbcode_parse_start
• bbcode_parse_complete_precache
• bbcode_parse_complete
• postbit_display_complete
• memberaction_dropdown
• tag_fetchbit_complete
• forumrules
• navbits
• navbits_complete