Mt - Local Site Path And Local Archive Path

[maggieroofus]

Up until today when posting photos in my blog I've just been using an "img src" link to where I have them hosted at SmugMug. Today I thought I'd actually try using the upload a file feature. Seemed easy enough ... yeah, right.

 

I've tried every path configuration that seems right and I keep having problems. The two main problems are either the photo not getting uploaded to the proper place or getting error messages about my path not being valid when I try to rebuild.

 

Here are the paths I have ...

 

Local Site Path

 

/home/cpanelName/public_html/index

 

Local Archive Path ...

 

/home/cpanelName/public_html/archives

 

When I try to rebuild with it set like this I get this error message

 

Writing to '/home/cpanelName/public_html/index/index.html.new' failed: Opening local file '/home/cpanelName/public_html/index/index.html.new' failed: No such file or directory

 

I'm at a loss. I've messed something up in my paths and I can't get it straightened out. Looking in my file manager, it seems as though I've done something at some point that has caused the site to rebuild inside my public_html/images directory as I have files in there with my template names.

 

Can someone plese tell me how the local paths should be?

 

Edited by TCH-David: Obscured CPanel username in directory paths for security purposes.

[TweezerMan]

Your Local Site Path doesn't look right, unless you really want to have your weblog in a directory named "index".

 

I think you probably should be using the following for your Local Site Path:

>/home/cpanelName/public_html

[maggieroofus]

Your Local Site Path doesn't look right, unless you really want to have your weblog in a directory named "index".

 

I think you probably should be using the following for your Local Site Path:

>/home/cpanelName/public_html

<{POST_SNAPBACK}>

 

I thin I finally got it. I had gotten it to where my entries were showing up, but they weren't showing up in my archives. Then I reset my local archive path to this ...

 

/home/cpanelName/public_html/archives

 

And now everything seems to be normal. I'm going to test the picture upload again (which is what started this whole mess in the first place) and see if it works right.

 

It sometimes amazes me how something that should be so simple can end up making you want to cry.

[maggieroofus]

Your Local Site Path doesn't look right, unless you really want to have your weblog in a directory named "index".

 

I think you probably should be using the following for your Local Site Path:

>/home/cpanelName/public_html

<{POST_SNAPBACK}>

 

It's all good now!

 

You guys have been life savers with this. I think I would have thrown in the towl by now if it wasn't for this forum. Seriously!

 

Thanks

Edited June 2, 2005 by maggieroofus

[marie b.]

If you want to prevent the .new error happening again, try adding the following to mt.cfg :

 

>NoTempFiles 1

[TweezerMan]

If you want to prevent the .new error happening again, try adding the following to mt.cfg:

>NoTempFiles 1

<{POST_SNAPBACK}>

This is what the MT Manual says about the NoTempFiles setting in mt.cg:

NoTempFiles

By default, when writing to an output file (for example, one of your index or archive pages), Movable Type will first write the data to a temp file, then rename that temp file. In the case that the process writing the data dies unexpectedly, this prevents the pages on your site from being erased. If you do not like this behavior (because it requires you to set directory permissions too liberally, for example), you can use NoTempFiles to turn it off.

Usually, when you receive an error about writing to *.html.new failed, it is because 1) the Local Site Path or Local Archive Path is not set correctly in mt.cfg, 2) the Local Site Path / Local Archive Path directories do not exist (you have to create those directories if they do not exist because MT will not create them), or 3) the permissions on the Local Site Path / Local Archive Path directories are not set correctly.

 

The creation of temp files while writing weblog pages is a good thing - if MT crashes or aborts in the middle of updating a weblog page, your original weblog page will not be deleted or modified. Setting "NoTempFiles 1" in mt.cfg prevents this feature from being used.

 

I have never encountered an MT installation where setting "NoTempFiles 1" in mt.cfg was necessary - it doesn't solve any problem that a user is likely to have. It usually does not eliminate the "Writing '*.html.new' failed" error - the error merely changes to "Writing '*.html' failed" instead, as the original problem (one of the three causes I mentioned above) still exists. You can use whatever settings you like in mt.cfg, but I wouldn't recommend using "NoTempFiles 1" to anyone.

[marie b.]

I think it's more a preferential thing - I should've noted that.

 

I receive .new errors sometimes, and none of the error-creating examples mentioned above hold true in my instance.

 

No temp files - no errors.

[TweezerMan]

I receive .new errors sometimes, and none of the error-creating examples mentioned above hold true in my instance.

<{POST_SNAPBACK}>

There are other possible causes of a "Writing to '*.html.new' failed" error - for example, a problem with an Archive File Template in Weblog Config | Archive Files, a problem with the "Output File Name" on an Index template, or incorrect settings for DirUmask, HTMLUmask, or HTMLPerms in mt.cfg.

 

I'd be willing to bet that if you said what you were doing when you receive the error, and what the error message was, the true cause of the problem could be determined and you wouldn't need to use "NoTempFiles 1" in mt.cfg to get around the error.

[marie b.]

I would, but I haven't gotten the errors since, and can't remember the specific one. I know it happened when I tried to create a new blog.

 

Either way, it's not an issue since I backup my templates whenever I make any change, and I know a lot of people who add the line rather than sift through lots of things to solve a minor problem.

 

Thanks, though.