I am making a woocommerce website and I was wondering what is the best way to update plugins (details) and still be able to update the plugin.
For example, I have two plugins that I just want to change the content in them like the currencies in woocommerce writes د.ب which is in Arabic Bahraini Dinar and I wanted it to be BHD.
Also another example I wanted to change in the wc-vendor plugin the namings instead of calling them vendors I want to call them artists.
I been reading articles about the best methods to update a plugin but I am not sure if they are also valid if I just wanted to change the "Naming" not "functionality"
https://www.seedprod.com/customizing-wordpress-plugins/
Summary:
I appreciate if you can tell me how to change plugin content and still be able to update it.
Thanks!
If you're using plugins developed by others, you may have more problem again in the future if the plugins update. Ask the developer or create an issue regarding the problem. Unless you're writing it of your own, you can play the changes locally or create an staging environment. If sound no problem, that's the time you need to replace code in plugins directory.
I assume, upstream developers are not able or willing to provide hooks for your need.
If you really must modify a plugin, put the plugin source code in a version control system (Git, Mercurial, ...). Make a branch for your changes, and each time a new upstream version comes up, import the upstream version and forward merge your modifications.
Related
I'm currently trying to duplicate the WordPress instance my customer is running to do some testing before changing something in the live version. Sadly I can't figure out how to get all Data including the Woocommerce WebShop on my own Test-Server. My Test-Server is freshly installed and runs WordPress with MariaDB. All the Data I got from the customers Server is located in a Folder with the Name "www.WEBSITEOFCUSTOMER.at", I can't go higher into the Folder Hirarchy due to restrictions of his WebSpace Provider.
This is the Content of the "www.WEBSITEOFCUSTOMER.at" Folder
At some point it looked like I could just copy it over into my /var/www/html/wordpress/ but that destroyed my Test-Instance.
Assuming that I understand that you don't have deep and well knowledge about migration/transfers, I will suggest you to use the Duplicator Plugin to make your job without any issues. This plugin can packaging all your data in one file and then moving to another server/folder etc. you can extract the package with new address. But one notice here: You have to read how Duplicator works, then understand the process and then start to transfer. One good point to understand how the plugin works is to search on youtube where are many guides and examples to see. If you do one time you will not forget for ever. Like a bike in example ;)
Hope this help and if you meet any trouble during the process do not hesitate to ask again for further information.
I've edited my page defaults in concrete5 and have a frustrating problem - when I add a composer control, I cannot push the change to existing pages. When adding e.g. a page title it works:
but when adding a composer control there's no option to push it to child pages.
This basically means that I have to recreate all my pages if I want to take advantage of the new default component.
Is there any kind of a solution?
This is a C5 bug that is still waiting to be fixed. If memory serves a fix was added to the core but I think it turned out to not be totally solving the problem and was pulled back.
You might want to update to the latest version and see if it fixes the problem but really no guarantee.
The only other alternative is to make sure you really plan your page types well before using them. I know it sucks a bit.
I've searched a lot about this problem, but I didn't found a "perfect" solution. I am using Wordpress with GIT and I'm currently using this gitignore:
https://gist.github.com/salcode/9940509
My question is on the plugins management:
It's very useful to have plugins tracked across environments and this gitignore tracks them unless you ignore specific plugins (like hello.php ecc..) which is fine. The problem is when the plugins have been updated. The files will sync because they are tracked in the GIT repo, which is ok. But what if the updated version of the plugin needs a DB update/upgrade, too? If so, you must always deactivate and activate again all the updated and pulled plugins to ensure eventual tables of the plugins are synced, too.
Do you have a solution for this problem or it is better to not track the plugins at all and install them manually on each environment which is a little bit frustrating to me?
Thanks
You can inject Plugin dependencies with TGM Plugin Activation
This library allow you to make an list of plugins that need to be installed in your theme/plugin. Is very easy to use and give you an better control (force activation/desactivation, private/git plugins, etc).
This way, you don't need to track the plugins folder.
Much better, you can track only your project this way (the plugin or theme only).
NOTE: Even if you use this tool, always integrate with external plugins safely (detect if it is activated, if function exists, using hooks and filters, etc). This way your project cannot crash WordPress.
I'm updating an existing wordpress site making significant modifications the the theme and site structure, as well as making updates to plugins which in turn store their data into mysql database.
As far as I'm aware there are 2 (3?) possible strategies here:
'Dump-and-load' MySQL database from DEV to LIVE and replace wp-content folder with latest updates.
Import changes via WP-importer and replace wp-content folder with latest updates.
Make database changes manually via WP admin interface and replace wp-content folder with latest updates (this is useful only for minor changes).
While I am developing in my own separate environment this is for an existing website which is currently live and will continue to receive updates from the public such as comments and entries into contact forms, hence I expect the database to be different now from when I release my changes.
Given this the options above provide the following problems.
1. DUMP AND LOAD
The 'dump-and-load' strategy seems to be out of the question as my data is being updated behind the scenes (this would have been my preferred approach as this is easily rolled back).
Result: requires synchronising databases post release to get latest updates, TOO COMPLICATED.
2. USE THE IMPORTER
Using the WP-Importer plugin page and post IDs will get updated, screwing up styling that relies on the post IDs to get activated. This in turn creates a CSS nightmare that I wish to avoid, having to go though the CSS after release to update the new page/post IDs with the ones the database created.
Result: Too finicky, not very professional approach leading to long and complex release process.
3. UPDATE DATABASE MANUALLY
This option is great for small changes but when for more complex releases the list of steps to follow on the PROD interface becomes long and hard to follow, making it easy to make mistakes.
Result: Too easy to screw up, only a last resort.
IS THERE A STANDARD WORDPRESS RELEASE STRATEGY FOR EXISTING WEBSITES?
So basically, my question is: What release process do other wordpress developers follow when UPDATING an existing website? Is there an option that I have not listed below that minimizes hassle and reduces time and complexity during release?
I've set up source control for the site using GIT and I am used to automating things via ANT or similar release script, this may be overkill for the current project but would be ideal to at least know of a simple way to update a wordpress site and minimize the chances of screwing it up.
Thanks!
I don't think this is particular to WordPress, it's a similar situation to any custom site. I personally favor replaying the SQL changes on production that were made on dev. The tricky part is that you have to know what SQL changes were made. For example a certain plugin may make some schema changes when you install it - you need to know what they were. You can do that by creating an export of your DB as SQL before installing a plugin, then take another export after and do a diff on the files.
Since you say you're making the modifications then I might assume you know what SQL changes you are going to make? Just make sure all changes you make to the DB are in the form of SQL script files and not just editing using the GUI (you can use the GUI to help write the queries, but save the actual SQL). After all of your changes are done you should have a bunch of SQL scripts that you ran during your development process - you can re-run them in order without encountering errors.
Then when it's time to push to production, create a staging version of production (that is take a fairly current DB backup of production). Run your update scripts on that and test that everything is ok. If it is, then you can run on production.
definitely make a backup of production before running any changes on it!
The guy behind WordFence was working on a deployment plugin called
Deploymint.
There's a new one called WP Stack.
Metal Toad Media discussed using Capistrano, but that Capistrano isn't specific to WP.
CrowdFavorite launched a service called
RAMP.
Needless to say, you have some other options. If you're making db changes manually make sure you're working with the serialized data effectively. I recommend using Search and Replace DB. WordPress also had a great little trick for changing the site url entirely from the wp-config file.
I assume you have everything running in a test environment. I would then:
Create a new database in your live environment.
Preload it with all content and configurations for the new site.
In your test environment, configure your config.php to point to the new database.
Upload all files to the live server. Upload your config.php last.
This will minimize downtime.
How can you start making changes inside a WP theme and then keep track of them for future them updates ?
You can use some sort of version control software like subversion to track updates. Also in terms of just "hacking", it is all based in PHP so you can just drop into your theme and make changes as needed to any of the files as they pertain to what you want to do. For example in order to make any sort of changes to the header, typically you would edit the header.php file.
One way would be a version control system like Subversion.
My experience has shown that it is best to go with a very well developed and customizable theme (occasionally paid) that allows you to make the majority of changes within the theme's settings rather than hard coding them. When the theme is updated by the author, while not impossible, I find it is rare they've butchered something from a previous version. If they did, they'll often offer not only a reason but a possible work-around.
Another think would be to have a testing environment where you can try out new releases of a theme without risking harm to your live site. Just google 'wordpress testing environment' and that should point you in the right direction. For the record, I run XAMPP on a spare windows pc for this process.
Last bit of advice: if you do make any changes to your theme, back the theme files up regularly. In the event something does go haywire, you wont have to design the site from scratch.