I just installed WordPress in Heroku, now I wanted to add the plugin in WordPress but it does not allow me to add the plugin, no option is available for adding new plugin why? please help I'm in great trouble
Heroku is a bit unusual as hosting providers go. The filesystem your code is deployed on is ephemeral - any changes you make to it (like installing plugins) will be blown away a) the next time you deploy and b) at least once daily due to dyno restarts. In addition, if you're running multiple dynos, making changes on one won't reflect on the others.
What you'll need to do is install the plugins locally in your development environment, and check all the added files into the Git repository and deploy that to Heroku.
Related
I successfully deployed a Wordpress website on Heroku.
Here is what I did:
Download wordpress
Push all file on a Github repository
Create Heroku app
Link Heroku app to Github repository
Create clearDB database and update to wordpress config file
Deploy
Everythings is working fine. But whenever I update a file on the github repository and redeploy the heroku app, all user generated content are getting overwritten such as plugins and media contents.
How can I update my wordpress source code without losing any content?
Heroku has an ephemeral file system, meaning that any files that are saved to the Heroku instance while running, will be removed on your next application push. This is why there aren't many easy buildpacks for WordPress. All files "added" to your app have to be hosted elsewhere, like S3. Which makes it not necessarily ideal for a WordPress app without significant modifications.
I use Heroku for a lot of our infrastructure, but for WordPress sites I use Flywheel. (http://getflywheel.com) They have great support, have a handy local app that harnesses a virtual machine that is virtually identical to their live builds, and support intelligent Staging environments. I use DeployHQ to automate the build process similar to how Heroku does it. Pushing my repo will trigger a DeployHQ build to push code to Staging or Production, without affecting any user uploaded content/etc.
I'm still new to coding and I'm learning everything on my own. This is a silly question for you but after reading a dozen of articles I am still confused.
I have a php based website on a shared host. After reading the various articles on benefits of using repositories and Composer, I decided to give it a try. These are my difficulties so far:
Which version of the operating system of Composer should I download, to enable me to install/update repositories of my cPanel based shared hosting?
If I am to install Windows version, how do I connect to my shared hosting to install/update the repositories?
My apologies for my silly questions, but it would really help.
If you are using shared hosting, you are unlikely to be able to use Composer on the host itself. Furthermore, you are not encouraged to use Composer "on production".
I would recommend you use Composer locally (on the O/S of your local machine), to compose your project and install your dependent packages. Once it's all working and tested with your own code, you upload your entire development directory tree including the resulting vendor library - as one big FTP/SCP upload of "flat files".
Once you get more advanced you could adventure into automated deployment techniques, but I feel for now you would be best to stick to using Composer as a local development tool to manage your codebase.
Update, further details:
Composer is really a tool to help you manage your codebase in development. It's not intended as a "deployment" tool. Previously you used to find a library you liked, download it, unzip it into your codebase somewhere random like "lib/stuff" and then link to it, and commit it into your version control system (VCS). OK, but they a year later you want to update it and you have to download it again, figure out where you saved it and how to overwrite the files, or delete old ones... it gets hard. Also your VCS repository gets full of 3rd-party components - even duplicates of the same one! Composer solved this by bringing order to this long-term dependency management chaos.
The reason you don't want to run Composer "on production" (i.e. your live website), is that during the process of download, update, composition your website will probably be broken. Even if the composer process works, this could be several minutes of broken site. After the update has finished - you now have a completely new set of 3rd party packages: how do you know they are compatible with your codebase?
So therefore you only do composer updates locally, test everything, amend your code to work the shiny new updates, and only then do you decide to upload the whole new site to the server - just as if you'd cobbled it all together manually. The deployment is independent.
Being new to Wordpress development ecosystem have few queries which I m stumbled upon currently.
Have installed wordpress and it was working as expected. Had installed a theme to the website recently to the local working copy. Also, added 2 more members to the team which was previously single person and thus made the code version controlled with bitbucket server repository.
Now, the issue is when the new developers cloned the remote repository to their local machine ( entire wordpress with installed theme ) is available. But its not working properly as the new pages/links/menus/images added are not reflecting for the other's local .
Would like to know the general thumbrules which needs to be followed while version controlling Wordpress. Is the added themes/additional code changed files etc. only need to be version controlled instead of the whole Wordpress files? In my scenario what would be the changes I need to do ( any files which I need to configure to get the latest repository code to run locally )
Would we need to version control the Wordpress including the Database?
Please advise.
Yes the main issue you have there is all the things you want are within the database. There are version control things for db but not sure how best they work... so you either export and share you db with them, or all work off a remote db from a server. You can change db credentials, including ip address etc in wp-config.
As for version control, I only save my theme in git and the wp-config etc etc... the bare minimum I can. Then I use composer https://getcomposer.org/ to pull in wordpress and make use of https://wpackagist.org/ to get plugins.
Roots did a nice introduction to composer and WordPress - where I started learning from and is worth a look: https://roots.io/using-composer-with-wordpress/
I have installed a couple of Wordpress plugins on my local development server. When I deploy to the cloud, however, my plugins are not available.
I understand that the read-only file system prevents updating plugins from the deployed app as per this blog post, but is there a trick to getting locally installed plugins to deploy?
When you install the plugins on your local server, it should work when you deploy. No need for a trick.
Make sure you install the plugins to the plugins directory in your wordpress project which you deploy, and make sure you enable the plugins on the production server
I want to use GIT as version control for the PHP/MySQL web app I'm developing. I'm going with the server style setup since a couple of developers will also be working on it. I have the sandbox/dev server running (Ubuntu 10.10 server, LAMP package, CodeIgniter 2.01 framework) and its web root is /data/www/webapp.
How do I correctly set up GIT with my environment? Essentially how do I get GIT's "push to" or "I'm up to date and ready to test" directory the same as the web root (so I can just hit refresh in the browser and see the changes results)?
I'm still learning how GIT works so please excuse any incorrect use of terms. Also please no comments about other VCS systems - I'm sticking with GIT for sure.
Thanks in advance
One possible solution is to use a hook in your repo that will react to either new changes or a tag being updated that will export the new content into the appropriate location for your webserver.
The use of hooks makes things very flexible. There are hook points for quite a few actions in a repository and they can do just about anything (if you write it).