Which is better if you are not changing the plugins or if you aren't doing your own plugin, should I commit the plugin folder or add it to git.ignore file
As a general rule I'd say, if you are making any changes to an external plugin/library you should obviously commit it along with your solution.
If you are not making any changes, there is usually no reason why you'd want to do that.
However you will want to have some means of package management. If someone changes the version of that plugin, others need to get that same version updated upon git pull. Otherwise the dependant code may break. Hence if you are working with some kind of package manager and your plugin is treated as a package - your problem is solved. The packages themselves will be ignored by git, you will only version some kind of package configuration file and all will be updated regurarly by the package manager.
Now, if you do not have any package manager, then you will actually probably want to consider versioning your plugin code, even if you are not making changes to it. That way the person who updates the plugin to a new version (and it's probably going to happen with Wordpress pretty often), pushes the new version and it is updated for everyone with every git pull.
Related
I've used Git on and off, but we're making an effort to commit to it, so I'm needing some guidance.
I'm using JointsWP as my base for our WordPress themes. What I want to do is to clone a copy JointsWP, so I can pull updates from them, but not to push my own changes back to them. That I have no problem with, where I'm running into issues, is when I want to backup each theme we create as a separate repo on Github, to have a backup, and so we can share them as needed. When I clone the original JointsWP repo, I can't seem to figure out how to push change to my own new repo. I thought that a fork would be my answer, but I'm only allowed one fork of the original repo, and pulling updates to a fork makes it feel like that's not what they intended. I considered making a fork and branching off of my fork of the repo for each theme we're creating, but that's not really what branching is meant for.
I'm totally open to suggestions, I'd love to get my workflow right, and it's totally possible I'm thinking about this the wrong way. In summary, all I want is to make multiple WordPress themes, based on the JointsWP boilerplate theme, and be able to update those themes as the original JointsWP theme is updated.
Thanks!
I don't think that a whole new repo is what you're looking for.
I believe that a separate branch would be a simple solution to your problem.
create a new branch using
git checkout -b new_theme
And then you can have many branches in the same project. Then you can easily checkout each branch as needed using
git checkout new_theme or git checkout old_theme
Here, have a look Git basic branching
How can I modify source/templates of packages that I am using inside my Meteor Project.
For example, I download the package from Atmosphere, begin using the package and want to make some minor tweaks to the package.
What is the best approach to making changes to a installed Atmosphere package?
You should fork the package from the github source and make changes to your own version. If you think those changes might benefit others then you can make a pull request for your changes and, if the original author(s) agree, your changes can now benefit others.
If you make changes in the deployed package under your project directory then those will probably be clobbered the next time you run $ meteor update
If you're still curious as to where they live, look under /.meteor
I have been version controlling my WordPress site with Git and pushing to GitHub for quite some time. I develop locally, push to GitHub, and pull from GitHub to my production server.
I would like to scrap my current WordPress core on my local environment and replace it with a fresh new copy to then be pushed to GitHub and pulled to my production server.
My question is...am I going to run into any sort of tracking errors wit Git by replacing my WordPress core? Any other suggestions for me when I do this?
I handle this by adding the Wordpress core as a subrepository. WordPress maintains a mirror of their SVN repository on GitHub. Then you can update to a new version easily by going into the subdirectory containing the WordPress core files and checking out the tag for the current version:
git fetch --tags
git checkout 3.3.2
The repo also includes beta releases, if you prefer those.
Here's the guide that I used to set up this process: Install and Manage WordPress with Git
I understood you're talking about updating wordpress. You should note that, like documented in the update instructions, during update you should
check the requirements
take a backup of your database contents
disable the plugins you have
So all this you should do regardless. Also, you should be sure to update your database content, too, if needed.
Wordpress contains instructions on updating using svn, and it seems it is, according to them, a perfectly fine approach to have. I would see no major difference for you to do essentially the same thing with git, provided you can tell exactly which files are appropriate to store on version control and which aren't.
recently, i upgraded to Flex Hero 4.5 and created a new workspace. Then, i imported a project from the former workspace and started working. when i tried to upload the project from the new workspace to codereview, i got the error message: could not guess version control system. Are you in a working copy directory? How does one resolve this issue?
thanks
I have read somewhere that i need to checkout my svn but i thought that you only checkout when you want to get a folder/file from the svn.
Sounds like you've got a bit of a mess unfortunately. Hopefully you're not in the habit of doing a ton of changes without checking in. I would suggest you:
Back up your latest changes to a safe location
Check out the project from SVN into your new workspace (which is what you should have done initially) - creating a brand new project folder
Merge the changes you've made into the now-correctly-versioned copy of your project (you could do this by just copying files from the "latest"/project backup folder overwriting the SVN versioned files, but if you do--do NOT overwrite any .svn folders). You could also use a tool such as WinMerge or WinDiff to find differences between the two projects (of course ignoring .svn folders).
If you have a small number of changes it shouldn't be bad, but if there's a lot, you might want to follow SolarBear's branch suggestion, if WinMerge isn't going to cut it.
If I understand correctly your latest comment, you did a svn export on your code. The export command, as the doc mentions, creates a "clean" directory tree, i.e. without the .svn directory. So basically, these are files not controlled by SVN; also, you lose all the history of your files. The best way would have been, I think, to do a checkout in your new workspace and then work from there. It could take some time, but it's much easier to manage afterwards.
One possible way to make this work would be to checkout a clean copy your code somewhere safe and then merge your changes into this clean copy. However, if your trunk or branch changed a lot in the meantime, this could be very, very tedious. I could then suggest to branch your trunk, checkout that new branch, slowly merge your changes into that branch and when you're done and everything's working OK, merge the branch back into the trunk.
After months using Drupal for my websites I noticed module uninstall tab in the modules list.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
Thanks
When you uninstall the module, rather then just disabling and removing, you let the module clean up after itself, including:
Delete tables it created
Delete system variables it used.
So uninstalling is a good clean, for the health of your database. Things will work fine not doing it, but why keep unused tables in your database?
Note:
It's up to the module creator to create the code needed to do the clean up, so not all modules do this very well.
I've always uninstalled my modules by deleting their folders from filesystem (after disabling them). I was wondering if this is the wrong way to remove them.
The files used from a module is not the only thing a module leaves on a Drupal site; there are database tables, Drupal variables, cached values that still need to be removed, when uninstalling a module. It's also possible that a module adds rows into a database table created from a different module.
Deleting the module files, you are not removing any reference to the module contained in the table system. This means that if you are copying back the same module after you deleted it, and you did delete its tables, the module is not going to re-create the database tables it needs.
I would definitively say it is the wrong way to uninstall a module.
Uninstalling is sometimes needed, as hook_install() won't fire if a module is just disabled. So if for example a module has some corrupted data, disabling and re enabling won't remove that.
You will probably be ok in your approach. However one thing to be weary of is doing the following.
Disable
Remove folder
At a later date put module back again (not the same version)
Uninstalling.
The reason for this is hook_install() and hook_uninstall() should be mirror images of each other. Update hooks are used to keep a module schema and settings up to date with what is provided in hook_install(), if you were to use an updated module to uninstall (without updating) it will be trying to uninstall a different set up to what is expected. The risk is slim that something would go badly wrong, but it is worth being careful.
The uninstall tab will remove anything in your database related to the module. This operation requires the module to still be present in your modules directory.
Simply deleting the files isn't 'wrong', but it will leave unneeded cruft in your database. The uninstall tab will not remove the module files for you, you need to do that yourself as you have been doing.
Drush makes the module uninstall process much more pleasant, with something like:
drush pm-disable [module] // or its shorthand drush dis [module]
drush pm-uninstall [module]
In fact, Drush makes just about everything more pleasant (downloading/installing modules, dealing with install profiles, creating DB backups, and my personal favorite, updating your entire code base). If you're not already using it, I highly recommend giving it a try.
You can check this link - modules may have some additional uninstall instructions for them, but it looks like majority of them don't - that's why you didn't have any issues :)