Tag Info

Hot answers tagged

12

I am not sure how much you know about using version control, but I recently switched from SVN to GIT and find that to be great! Though it depends in you live site's server has GIT installed (or will let you). I have a GIT setup on the live server also, running of a branch called something like production. Whenever I finish implementing / fixing something ...


11

I have a setup I'm pretty proud of, and it works extremely well for my team. General Structure I keep the entire installation under git. All changes, be it a system update, adding/updating a plugin, adding/updating a theme, go through the same workflow. Changes can be rolled back at a moment's notice. I have a deployment server (an old P4 desktop) running ...


10

I use Git for all my projects since it lets me work offline and that happens fairly often for me. Git can interface with SVN if you'd still like to use Git then push your plugins to WordPress.org. http://www.nkuttler.de/post/using-git-for-wordpress-development/ http://hakre.wordpress.com/2010/09/28/git-rocks/


8

The easiest way to create a patch is described here: http://wordpress.org/download/svn/ Can I create patches from older version or must I use trunk? You should create the patch against the same version you want it applied against. In other words, don't expect a patch created against WP 3.0.1 to apply cleanly on WP 3.1-alpha. If I'm working on a ...


8

WordPress moved to Subversion in 2003. Git (as a project) was started in 2005. Absent Doc Brown's flux capacitor coming to fruition, I think the reasons for SVN over Git are rather obvious. (Hint: they rhyme with "fistory", "finertia" and "forganizational fomentum")


7

I use SVN for version control with everything I do in WordPress development. I actually started this way because I needed SVN for plug-in development ... once I got started there, it was a natural extension to continue using SVN for themes and custom scripts on client sites. Plug-ins Since plug-ins are already hosted on WordPress' server, I just check out ...


7

Good news and more good news! First - all of the code related to WordPress itself and its repositories resides in version control system (Subversion). Among other things that makes publicly available sites with all code in plain sight: http://core.svn.wordpress.org/ http://themes.svn.wordpress.org/ http://plugins.svn.wordpress.org/ One not so obvious ...


7

Yep, you can pass the initial revision from which to start scanning: git svn clone -s -r387893 http://plugins.svn.wordpress.org/your-plugin/ You can hunt down that revision by using this command: svn log http://plugins.svn.wordpress.org/your-plugin/ The last line shows the earliest revision. Source: ...


7

Real answer, taking all the above into account: Regarding .svn directories: Subversion 1.7 was released a little over a year ago ( http://svn.haxx.se/dev/archive-2011-10/0152.shtml ) and the working copies no longer contain .svn directories in every folder. They contain a single .svn directory in the root, along with fairly substantial performance ...


6

I'm embarrassed to say that I am a bit clueless on the procedure used to update a plugin via tortoise svn even though my plugin has been on the repository for years and had over 300,000 downloads! Don't be. SVN can be tricky for a lot of people ... so let's go through things step-by-step ... This is what I've been doing so far. code the ...


5

Subversion doesn't work that way. You have a local copy and a repository ... only two systems. There's no concept of syncing a local copy to a local repository and a remote repository. I recommend you look into using either Git or Mercurial for your local development. Both systems allow you to have a local repository (for local source control) as well as ...


5

Externals, definitely. Set up your own SVN repo, then make WP as an external in the repo. I put it into a /wp directory. You can access the WP SVN as an external here: http://core.svn.wordpress.org/ I tend to use trunk. You can use a branch, if you really, really want. Branches get auto updated with minor releases (/branches/3.0 held 3.0, then 3.0.1, 3.0.2, ...


5

Eclipse PDT + Subclipse + X I'm using Eclipse that has SVN Integration. I think PHP Strom does so as well. I go into one of my trunk projects which are basically a checkout from WordPress svn repository. Then I edit the files I need to edit. Eclipse shows which are modified, I right-click a directory, select Team->Create Patch and I get offered all ...


5

Simply stop running svn commands, and/or delete all the folders named ".svn" in your WordPress folder and all child folders, which removes the Subversion metadata. There is no difference between the WordPress 3.0.1 release obtained using Subversion or as a tarball from the WP downloads page, save for the .svn folders in the former. WordPress doesn't know it ...


5

@articlestack According to the trac revision log you added a new directory under your root with the same name as the plugin. It looks like your whole root directory got copied to the new directory because it contains all the tagged versions and trunk. The plugin bot will not be able to find your newly tagged version unless it's in trunk or the new ...


4

Question 1: Should I switch to working with command line instead of Tortoise? will it be safer? No, tortoise SVN does everything you need to do pretty well and without the need for you to learn every command line command. I've used it plenty of time, and I never had problems that were related to it, the problems were related to me using it ;) BTW: Tortoise ...


4

Have a look at this older question: Easily Move a WordPress Install from Development to Production?. It covers migration and deployment of WP installations. For your more immediate issue, do backups of your database. Use a backup plugin (WP-DB-Backup is what I use, find it on the WP plugins repository) to handle this for you. You needn't worry as much about ...


3

A readme update may take a week or more. Sometimes it helps to update just the readme file again. The Last Updated field is … dead. One of my plugins still shows the date 2010-12-24, but I had three updates in the mean time, the last one a week ago. The whole system feels like an old windows. :)


