Access Problem in the Morning

Hi have a development site which I am working on which every morning throws the following error. After I log in to the manager everything is fine (no errors) and continues to be so throughout the day. Thereafter logging in or out and everything continues to be fine on the site. Next morning same thing.

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: include(../template01.php) [function.include]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: D:\inetpub\vhosts\mydomain.com\httpdocs\manager\includes\document.parser.class.inc.php(770) : eval()’d code
Line: 7

I have a template that uses an include to the template file that allows me to easily work on the template without putting it in the database.



The template file resides in the root so that images assigned to the template work the paths out easily and it is really nice to edit that way.

Any reason why this error is thrown?

If template01.php is in the root alongside the index.php file then I’d have thought the ../ wasn’t needed.

Make sure you have a <base href="[(site_url)]></base> tag in the template.

I’m guessing that the same template gets loaded (correctly) when you are in the Manager. That puts it in the MODx cache so it’s available in the front end, even though the front-end reference to it is wrong. In the manager, the preceding "../" works because the root is one level above the manager directory. In the front end, however, you’re already in the root folder by default (no matter where you are) so the "../" goes to the the wrong directory. You should be able to just remove the "../" in the reference. With the <base> tag, all references will be relative to the MODx root.

Hi Bob, Thank you for taking the time to reply to me. I went out to shovel snow and I am back.

I follow you on all you are saying.

I have had <base href="[(site_url)]"></base> in my template Head Section.

I totally agree with you on not having the ../ preceding the file name when the template is sitting in the root directory, however, just to make sure removed it again and it produces the following.

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: include(template01.php) [function.include]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: D:\inetpub\vhosts\mydomain.com\httpdocs\manager\includes\document.parser.class.inc.php(770) : eval()’d code
Line: 7

Parser timing
MySQL: 0.0024 s (3 Requests)
PHP: 0.0381 s
Total: 0.0405 s

I follow what you are saying about the cache loading when in the manager, it is just that what is happening does not seem to be logical to me either just as you were saying. That is why I wondered about something beyond my understanding.

For your info, I am on IIS. Also since I do not have modify access to the c:/windows/temp directory on my host for my session_save I created a temp directory with with the proper permissions and redirected as Jason indicated to do:
http://modxcms.com/forums/index.php/topic,4758.msg34281.html#msg34281

Thanks again for looking into this. Thomas

I know squat about IIS so it could be something to do with that.

Check the value of site_url system setting in Tools | Configuration.

Do you have an .htaccess file in the MODx root?

Hi Bob and also thanks David,

Thanks, At least there is consistency as every morning the same error

I had checked that but good to remind me. The File Browser URL is http://www.mydomain.com/assets/

I guess it is the inconsistency that bothers me. What I cannot understand is the action of logging in to the manager that corrects the problem. You explained your thoughts on it but it is hard to correct the problem when you cannot throw the error consistently. I did shut it down for five hours today and when I came back it threw the error again.

Tonight I am going to take the ../ reference out and see what comes up in the morning.
Is there a way to take it out of the cache after logging into the manager? I cleared the cache on Modx and even tried to call the includeFile snippet uncached but do not really know the results of that

On your other question, I do have the IIS equivalent to .htaccess in the root. My .ini is:


RewriteBase is off as it is not a function of this mod rewrite or used on IIS.

You’ll probably get better answers on the IIS forum section: http://modxcms.com/forums/index.php/board,220.0.html.

I see there are several threads there on Friendly URLs in IIS that might be relevant.

Thanks Bob, I will do so. Actually I have been over there a bit in the past.

For your info, I reloaded Evo on the server today. I had taken out the ../ in the includeFile snippet last night but that did not bring up the site this morning.

I have a duplicate "test" site that I used to get familiar with Modx on a separate domain that is personal. There I put the Modx install in a Modx subdirectory.
I used the [[includeFile? &file=`template01.php`]] as I’ve described there with no problems; with the template file in the root (modx/) Things work just fine there. So when I came to working up this new domain with Modx in the root did not think I would have this problem. I had used $database_connection_method = ’SET CHARACTER SET’; in the Test site and $database_connection_method = ’SET NAMES’; for the site that was having trouble. Saw some posts on problems with this and so last night rebuilt the database as Set Character Set. Now I have two almost identical sites (of course path configs are set for each), one sitting in a modx/ sub directory that works and one in a root that does not.

It’s an odd one. IIS must have some equivalent to the Rewrite Base directive somewhere. I would suspect that, but again, I know nothing about IIS.

BTW, changing a DB’s character set is an involved process. It’s not enough just to change the settings, you actually need to convert the data in each table/field to the new charset, otherwise, the settings don’t match the data -- so that could still be an issue.

Hi Bob,

I think that I found something. It is significant but do not know the entire ramifications. I am checking my host. Manage Files is not an area that I check regularly.

In Elements => Manage Files it returns

Invalid path "D:/inetpub/vhosts/mydomain.com/httpdocs/"
Filename Modified File size Options
This directory is empty.
Directories: 0
Files: 0
Data: 0 B
Directory writable? No.

That is what is in File Manager Path settings so I am going to check on why this is not coming out properly even though [(filemanager_path)] placed on a page returns the same path.

Also, since it shows directories not writable I did double check the write permissions on the directories and they were correct.

Maybe this is a corrupt install? What do you think? I did also do an upgrade install since the problem started.