Wordpress theme edit file permission issue - wordpress

You need to make this file writable before you can save your changes. See Changing File Permissions for more information

Make sure you've the correct permissions to edit the files in your FTP or File manager in Cpanel. You don't have any permissions to edit the required files. Let me explain what the File permission is and how to enable it.
What are file permissions?
This is a method of administering access rights to certain files of your site. There are 3 types of permissions, read, write, and execute. Each of these types can be defined per a certain user group. These include owner permissions, group permissions, and public permissions. Some host’s security settings do not have the ideal WordPress permissions set by default, you’ll have to add this yourself. You don’t need to worry about all these technical details. All you need to remember is the number: 666.
Changing file permissions in FTP
This is probably the quickest way of changing the file permissions for all of your template files in one swift command. Open up your favorite FTP client, navigate to your template directory (with style.css, index.php, etc.) and select all .php and .css files. Do not select images or subdirectories.
You can press CTRL + A to select them all, and click while holding CTRL to deselect items like images. After selecting the File Attributes option from the menu, you can change all the permissions to 666. You’ll notice the the group and public write permissions will automatically checked off.
After pressing OK all the permissions to the files you selected should be changed to -rw-rw-rw-. You should now be able to edit them via the theme editor.
Changing permissions in cPanel
You can also do this in cPanel, although not in bulk (for the version of cPanel I’m using anyway). Open up the file manager, navigate to the template directory (similar to FTP) and click on the file you want to change permissions for.
Change each one to 666, as before. This could be useful if you don’t have access to an FTP client, or just want to selectively make files writable.
You may see different sources telling you to set everything to 777, which gives everybody full permissions. I wouldn’t recommend this. Although it would work, it may open up security holes on your site. The 666 permissions are just enough for the text files you’ll be editing.

I have fixed this by a command :-
sudo chmod -R 777 "filepath"

Related

Wrong permissions when uploading file on WORDPRESS (Windows server 2012)

I've recently moved my WP site from godaddy to a physical sever using windows server 2012 R2.
But I'm having problem uploading files using the Admin panel, After uploading the file, I can see it physically on the server (wp-content\upload\2017\10)
But I can't see it on the website it self.
I can only see the file if I'm changing it permissions on the server it self.
I've changed the permissions to the folder, I gave full access to the relevant users. But still, it doesn't work for new files\pictures I'm uploading via the wp admin panel
Edit:
I've notice that every time I come to change the folder permissions the permissions under CREATOR OWNER are always empty, Is it Related ?
Thank you very much for the help
When you upload a file, PHP sends the file to a temporary directory on your server's hard drive (usually C:\Windows\Temp) and then copies it over to the proper directory. Once the file has is initially put in the temporary directory, it gets the permissions of that directory. The problem is when Windows moves that file to the proper place, it keeps the temporary directory’s permissions, which can cause access problems.
The way to fix this is to change the temporary directory to a folder within your WordPress installation, usually wp-content/upgrade.
To do this, follow these directions:
Find your php.ini file.
Find the upload_tmp_dir line, and change it to the wp-content/upgrade folder.
Browse to this folder and verify that the permissions are set properly.
You should then have the ability to properly view all your images. You'll most likely need to select all the previous selected images, and change the owner of the files to the web folder owner. Then you should be good to go!
If you can’t upload an image at all, it’s probably because you need to give the IUSR account Read/Write/Modify permission on your wp-content folder. This will allow you to upload, and do the WordPress & plugin updates.
Once you have done that, all you need to do is give the IIS_IUSRS group Read permissions on your “C:\Windows\Temp” folder.
Make sure to notice that the two permission changes you make are not for the same user/group. Give IUSR permissions on your wp-content folder and IIS_IUSRS permissions on your Windows temp folder.
Note: If you have edited your php.ini file and change the upload temp directory then you will need to give IIS_IUSRS group read permissions on that folder instead.
That should do it, or at least it worked for me.
http://chris.wastedhalo.com/2011/01/wordpress-upload-permissions-on-iis-7-fix/
I find myself coming back to this question time after time when images I add to the Media Gallery don't have the correct permissions in the WordPress Uploads folder. Since I develop WordPress sites locally, it would be a pain to set permission on the Uploads folder every time I work on a new site.
To fix this, I created a folder "C:\Websites\Temp" without messing around with permissions or security settings, etc. Then in MAMP, I edited the php.ini template of the PHP version I was using for this site, php7.3.0.ini (File, Edit Tempate, PHP). I then set upload_tmp_dir to "C:\Websites\Temp":
; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
upload_tmp_dir = c:\websites\temp
and voila, no more permission issues.
Well, a few years later, found this post. Tried it. Failed.
Other solution is to assign a specific user to the site in IIS and apply the right permisions to the folder containing the site.

Why does a new default directory have user executable permissions where as a new file only has user read and write permissions?

Noticed this when creating a new directory in unix, and was just curious as to why this is so.
Thanks
A new directory created by a user and owned by the user with full permissions is no big deal. However, a new file/program if executed accidentally or before configuration could have catastrophic results. So the designers decided to give you a layer of protection.
It also prevents other users from executing the file unless you specifically grant permission.
Because you need the executable permissions to naviguate into the directory.
So basic permissions allow user to read file (read file permission), and to access file in directory (directory execute permission).
Note that read permission on a folder allow user to list files in it. (But doesnt allow to read them unless execute permission is granted too as I said in the first place)
Basically, +x on a directory means that the user can 'execute it' hence change into it (replace user by group or other depending on position in permissions).
Hence drwxr--r-- means only user can change into directory. More here.
The directory needs to have executable permissions so you can do things such as cd into it. Also the executable permission lets you look into the directory for inode information of the files it contains.
More info can be found at this source.

