I followed this link to make my wordpress installation scalable on OpenShift http://gshipley-onpaas.rhcloud.com/scaling-wordpress-on-the-cloud. However, I think I have missed a step somewhere. My git repository does not contain any application wordpress file. I understood that that is the purpose. I only have plugins and themes on the application git. However when the second gear is started (due to scaling), only my files are deployed, not the wordpress installation itself. I must have done something wrong. But I don't understand why it doesn't deploy the wordpress files.
You can try using the wordpress developer quickstart (https://github.com/openshift-quickstart/openshift-wordpress-developer-quickstart) which included the base wordpress installation also, but you will still have to use an s3 plugin for your uploaded files.
Related
I have stanard wordpress installation on my server with all plugins, themes and stuff. Now I want to migrate to kubernetes server where I have already installed bitnami/wordpress. I see a bit other structure of files in bitnami/Wordpress installation on kubernetes where is only wp-content and config file in main folder of wordpress.
Can I copy normal Wordpress installation to Kubernetes image bitnami/wordpress installation from image installed by helm? How will be to do it best? Should I do it like normal wordpress website or other technique and tools?
Bitnami Engineer here,
The app's files are now inside the /opt/bitnami/wordpress directory. We recently updated all our WordPress cloud solutions to have the same directory structure. However, it seems that you have a previous version of the solution deployed in the cloud our you used the Bitnami installer in your server.
The easiest way to migrate your data from your current server to the k8s deployment is by using the All in One WP Migration plugin. The plugin takes care of saving all the necessary data so you just need to recover that data in the new deployment. You won't need to copy any other file from the deployment when using this plugin.
I know that the WordPress plugin directory is hosting site and not a listing site.
In order for your plugin to appear in the directory is to host your plugin with them using SVN.
I have used their SVN for a while and just wonder if I can instead use a GitHub repository and whenever I release a new version on GitHub it will automatically release an update on the WordPress sites which the plugin is installed.
I really think that if I used GitHub in hosting my plugin, it will not appear in the WordPress plugin directory? Am I right or wrong about it?
I want to use GitHub to release and at the same time, I want my plugin in the WordPress plugin directory.
I have tried so far following this tutorial: https://www.smashingmagazine.com/2015/08/deploy-wordpress-plugins-with-github-using-transients/
But this is for self-hosted plugins.
Unfortunately there's not a straight way to get what you're looking for. At the root of it, you need to have your Plugin hosted and maintained on their SVN.
That said, there are some Git to SVN Mirroring options available that, while a bit convoluted to set up (and sometimes providing mixed results) should be able to handle what you need if you can bear to walk through the initial set-up.
Check out the following gist: https://gist.github.com/kasparsd/3749872.
If you set it up properly, you'll be able to effectively deal with your plugin like it's hosted on GitHub where it will mirror itself into WordPress's SVN, so it will show up in the Plugin Repository.
Unfortunately I haven't seen it even broached as an issue since what, 2015? So the odds of native GitHub repo integegration at this point don't seem all that high.
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.
Openshift's default app generator sets Wordpress creation of sites to be a non-scalable version of their gears. I'd like to know if there is a way to set a scalable instance and install wordpress on it.
thanks!
I am working on this today actually and got a scalable wordpress site up and running on OpenShift. (www.runcloudrun.com)
I disabled the symlinks in the action_hooks and manually added my theme and plugins to the php/wp-content/themes and plugins directory. I also used a S3 plugin to store all of my media files on amazon s3 so my images and media would scale once OpenShift adds addiontal gears.
I am writing a blog post on how to do all of this and it should be posted later this week.
Edit to add the blog post: http://www.runcloudrun.com/?p=22
--
gs
You can checkout this AppFog solution. And if you visit his Github you'd find an OpenShift wrapper as well. These two might give you all the sparks it needs to think out a scalable solution on Openshift.
Just use the git source URL and create a new app with PHP. Once the app is created, add MySQL to it.
Once you've created the app, the important next step is to check in your modules directly to the Git repo.
By default, we wanted folks to be able to download plugins directly from Wordpress, but when you scale, those files aren't copied over. Also, the filesystem for each gear in a scaled app isn't shared, so modules uploaded after you scale aren't magically copied to all gears. Given that limitation, we decided to mark the QuickStart not scalable, so as to prevent unfamiliar users from getting into trouble.
If you're familiar with Wordpress just check those modules in directly to your source, and everything will scale.
While switching a WordPress site onto Git I looked for a .gitignore template. But I stumbled upon a reoccurring theme.
Fact: you don't want WordPress core files, or your server-specific configuration files etc., in your project's repository. You just don't. – Joe Bartlett
And the recommended GitHub .gitignore for WordPress excludes all wp-*.php files. Wordpress.gitignore.
Why is this recommended? Surely I’d want as many core files to be included as possible, otherwise I have to install WordPress on every server I deploy to.
If context helps, I’m deploying it to a load balanced network with two application servers and two database servers.
The only thing I keep in a repository is the theme, never any core WordPress files. In the readmes I keep track of what versions it works with.
It's probably not recommended to help discourage modifying the core files.
Another idea is to keep WordPress as a clean git repo with your themes as submodules, that way you can upgrade/rollback WordPress separate from your themes. This is also how I maintain sites that use frameworks.
This is recommended in order to keep only YOUR files into your repository. Then using a script (or something else) you can retrieve the WP sources.