Submitting Bug Fixes

Patching bugs is a great way for developers to contribute to the Shopp project. If you are familiar with HTML, CSS, PHP, MySQL, javascript, jQuery, or you have developed heavily on WordPress or Shopp, your skills can be put to great service to the rest of the Shopp community.

How do we judge bug fix sumbmissions?

While we can't say that your patches will always make it in, we can say that the more experience you gain in the Shopp codebase, the better your patches will be, the more attention you'll gain from us, and the more likely we will accept your submission. Also, there are perhaps hundreds of little changes that may not even change the functionality of the code, such as mis-pellings and unclear inline documentations, poorly formatted code (hopefully fair), missing translation string function calls that can help the project.

Here are some guidelines you can follow to help maximize your time:
1. First, we recommend that you become familiar with the WordPress Coding Standards, as these guidelines will make for much cleaner, readable code.
2. If fixing the "bug" would require radical changes to the Shopp architecture, it is likely that it's either too problematic to go into a bug-fix release, or is going to require some discussion with the Shopp core developers before a path to fix the bug.
3. Work up gradually to wide-scale patches. If we don't know you or trust you, we aren't likely to accept a lot of code from you, even if it is well written, because of the effort of checking over your code. This project runs as a meritocracy, build trust by being a solid, reliable, thoughtful, communicative, and careful developer.
4. Be mindful of where we are in the development cycle. If you don't know, ask. Come talk to us on the #shopp dev channel on irc.freenode.net. New features and radical re-architechture are unlikely to go into a maintenance release cycle. Consider writing a plugin to implement your new features, and bring it up during the next major development cycle.
5. Submit your bug fixes as patch files. If you have never made a patch before, see below. Do not upload entire modified versions of your file to the bug tracker, as it will take longer for another developer to determine what you changed in your patch.

Creating a patch file from diff

If you don't have Subversion access, which is true for most people, you can create limited patch files using the GNU diff program, part of GNU Diffutils

Diffutils is generally easy to obtain for Mac and Linux.

For Windows, see GNUWin32 Difftools. You may also need patch, see GNUWin32 Patch

To create a patch file, execute the diff command at the command line:

diff -u old/Shopp.php new/Shopp.php > Shopp.diff

The above command will create a Shopp.diff file (text file), containing a list of changes from the first file (old/Shopp.php) to the new file (new/Shopp.php). Upload the diff file that you created to the bug ticket you are working on. If your fix requires changing more than one file, create a diff file for each file that you have changed, and also upload those.

Be sure to note in your comment the version of Shopp that your patch applies to. Examples Shopp 1.2b1, Shopp 1.2b2, etc. If there is a newer prerelease version of Shopp, apply your changes to that newer version before creating your diff file.

If you have developer key access, you have access to nightly builds ( "Bleeding Edge" in your Store Account ). If you have built your diff patch from a nightly build, make sure you are using today's, and include the most specific version information.

Example, In Shopp.php look for the line that defines the nightly build:

define('SHOPP_VERSION','1.2b1 r2087');

Providing accurate version information will let another developer who is attempting to apply your patch, and test the fix, to see how fresh or stale the patch is. In some cases, your patch may become stale, and the testing developer will tag the thread stale and ask you to resubmit your patch, if it can't be applied to the recent pre-release or bleeding edge version of Shopp.

After you have uploaded your patch file for the bug ticket, tag the ticket patched and review to indicate that you would like your fix to be reviewed by other developers.

Creating a patch file from Subversion

Shopp, like many open source projects, uses Subversion for version control, however unlike some for-profit open source projects, because there is no "binary" distribution of Shopp, Subversion access is limited only to developers that are trusted and actively participating in the project, and not open to every common joe.

If you are fortunate enough to have Subversion read access to the project, you can use svn diff to create patch files. See Subversion Developer Commands for more information on working with Subversion to create patch files.

As above, upload your svn diff patch files to the bug ticket, and tag the ticket patched and review.

Applying a patch

Using the patch command from the command line, you can apply a diff/patch file to your working copy of Shopp. If you are helping to verify that the patch file fixes an issue, remember to read Verifying Fixes and follow that process.

The command, in general to apply the patch to your working copy is:

patch -p0 < patchfile.diff

The above command would apply a patch file named patchfile.diff, which was created using svn diff or just diff as above. If successful, the patch command will tell you what files were modified. If for some reason it failed, such as the patch file being stale, or if you executed the patch command from a directory which patch was unable to find the target file from, you may have to take action.

For stale patches, (make sure you are using the correct version of Shopp to patch too) tag the ticket stale and ask the submitter to submit again. For other errors, make any necessary corrections, such as specifying the target file to patch.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Plugin e-commerce for WordPress

Shared Ticket Bins

1.3 Development23% complete

 

Completed 23 of 102 tickets