Even i changed file permissions to 777 of wp-content nothing happened, i am not able to install wordpress plugins...
You have to update the plugins on your local instance and then re-deploy to App Engine as mentioned on this document.
This is also explained other tutorials such as this one, the reason for this is basically that the directories for WP are read only by default on App Engine, and since it's a managed service, you don't really have much control on the folder permissions.
Hope you find this useful!
Related
I'm using a Google Cloud instance and I have set up Apache2, MySQL and PHP (LAMP).
I then downloaded and installed WordPress.
However I cannot install themes and plugins via wp-admin. WordPress asks me for an FTP user, which I do not have.
Do I really need this?
I changed the permissions to 755 and changed the owner of the file and the wp-content folder
For some reason it had not worked before, maybe cache.
I just recently started by creating a EC2 instance on AWS. I used the Amazon Linux package. I changed the PHP settings to include the ability to upload files larger than 200MB. Got phpinfo.php working. Installed phpMyAdmin. Everything looked good.
Next, I installed Wordpress. It worked great. Then I tried installing a theme. Worked great. Then I started installing some plugins for that theme. Something made the site crash. I tried a few things, but since I couldn't go to the sites Wordpress Admin panel, it seemed hopeless. So I decided to start from scratch. I deleted the html directory (including wp-content) and dropped all the wordpress tables. I moved a fresh copy of Wordpress into the html directory, reconfigured the config.php file, and it recreated the Wordpress tables in the database. Seems to work great. When I try to upload a theme, it says:
Connection Information
To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host.
I noticed that wp-content didn't have a uploads directory, so I created one. That seemed to let me upload the theme, but it showed up as a media file. I moved it to the theme directory and that worked. But when I tried to upload a plugin, I got the same message as a above.
What happened when I deleted everything? Or rather, where was information stored that when I reinstalled Wordpress, it didn't create a uploads directory? I am fine with reinstalling Wordpress from scratch, but I don't want to reinstall the whole LAMP stack or redo the AWS instance. Any thoughts?
The issue is that your web server doesn't have the proper permissions to write to your content directory.
The WordPress Codex has some good info for proper file and directory permissions. Ideally, all files should have 644 permissions, and all directories should be 755 (no higher).
If you're still running into issues adding plugins and updating WordPress, you should heed the advice of the following (so that you don't have to enter FTP details into WordPress each time):
Any file that needs write access from WordPress should be writable by the web server. If your hosting set up requires it, that may mean those files need to be group-owned by the user account used by the web server process.
I'm migrating a WordPress site to Google Cloud using Click To Deploy. All as gone well so far except a folder permissions problem when migrated the current sites wp-content folder.
Steps I took to make this work...
I set up a new WordPress install by using Click To Deploy and tested that I could upload new images to the server.
Uploaded and installed my backup database and current site files. In other words, I overwrote the files on the new WordPress install.
Tested the site by changing my 'host' file to match the new Google Cloud IP.
All looks great on the front end but in the admin area I can no longer upload images for new posts or pages.
I know this is probably a permission issue but I can't figure it out. Please let me know if you have suggestions.
If you have a good sense that it's directory permission issues, a simple way to diagnose might be to create a new Google Cloud Project, create another click to deploy instance, ssh to /var/www and run ls -al and compare permissions between what you have today and what the default scheme is. You may have to descend down a few levels into the directory that holds user-uploaded files.
My guess is that when you copied your site onto your instance, you modified directories where your linux user account is the owner, and when you try to upload files, the www-data user (Apache) cannot write to those directories any more.
You shouldn't have any issues running chown when logged in via ssh. Please post the output or error messages of that command.
I've been trying to uninstall a magento plugin I've recently installed to reinstall it using Magento Connect. The log said that the plugin uninstalled successfully and if I go to the admin panel, the plugin's no longer there but when I went back to Magento Connect, the plugin is still listed there so I can't reinstall. Why is this happening?
Based on the answers, what I've tried so far are:
Clear cache through Admin Panel
Removed wordpress entry in core_resource
I've made sure wordpress xml in etc/modules is removed
I've made sure Fishpig folder in app/code/community is removed
Cleared cache in var/cache
Cleared cache in downloader/cache
Checked if there's xml for wordpress in var/package (there was none)
Reindexed magento
And none of this worked. The wordpress extension was still listed as installed in Magento Connect. I've been trying to uninstall repeatedly but it just won't go away even though the log said that the uninstall process completed. I've also tried reinstalling and upgrading. No success.
to remove the extension:
remove all the modules files, includeing the file which enables the module:
app/etc/modules/COMPANY_MODULE.xml
also make sure the entry is gone from the database by removing the correct entry in table:
core_resource
then refresh the magento cache
It should then disappear from connect.
Which module have you installed? Can you give me name so I can give you solution if possible for me. If module add new own tables in db then dont delete any module file otherwise may be magento crash. Its better way to uninstall from magento connect manages.
Clear the .cache folder in the downloader directory, in addition there is also another area where an xml can be present in var/package/
The package files are from magento connect so delete from here and have another check!
delete all files in var/cache/ and double check you are actually working in the right folder! if you have another caching system then clear it.
To delete the extension from Magento Connect (I believe you have already uninstalled it from Magento) you will need to delete the file var/package/Fishpig_Wordpress_Integration_{{version}}.xml
Thank you very much for all your help and time. I really appreciate it. I've managed to solve the problem. It's apparently a problem with permissions. I didn't realize soon enough that the permission for all folders had to be 777. I had most folders set to 777 except for 2 files on my etc folder (local and locals.xml) because of security issues. But after getting a go signal changing said permissions, I managed to uninstall the plugin and reinstall it. Now the Wordpress is fully integrated in the website with no problems and I've also returned the permissions for local and locals.xml back to it's original. Thanks again a lot for all your time.
I've got a WP site in a workflow that goes local--> git (beanstalk) --> dev server.
Everything seems to be working fine when I deploy, but I've noticed that I can't upload images via WP and it seems like it's a directory permission issue.
The error I get is: "The uploaded file could not be moved to /path/blah/blah...
Is this because the FTP user doesn't 'own' these directories/files (because they weren't created via the WP site / FTP account of the dev server?
Please let me know if you've got any brilliant work-arounds or insights. I'm stumped.
Thanks in advance.
This is because Beanstalk uses ftp to upload your files, that means the owner becomes the FTP user. If Wordpress then wants to access those files, it is no owner so it can't delete/alter them. You can use chown apache <filename> on SSH if you want to make apache (wordpress) owner again. But now Beanstalk can't overwrite the files for the same reason.
The way to go is use a .gitignore file to ignore folders like uploads and cache. You don't need them locally for development, if you do, just grab them once with ftp.
I use this one myself with some additions. It may seem weird at first, but it rocks when it all works. :)