Templates permissions for end users

[newtech1]

I never let end users have the ability to add new templates or edit existing templates. But I have one user I want to allow the ability to add a new personalized template and do edits on it online. However, there are permission issues.

I have scanned the template file and it is in their folder. But if they go to the template editor, they can see all the files, but they cannot delete or edit any of the files. I have permissions turned on for them, but must be missing a step somewhere.

Can someone tell me all the steps to take to make it so they can edit: folder/file permissions for their template folder (777?), what permissions to check in admin control panel, permissions for individual user, etc.
Want to make sure only they can edit templates.

[jondaley]

Different webhosts uses different permissions on their files, and we don't have a good way to make it work for some of the hosts. The template editor is one place this pops up. If you don't need to copy templates very often, you can simply chmod the directories and files after they are copied. I think the editor will work fine from then on.

As for permissions in the admin, the template editor has a couple of permission settings, and you simply give the template editor permission to the user you want. I think there is a site-wide permission, and a blog-specific permission.

[newtech1]

If you don't need to copy templates very often, you can simply chmod the directories and files after they are copied. I think the editor will work fine from then on.

What permissions would give them. I have tried 777 and the end user still cannot edit any of the files. They can see all the files listed, so obviously they can in theory use the template editor (have permissions turned on)

[jondaley]

What error do they get? Anything in your apache log? Does the directory have appropriate permissions?

[newtech1]

Does the directory have appropriate permissions?

That's one of the questions I asked in my previous post-what are the appropriate permissions?

Interesting enough, I just went back into their template editor (had not changed any settings), and I can now edit files. However, one of the templates has subfolders-assets and styles, that when you click on them, there is nothing shown in the folders. However, there are subfolders and files in these folders. I have made the assets and styles and their subfolders 777, but still cannot see the subfolders or files when using template editor.

There is no error message that comes up.
And regarding my apache log, it is not showing ny kind of errors-seems to be the case the first day of each month after they clean it up for the previous month.

[jondaley]

"Appropriate" depends on your server. Certainly 777 should get rid of all permission issues except for those servers running safe mode, which then probably restrict directory location, and ownership and things like that on top of regular permissions. I heard that safe mode has been removed in future versions, which will be a great thing when the "regular" web customer gets that.

[newtech1]

I just tried the template editor own my own administrator blog. Here is what happened:

I edited a template footer. When I went save it, got the following error message:
There was an error updating template file.

I then checked my apache error log. This is what it had:
line 50: [client ] PHP Warning: mkdir() [function.mkdir]: Permission denied in /html/blog/class/file/file.class.php on line 318, referer: http://www.mydomain.com/blog/admin.php? ... r.template

I went to the file.class.php and here is the code around line 318:
There was an error updating template file.

Code: Select all

function createDir( $dirName,
                           $mode = FILE_DEFAULT_DIRECTORY_CREATION_MODE )
       {
             if(File::exists($dirName)) return true;

             if(substr($dirName, strlen($dirName)-1) == "/" ){
                 $dirName = substr($dirName, 0,strlen($dirName)-1);
             }

             // for example, we will create dir "/a/b/c"
             // $firstPart = "/a/b"
             $firstPart = substr($dirName,0,strrpos($dirName, "/" ));           

             if(file_exists($firstPart)){
                 if(!mkdir($dirName,$mode)) return false;
              chmod( $dirName, $mode );
             } else {
                 File::createDir($firstPart,$mode);
                 if(!mkdir($dirName,$mode)) return false;
              chmod( $dirName, $mode );
            }
         
          return true;
       }

This is line 318:

Code: Select all

if(!mkdir($dirName,$mode)) return false;

Does that give any clue why cannot save edits in template editor?

[jondaley]

Since the mkdir failed, it means the parent directory permissions are inappropriate. If you think they are set correctly, you should ask your host why the mkdir is failing.

[newtech1]

So, in this case the parent directory would be blog_1. And the permissions for this directory currently is 777. So that would mean there is something else not correct on the permissions regarding owner permissions on the hosting side. Am I tracking correctly?

[jondaley]

Your host probably has a setting that says that the www-data user cannot write to files in directories that it created, or something like that. You need to ask your host.

[newtech1]

Just did a test on the template editor to load an image, this is the error:

line 49: [Fri Apr 10 22:52:59 2009] [error] [client PHP Warning: copy(./templates/blog_1/CBSShadedGrey/img//richsig.gif) [function.copy]: failed to open stream: Permission denied in /blog/class/file/file.class.php on line 402, referer: http://doman.com/blog/admin.php?op=blog ... lderId=img

Here is line 402

Code: Select all

  if (!copy($inFile, $outFile)) {




              // copy the file to the new location
              if (!copy($inFile, $outFile)) {
                  // The copy failed, return false
                  return false;
              }
           
              // Now delete the old file
              // NOTICE, we are not checking the error here.  It is possible
              // the the original file will remain and the copy will exist.
              //
              // One way to potentially fix this is to look at the result of
              // unlink, and then delete the copy if unlink returned FALSE,
              // but this call to unlink could just as easily fail
              unlink( $inFile );
           
              return true;;
          }

[jondaley]

The error is really before that - when the directory is created - that it is created with the wrong permissions for your server.