3

For local dev I use tortiose-svn , it is really easy, there is no learning curve, it takes about 10 minutes to learn and get up and running. If your looking for online or multi-collaboration I would look into Git, especially if your using a Git friendly editor like vim. Here is a huge list of interfaces and editors that work with Git, scoll down to 2.1 ...


3

More then likely it is personal preference. Some people like the workflow introduced by SVN, and some just don't like the distributed model of Git. Some like the way commits, branches, tags etc are handled in one revision control over another. It could also be that they where using SVN before Git was stable enough and they don't want to go through and ...


3

I run a WordPress checkout of trunk, a branch, or a tag. This way I can switch WordPress versions easily: svn sw http://svn.automattic.com/wordpress/trunk svn sw http://svn.automattic.com/wordpress/tags/3.1 In wp-content/plugins I have a trunk checkout for each of my plugins: cd wp-content/plugins svn co http://plugins.svn.wordpress.org/stats/trunk/ ...


3

Dunc, glad you asked about this before it was too late for you. You have heard the right words. You are right, unfortunately the articles tutorials are not very much newbie friendly. Frist let me try to clear some terminology for you. The thing you need to manage your code and keep track of all the changes you make to your plugins is basically called source ...


3

You can try out the api.wordpress.org. Take for example the secret MP6 plugin: http://api.wordpress.org/plugins/info/1.0/mp6.xml The current version is given by: <version type="string"> <![CDATA[ 0.8 ]]> </version> and it looks like the previous versions are listed in the compatibility tag: <compatibility type="array"> ...


3

Here's a nicer, more automated approach (following this answer): class MyPlugin{ const OPTION_NAME = 'my_plugin_options', VERSION = '1.0'; protected $options = null, // default options and values go here $defaults = array( 'version' => self::VERSION, // this one should not change ...


2

You should store a version number for your plugin in the database (if you don't already, add this pronto), using that you can do this (note that this is pseudocode): if( $db_version < {your desired version} ) { // previous updates and such $db_version = $new_version; //put that in the database } if( $db_version < $current_version ) { ...


2

I do not know which OS and/or software you use but regarding SVN it's quite simple : $ svn co http://plugins.svn.wordpress.org/your-plugin-name Then you just have to add your files in trunk and/or maybe in assets (banner,screenshots). Then : $ svn add trunk/* and or : $ svn add assets/* Last step is : $ svn ci -m "initial upload" That's pretty much ...


2

Sure it is possible there is a great chapter about that in the Professional WordPress Plugin Development book (http://www.amazon.de/Professional-WordPress-Plugin-Development-Williams/dp/0470916222). I've already got a system for my premium plugins like that. Essentially you have to hook into the WordPress API requests and root them to your own API Here is ...


2

Not tested yet, but add_filter('upgrader_clear_destination', array(&$this, 'delete_old_plugin'), 10, 4); looks good. You will find it in wp-admin/includes/class-wp-upgrader.php Remove the filter before updating your plugins. This could be a bit tricky because you have to search for the correct function name to be remove. Toscho wrote a post about ...


2

First, I think its important to consider what you are going to Version Control . I would recommend against putting the entire WP directory under VC. I think it makes the most sense to put wp-content/themes/YourThemeName under VC. For a large site with a high number of complex plugins I could see the case to including wp-content/plugins as well. If you ...


2

I do this with git and mercurial, just make sure you're using a private repo. Option 1. The only problem is the config.php, which you can tell git to ignore on push or before init. Use .gitignore or git update-index --assume-unchanged config.php (read a bit about the assumed-unchanged command before using it) Options 2. Use a conditional in the ...



Only top voted, non community-wiki answers of a minimum length are eligible