The situation is the following one: A colleague of mine built a WordPress theme with some custom widgets which need to be configured through /wp-admin/widgets.php.
In the local copy that me and him have installed everything works fine (it's the latest WP, the production database and the theme from bitbucket). The production is ok, but it's impossibile to change the widgets options since every widget has a There are no options for this widget. label.
So I did a setup from scratch: I created a new WP-ready droplet on Digital Ocean, imported the database I have locally (1:1 production since I changed my /etc/hosts to point the production domain to my localhost) and cloned the theme, but still I got the same issue of production: Widgets were not customizable. Also there are no references to localhost in wp_option rows.
tl;dr: With the same database and the same files, the website works fine locally while in the production machine (AWS) and in the staging droplet (DO) widgets are not customizable.
May be there are some problems with moving to production,check this: Moving site from development to production , and this: How to migrate subsite from dev multisite to production multisite , hope these will help.
I just understood what happened: The custom widgets were using short tags (<?) to split up the HTML output, which directive (short_open_tag) is disabled by default in the production environment.
Problems like this are a pain to spot and I can do nothing but laughing thinking what we tried to understand the issue.
Related
Currently we have a WooCommerce webshop hosted on wordpress.com. This webshop was setup as a prototype and because of its succes we want to start developing the webshop further. We don't want to change the production website directly, but we want to develop inside a closed development environment (e.g. locally using docker).
I have tried to run the webshop locally by exporting all its data using the All-in-One WP Migration plugin. Afterwards I have created a docker environment with a wordpress and a mysql container. On the wordpress container I've also installed the All-in-One WP Migration plugin and I've imported all the data. It looked like this worked fine, but after a few clicks I saw that I could not navigate to any other URL besides the homepage. I have read online that the Wordpress codebase being used on wordpress.com differs from the default codebase which can be download on wordpress.org. So I think this means the wordpress.com export file can't be imported into a default wordpress container.
Because of this I've tried to download all the files on wordpress.com using FTP and run the website myself using a php container. This also didn't work, because I can't download all the files using FTP because of the permissions. I also contacted the support of wordpress.com, and they told me they couldn't sent me the contents of these files. But without these files, I don't know how I can run the wordpress.com website locally.
I hope someone can help me with getting the wordpress.com website to run locally in a development environment. A suggestion how we can implement a workflow where we can change the webshop in a development environment and deploy the changes to our production website is also very welcome.
Edit: For now I've chosen to run my site in a docker environment and write down all the changes I make locally. When I'm satisfied with the site locally, I will repeat the changes I made earlier on the production website. I've chosen this workflow because I don't really know the structures inside Wordpress. I don't know how I can migrate the files and database tables I need to switch theme, without overwriting the database tables I want to keep (e.g. WooCommerce orders table).
Have you tried running it on a localhost? MAMP is a good option for this.
https://www.mamp.info/en/
I have a live newspaper WordPress website with about 10 users updating it daily with about 2000+ unique visitors a day. I have a sum of about 30 posts a day added to my db and i host my own pictures.
My goal is to change my theme that has been used for over 4 years so smoothly that I don't experience much hiccup for my viewers.
I want a dev environment somewhere in my server that I can test my new theme with my current posts.
A solution I have in my head is to create a subdomain for example "dev.example.com" and deploy the new theme there and have two working wordpress themes with one database.
Is this even possible? I need to have my new theme that is in a dev environment have access to my live database.
What is the best practice for this situation?
for people looking into this like me, I will post my findings below and if you like you can comment to guide me or tell me what I'm doing wrong or right.
there is a wp-staging plugin that can be used but it seems to be paid if you want to push changes from staging version to production version of your website.
I have also figured out that another wp website can be installed on a subdomain that you can create through cpanel and install a brand new wordpress environment that is completely separate from your live site with its own db and config.
Since most of us don't have unlimited server resources its going to be pretty heavy to clone everything from live site to staging site and I figured they cant share a db because changes made to staging site can effect live site if they share a database.
So I looked over a very well summarized easy youtube video which basically explained the whole process for cloning your wordpress on your subdomain and using a new db, but this solution can be good if you have the server space and resources, for a website like mine i would guess that a local installation of wordpress would work.
One of the comments on that video was very usefull as well:
Just create a subdomain, install WordPress with Softaculous on the subdomain, install the All In One WP Migration Plugin on both the main site and the subdomain, export the file in All In One WP Migration on the main site and import it to the subdomain and vice versa, you have your staging.
I've transferred my database and entire Wordpress file structure over to the live site, but the live site is still looking for all its resources at localhost:8888/.
I looked back on what I did when getting started and I edited my gulpfile.js to include
var browserSyncOptions = {
proxy: 'localhost:8888',
notify: false
};
Thinking this was the issue, I switched it to proxy: $_SERVER['DOCUMENT_ROOT'], but still no luck. Any ideas for what I may be doing wrong?
Unfortunately I haven't been able to find a single bit of information about deploying an understrap themed site. Here are the docs for the theme though: https://understrap.com/demos/core/wp-content/themes/core-understrap/docs/.
I've transferred my database and entire Wordpress file structure over to the live site, but the live site is still looking for all its resources at localhost:8888/.
That is an easy to way to get into live server maintenance hell. UnderStrap is a unique theme package because it has strong npm dependencies running in the back-end that are appropriate for localhost development builds. For that reason, Here is an alternative approach I recommend instead.
Install a clean vanilla version of WordPress on your live server.
Install and activate UnderStrap.zip on your live server through wp-admin.
Import/Export your posts and pages from your local site, onto the live site. Add all media images. Adjust your settings, install your plugins, and clear your cache.
Now use the file manager in your C-Panel to only upload all modified theme files from your localhost to your live server.
Test your site, then go live.
That is more of a manual process, but it has its benefits. For one, you learn and see what each step looks like, you push up only what you need, you don't have localhost decencies running on your live site and the database is 100% targeted on live site content.
If you can access the wp-admin of your live site there's a great plugin called Velvet Blues Update URLs that you can install.
Install it, go to Tools > Update URLs and enter the localhost address and then the live site address.
Always works great for me.
Many developers have done this process by running its gulp dist when processing deployment. It will create dist folder which you can upload on the server. It contains all necessary files that supports running the scss. So try to use also the gulp dist-product as a "product" that the theme can be published and downloaded in the near future.
Trying to figure the best way to develop on plesk.
I would like to develop my wordpress website on a temporary url, and attach the production domain only when I am done developing.
From some reason I'm getting various dns errors, saw a guide referring to change of hosts file but it dosent seem like the perfect solution to me.
Any tips?
You may create the clone of your WP instance (staging) and use Plesk Git extension for developing this staging WP site. After making all necessary changes on staging non-public clone you can publish it to a production domain to make it publicly available.
In a wordpress installation we want to have our main site, and a staging site separated and different. Where in the admin interface you separate your staging area?
Let's say:
for production you will have: http://www.yourdomain.com/
but for staging we want to have: http://www.yourdomain.com/staging
Staging is the website that will be in production next.
Any ideas?
With Wordpress 3.0+ you might be able to create a network of sites or install multiple sites with an older version of Wordpress. The catch is I don't know of an easy way of moving the staging to production. I'm not entirely sure that will do what you want, but you may want to look into it.
Personally I'd think you'd probably be better off keeping your staging and production sites on 2 different servers and just do a copy over when you move to production.
I don't know of any instant, simple answers, but have you seen this article in the Wordpress support forum? It has some informed discussion and at-least partial solutions:
http://wordpress.org/support/topic/one-wpseveral-servers
If your staging site doesn't need any database modification, or custom forms/widgets for the backend, you can create a new theme, and test it in the preview mode. When done, you can switch the theme to the new one!