Wordpress plugins and git sync across environments - php

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.

Related

How/Where does SuiteCRM compile the scss files in a theme?

I'm currently working on setting up a custom admin page for a specific task I need to do and it requires some custom styling in the theme. I went to the themes/SuiteP/css folder and found admin.scss. After making a change, I had assumed that Suite would dynamically compile the asset since I am developer mode; however, that did not happen.
I decided to search the code for any place I could find that would deal with compiling those files to *.css, but found no such place.
My question involves inquiring as to where that compilation takes place and/or how it takes place. Right now it appears as if I have to manually compile those assets, which seems pointless because it is just an extra step I have to manually take, rendering using SCSS less useful in comparison with CSS.
Right now, my solution will probably have to be adding a CSS file that has nothing to do with whatever pipeline exists, but if I can leverage existing functionality, that would great.
Due to legacy issues with the SugarCRM framework, SuiteCRM loads style.css for current theme. The sass work for SuiteCRM is in a transitioning period. It is currently a manual process, but we hope to make it automated in the future.
We are using Sass as a way to allow developers to customise the SuiteP theme. I have a github project which provides a UI to generate the variables.scss for you. I am hoping that it will be accepted in a future release.
So in regards to your workflow you only need to care about the style.css.
If you want to contribute back to the SuiteCRM project, then you will need to use the sass files in themes/SuiteP/css/.
However, if this is just for your instance of SuiteCRM, then you will want to create a style.css in the custom/themes/SuiteP/css/style.css. How you change that is up to you.
I would recommend that you use Sass to generate the style.css.
You can achieve this by copying the style.scss file custom/themes/SuiteP/css and then add the following to the file
#import ../../../../themes/SuiteP/css/style.scss
Note: I may have the path slightly wrong
or use the command line tools to include the themes/SuiteP/css/ directory
See for details:
SASS: Import a file from a different directory?
SuiteCRM should pick up the rest of the work. There is a change in SuiteCRM 7.9 that deprecates the $sugarcrm_version in favour of $suitecrm_version. This will effect theme themedef.php.
See for details
https://github.com/salesagility/SuiteCRM/pull/3233/files
I hope this answers your question.

Proper way to update WordPress plugin (for updates)

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.

Handle plugins with composer

I have been making a CMS as a project for a little while now, and am currently working on the plugin management section. Instead of building my own repository & update manager, I've been toying with the idea to use composer instead. The issue is I want the admins on the site to be able to add/remove plugins at will.
So I was thinking, how bad of an idea would it be to build a front-end which runs composer? Composer is just PHP after all, it's meant to be run on production environments (granted with a composer.lock file though), and it'd resolve all of my repository, update, and dependency needs.
I knocked out a quick test script, I built and passed in a custom configuration file (instead of composer.json, the installed plugins list is stored in the database), and everything seems to be working fine. But I can't shake the feeling of this being a bad idea.
Does anyone have experience with this, and whether or not it is a good or bad idea?
Using Composer as an embedded dependency manager with a front end is actually a very valid use case for it. Here are some links with information, as well as a project meant specifically to help with embedding composer into an application.
https://github.com/dflydev/dflydev-embedded-composer
https://sculpin.io/documentation/embedded-composer
http://srcmvn.com/blog/2013/05/23/symfony-live-2013-portland-embedded-composer

How to know if a wordpress plugin is safe

There are thousands of plugins and themes available at wordpress.org and many other third parties. There is every possibility of bad plugins and themes being uploaded, which once uploaded could send info about the site to its owner. It could also send the information in the wp-config.php (A high security risk).
Please tell me how to protect wordpress sites from this other than by reading the code line by line. Also tell me if plugins and themes at wordpress.org are analyzed by the wordpress developers for threats like this before making it available to public.
Thank you.
Peace to All....
As with any code you run on your own server(s), WordPress plugins are caveat emptor.
That said, popular plugins have probably had a fair number of eyes on their code, making it unlikely that they're doing something shady. You probably don't need to go over them with a fine-tooth comb before installing them.
Lesser-known/used plugins, however, should probably be looked over before you install them on a site/server that you care about.
WordPress.org does not review every bit of code that goes into plugins - the only time they even do any review at all is when the plugin is initially submitted to the plugin directory, and that's cursory at best (mostly just to avoid spam). A plugin's code can change drastically after it's initially submitted.
Typically I will look at the feedback the plugin received on wordpress.org What kind of rating does it have? What comments/questions are asked in the 'what others are saying' section.
After making the decision to install the plugin, BACKUP YOUR DATA PRIOR TO THE ACTUAL INSTALLATION.
This is just good practice in any case, whether it's a wordpress core installation, plugin installation, or theme. If something breaks, you will have something to go back to.
Also making sure to keep frequent backups is a must. If you do get infected, you will want a snapshot.
There is a good article about the safety and security of themes that best plugins for wordpress put together. Also you can go some off of the rating given by the community straight from the wordpress plugin site. If you keep with plugins that have a 4-5 star rating and lots of downloads/ratings, you will most likely be ok. However, because this is an open source project, there is really not a 100% way to keep hackers and "bad people" from putting code in a what appears to be good theme/plugin that you are describing.
In this case if you have concern of a theme or plugin, I would always look over the code very carefully and make sure that it all looks good to you. Of course this is always time consuming and if you are not comfortable with code, this may not be an option. If you have questions about a certain set of plugins/themes, im sure if you post them here, there are many people that have used the plugin and maybe the theme before that can help you out.
From "Best Plugins for Wordpress"
1 TAC (Theme Authenticity Checker) Plugin
A very simple and straight forward plugin that will scan all files within your theme to >>check for any malicious or unwanted code.
2 Theme-Check Plugin
You may notice that a lot of free themes aren’t available directly from WordPress.org, >>the main reason for this is that most free themes don’t pass the tests that WordPress.org subjects them too. This nifty plugin will provide you with all the testing tools you will need to conduct the same tests that WordPress.org does. It’s also useful for theme developers who want to make sure their theme supports the latest standards.
3 Exploit Scanner Plugin
This plugin isn’t just for themes, it’s for your entire site, so it’s worth keeping once you’ve checked out the theme you’ve decided to use on your site. It scans all files, posts and comments on your site for any possible exploits or anything that looks suspicious, please note however that this plugin will not remove any files.

How to edit a Wordpress theme and make it easy to update?

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.

Categories