I'm creating new Wordpress project and I want to make it easily scalable. It will be hosted on AWS (EC2 + RDS). I set up autoscaling group + code deploy and Jenkins builds and deploy the project after pushing into master branch. Now I have following question:
Shall I move whole wp-content out of the server and put it in some place available from other machines in the network? It would allow to keep content separately from the core project code and have it in one location. I cannot just move it to another server, because WP requires it to be available from filesystem. I was thinking about moving it to S3, but it does not seem to be good idea.
Can someone more experienced with WP advice what is the best option here?
Related
I'm developing a website using Word Press (Elementor plugin) and I want to create a custom widget. I found a tutorial I want to follow (https://www.youtube.com/watch?v=Ko9i153o_iU), the only problem is that I have no idea how to access the code on my local machine to begin. From what I can tell, everything I'm doing is on the word press website, and the code isn't on my local machine. How do I go about getting the code onto my local machine so I can begin working with it in vscode?
You need a way to spin up local apache or nginx server and mysql, along with Wordpress. I suggest the app Local:
https://localwp.com/
Then, if you want to copy your production environment (your website), you need to get the files for the theme and any plugins onto your local environment. Local pairs with some hosting providers to make this easy. Otherwise you can install by downloading the files. Some hosting providers give you FTP or SFTP access to your site files. Figure out how you can gain access and download them.
Lastly, if you want, you can copy the database over to your local environment. There is a great plugin called WP Sync DB that does this for free. It can also be a way to push your local environment to your production environment, but I definitely suggest keeping backups if you are going to do that.
I'm currently migrating a wordpress installation to azure app services with containers. First I did a normal installation with everything inside the container for testing purpose. The performance was good and and things worked without problems.
Then I wanted to add the wp-content folder to a persistent folder, for this I created a file share and added it under Path mappings. This worked without problems and after the restart Wordpress could access the files.
But now every page load takes about 1-2 minutes and the page as whole is unusable in this stage. I double checked the the file share settings and everything else. Share is optimized for transactions and as soon as I remove the volume, the container is fast as light again.
Does anyone have the same problem? Any ideas how to fix this? This is a deal break for me tbh.
Thanks!
Not answering your question directly but an alternative is to use App Service Persistent Storage that store data in /home folder of the VM where your app is running. It should be a lot faster then using a File Share in a storage account. The ${WEBAPP_STORAGE_HOME} maps to the /home folder.
You need to enable by setting WEBSITES_ENABLE_APP_SERVICE_STORAGE to true in the application settings or by using the CLI:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE
For the continuous integration and deployment of websites, I am using this pipeline:
But for many CMS like wordpress, prestashop, magento and others, the configuration of the website and the installation of plugins is done in the back-office of the deployed website.
For now, I am building the docker image on top of the CMS base image, then replacing all the /var/html directory with the files in github. Then Kubernetes is deploying the containers and plug a database and a persistent storage
Hence, this is breaking my pipeline: imagine that someone is installing and configuring a plugin in the back-office, then someone else is doing a modification on a file and pushes it to github. The github repo doesn't have the info that a plugin was installed and will build and deploy a new image without it.
How to integrate all the modifications done in the back-office in my github repository?
The solution we use is an override of the DB class.
So we monitor a number of tables (Configuration, module, hook, etc ...) and we store all queries about it in a sql file.
So during commit, we also have a .sql actions to perform on the database side.
Once deployed, either you manually execute the sql, or a script detect that new SQL are present and executes.
In this way we are always up to date.
This solution we developed in the form of Prestashop modules to track all actions.
Regards
My (by any means not ideal) working solution:
Create plugins folder outside docker and symlink this folder in dockered /wp-content/plugins
recreate above in production
Then installing new plugin doesn't break CI flow but requires two independent installations and configurations, if you (or dev team) need to install something new.
So you basically treat plugin files same way as you already do it with DB.
Forgive me if this is an obvious question, but I am trying to figure out what the best way is of handling autoscaling of EC2 instances running WordPress such that their themes and plugins (along with their associated configurations) are preserved.
I am already able to decouple the data and content layers via RDS and S3, respectively, but I am struggling how to preserve the themes and plugins through an EC2 instance autoscaling event.
My EC2 instances are configured as follows:
EC2 bootstrap script installs WordPress onto blank Amazon Linux AMI
EC2 runs behind an ELB
Database is on RDS
Web content is on S3 (using W3 Total Cache plugin)
Plugins/themes are installed on the local EC2 filesystem
To preserve themes and/or plugins through an EC2 autoscaling event, I could:
Install the themes/plugins I need first, then upload the /wp-content/plugins and /wp-content/themes dirs to S3, downloading them automatically each time an EC2 instance restarts via the bootstrap script. DISADVANTAGES: need to update S3 every time i make a config change, not all plugins are installed neatly within the /themes subdir, and changes to one instance don't flow to all (need to restart the cluster everytime a change is made).
Install the themes/plugins I need first, then take an AMI snapshot of the entire instance. Use this AMI as a template when launching new instances. DISADVANTAGES: need to update the AMI every time i make a config change (seems tiresome), and changes to one instance don't flow to all.
Create a symbolic link out of the /wp-content/plugins and /wp-content/themes dirs, pointing to an EFS filesystem that is mounted on all EC2 instances. DISADVANTAGES: EFS can be a bit slow, not all plugins are installed entirely within the /themes subdir.
Anybody have any experience with this? Am I over-engineering this? Perhaps the themes/plugin files don't really change much throughout the lifespan of your WordPress blog (ie, once you're set up, you don't really find yourself changing them much), in which case maybe Option 1 (zip to S3 and download via bootstrap script) is the best option for me, and Option 3 (EFS) is over-engineered.
I would love to get your take on this if you have experience with this conundrum!
Thanks in advance!
You can take a look at this link:
https://cloudonaut.io/wordpress-on-aws-smooth-and-pain-free/
It provides a CloudFormation template that sets up an ASG backed by EFS, installs wordpress and some plugins there, uses RDS for their database, sets up CloudFront as CDN and a few other goodies.
I tweaked their template for our use case and added an extra ASG with spot instances, replaced all the VPC stuff with references to my VPC template and tweaked the LaunchConfig so it automatically sets up the S3 Offload plugin with a bucket created on my template. It also automatically sets up the certificate for the ELB and a few other goodies.
I thought that would be the end and that I would be able to forget about WordPress and leave another team to work on it. Wrong. They complained it felt sluggish and some plugins failed to install with timeouts (and installing them manually using wp-cli took way too long, one of them up to 2 minutes and a half).
So here my 2 cents: set up RDS and CloudFront, use a reserved instance for wordpress and offload your static assets to S3 using a plugin. Once the site is completely set up bake an AMI or take a snapshot of your EBS and set alarms so in case the instance breaks down you can quickly spin up a new one with your AMI/snapshot.
Either that or have your dev team baking AMIs from a dev environment so you can set up an ASG in your production environment with those.
I got to a point where I believe trying to set up WordPress for a non-dev team (meaning, they can install/upload plugins and themes from the browser) in an ASG is just madness without support from a dev team (baking AMIs, updating stacks). You could, of course, automate all of this. You could, of course, develop a full new site using anything else. Your call.
/rant
I have a simple Wordpress website that is created using twelve twenty. I need to transfer it from server to my PC to be able to edit it and transfer it back to server. Now that I copied wordpress directory from server to my PC it asks me to reinstall it. How can I do it? Am I missing something? Is it possible to work on website locally and once it is done transger it to the server?
Reason for doing this are:
-don't want to loss data for wrong doing things.
-have a copy of website on local machine.
-easier to work on the local machine offline rather than bing online and accssing the server.
From my point of view , i would suggest u to back-up full website and database from server [every hosting control panels has option to backup same]
Connect via ftp and edit ur files.. there to make lots of changes when u want to move from local to server or server to local.
cheers!!!
Editing the files on a live site directly is a terrible, terrible idea. It invites any number of points of failure. If you're actively developing a site things will break at some point - it's part of the developing process - and you definitely want to break things locally, not on a live site.
There's actually several steps involved, all of which are too long to go into great detail, but here's an overview of what is required along with a few links to get you started. The first time you do it seems laborious, but once you figure it all out it actually only takes 10 minutes.
Firstly you will need a local environment MySQL and PHP environment to install it. As you're on PC look at WAMP; here's a fairly good tutorial on installing it.
If you have a lot of content on the live site you might want to import it into your local environment; you'll need to export the database (probably using PHPMyAdmin) and then import it into your local database. You will need to update a couple of database options so that it points towards your localhost. It's basically the reverse of the process detailed here: you'll be changing your-site.com to localhost:8888. If your site is relatively simple you could skip this stage*
Now you should be able to update your local copy of wp-config.php with the database connect details for your local database (usually it's just localhost for the host name and root for the user and password`). With that in place you should now be able to install WP.
Now that it's installed you can edit away to your heart's content on your local copy, safe in the knowledge that anything you do on your local copy doesn't affect your live copy. When you're ready to push your changes live you can use FTP to copy your local files to your live environment.
* For a lot of projects I don't actually go to the trouble of synching databases - if there's a live site that the client can change the content on it often becomes a futile exercise attempting to synch a database with a moving target. In those instances I'll just use a comprehensive set of test content that contains every conceivable type of content that could possible inserted in to the live site.
your going to love working on your project from your locally. Here's an article I found on wpmudev http://premium.wpmudev.org/blog/how-to-install-wordpress-locally-for-pcwindows-with-xampp/ which gives you a step by step guide for PC / Windows.