Wordpress directory Permission for Plugins and Themes

Is it possible to set permission for plugin directory to 554 because i am trying to set the permission for plugins directory and its files to 544 but its not loading the css and js files. same goes for themes .
General rule of thumb: Folders set to 755 or 750. Files set to 644 or 640. Important files (wp-config.php) should have more strict permissions like 600.
See more here.
I supposed the author was asking how to set file permissions to reinforce wordpress security. Instead of default 644, 755 by wordpress installation, he wants to try some custom permission values while still want wordpress work normally.
Here is the official codex page reference about recommended wp permmisions which may also take it as a reference cause no one has concrete widely tested sample yet:
http://codex.wordpress.org/Changing_File_Permissions
Furthermore,What i'd like to share with u is that
while i'm studying on changing the chmod via diff approaches, i found my mozila ftp user unable to change the chmod first bit value,
case1 : folder chmod value 755 in ftp view panel (such as the image below)
when you use full control ftp account (generated via cpanel)rightclick to view
attribute 755 and key in the value 644 then save.
the outcome is surprislying not 644, but 744 instead.
But in ssh command and cpanel file panel interface
will not have this kind of strange problem (1st bit didn't change)
in the chmod pemmsion settings.
In addition, I've also tried setting up apache passwd protection to certain folder as a way to enhance wordpress security, such as in the practice of adding .htaccess and .htapsswd to make wp-admin a password protected restricted directory, however, i found it not successful to implement on share-hosting server.
Below is another post discussing about wordpress security involving configuration of chmod and plugin compatibilities.
url: https://wordpress.stackexchange.com/questions/167900/evaluations-of-two-wordpress-security-plans-against-php-code-injection-attack/167905#167905
Thanks for this post and others' answer contributions :)
//2014 11 20
live testing of setting folder and file permission to 555 554 respectively and confirmed, the plugin folder and css js inside still working very well.
// firstly after testing, i found the permission can be set more strict than nromal ones mentioned in wordpress documentation link and still run normally.
all *.php file can be set to 544 to avoid writing permission or prevent injection
for normal folders usually 555 is okay,"wp-upload" folder needs a 755. if you set js, css to 544, you will get 404 error and of course they wouldn't be load, can set those folder to 555.
normally if you set the first bit to a stricter mode it's would not be able to use ftp software to modify, meaning if the file or folder has been set to 544, using ftp can not modify the chmod permission of the 1st bit. the complete modification should be using ssh or cpanel file management tools thus made the site files & folders more secure.

Files reappearing on server even after getting deleted

I am deleting files (wordpress theme files )of my website to the server using cPanel, but still the files are reappearing. The files have a 000 permissions set.
It is strange that files have proper permissions ( i.e. 777) when they are on my local machine, but on uploading they are getting changed to 000. Do you think the site is infected by virus ? I run an Anti-Virus scan, and found none.
Any reason why this may be happening?
chmod 000 denies read, write, and execute permission to yourself, your group, and everyone else.
How are the files uploaded to the server? Your FTP program might me screwing up the files when they are uploaded.
If you have root access you should be able to remove using $ rm -rf filename
Edit
The Umask settings on your server are not right. Setting Umask to 777 will make permissions 000.
If you have shell access you can check for 777 Umask values by running: grep 'umask 777' /etc/skel/.bashrc
If you find anything change the Umask to 022. If you don't have shell access your host should be able to fix this for you.
Instead of using the cpanel uploader use a an FTP program like Transmit for Mac or Core FTP Pro for windows and make sure to always use SFTP which is encrypted instead of FTP.
If you have the option, use FTP to manage your server files. It's more reliable than any web-based client.
If not, try changing permissions through cPanel to 777 before deleting them. If you are unable to do that, then contact the server administrator to resolve the issue (since it looks like a server/cpanel misconfiguraiton).
This is caused by the server recreating folders because you have subdomains or email addresses still attached to the domains related to those folders. Delete the subdomains and emails related to them and those folders will stay deleted.Happened to me before :)
Tim
backup other files in folder then delete folder.
create new folder with previous folder name (that was you deleted) and copy backuped files to it.
This may just work for other users who don't know how to do the techies, or who don't have shell access:
Check to see whether what you want to delete is a FOLDER or a FILE
If it is a FOLDER, check the permissions on that FOLDER and change to 755, do the same if it a FILE and simply delete
The issue here is that you have to open the FOLDER and CHANGE ALL SUBFOLDERS and FILES inside it to permission settings 755.
Delete the files from the inside of the SUBFOLDERS out then to the FOLDERS
This should perhaps help someone.

How can I edit files in c:/inetpub/wwwroot/testsite on vista/IIS7?

I've got IIS7 installed and have a simple website at:
c:/inetpub/wwwroot/testsite
I can copy files into there, but I can't edit them:
I can open them but cannot save them back
the files themselves are not write-protected
the folder itself ("testsite") IS write protected, so I took the write-protection off (right-click, properties, uncheck read-only, continue as administrator, etc.) and it pretends to change it but then always sets it back to read-only
What is the modus operandi for editing web files on IIS7 on Vista?
You have a couple choices:
Replace the permissions on the entire folder.
log on as administrator and do what you need to.
Note also that the c:/inetpub/wwwroot directory is UAC protected.

Resources