Information for Developers - Revision history

Jmacgreg at 20:45, 13 May 2013

2013-05-13T20:45:22Z

Alec at 22:32, 24 October 2012

2012-10-24T22:32:40Z

Alec: Removed PHP4 info

2012-10-24T22:20:44Z

Removed PHP4 info

Alec: Removed CVS instructions

2012-10-24T22:11:04Z

Removed CVS instructions

24.84.195.154: /* Making Patches */

2011-06-14T21:45:37Z

‎Making Patches

Jerico.dev: Change title to better represent content.

2010-11-09T14:38:09Z

Change title to better represent content.

Jerico.dev: add deprecation to CVS title

2010-11-09T14:35:57Z

add deprecation to CVS title

Jerico.dev: Explaining solution to the "Client does not support authentication protocol requested by server" error.

2010-09-29T02:36:53Z

Explaining solution to the "Client does not support authentication protocol requested by server" error.

Jerico.dev: Downgrade CVS documentation, remove git incubation documentation

2010-03-05T02:42:10Z

Downgrade CVS documentation, remove git incubation documentation

Show changes

Jerico.dev: Corrected a typo.

2010-01-13T05:43:19Z

Corrected a typo.

@@ Line 1: / Line 1: @@
-= Bugzilla =
+= Managing Contributions =
 You can access our Bugzilla database [http://pkp.sfu.ca/bugzilla here]. We welcome any bug reports and feature requests, so long as they are understandably written and flagged correctly (mostly an issue of setting the severity between enhancement; trivial; minor; normal; major; critical; or blocker levels, although you can also set the priority as well if you'd like). You can see a great set of bug-writing guidelines [http://pkp.sfu.ca/bugzilla/page.cgi?id=bug-writing.html here].
@@ Line 5: / Line 9: @@
 You are also advised to [http://pkp.sfu.ca/bugzilla/query.cgi search] for similar reports to avoid duplication.
-= Patches =
+= Contributing Code =
-== Making Patches ==
+== Contributing via Github ==
-We're always happy to receive patches, whether for contribution to a project or for general community availability on [http://pkp.sfu.ca/support/forum the forums]. The one thing we do ask is that you provide the patch in [http://en.wikipedia.org/wiki/Diff#Unified_format Unified Diff] format. If you are using our [http://pkp.sfu.ca/wiki/index.php/Main_Page#Development_Topics git instructions] to work with the application codebase (highly recommended), you can create unified diffs via git using the following command:
+Contributing code via Github is our '''preferred method'''. Please see http://pkp.sfu.ca/wiki/index.php/HOW-TO_check_out_PKP_applications_from_git and http://pkp.sfu.ca/wiki/index.php/Frequent_git_use_cases for extensive instructions on the ins and outs of working with git repositories.
   git diff -u ./ > patch.diff
@@ Line 16: / Line 32: @@
-=== Applying Patches ===
+== Applying Patches ==
-If you want to apply a patch, download it to your development environment, and from the application's root directory and run
+If you want to apply a patch manually, whether from Bugzilla or from Github, download it to your development environment, and from the application's root directory and run
   patch -p0 < ./path/to/patch.diff
@@ Line 25: / Line 43: @@
 For more Windows (and general) information, also see [http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=3779 this forum thread].
 = Setting up a flexible development environment =
@@ Line 152: / Line 184: @@
   http -DPHP52 -DMODULE
   http -DPHP53 -DFCGI

← Older revision		Revision as of 22:32, 24 October 2012
Line 152:		Line 152:
	http -DPHP52 -DMODULE		http -DPHP52 -DMODULE
	http -DPHP53 -DFCGI		http -DPHP53 -DFCGI
		+
		+	= Collaboration with Github =
		+
		+	Please see http://pkp.sfu.ca/wiki/index.php/HOW-TO_check_out_PKP_applications_from_git and http://pkp.sfu.ca/wiki/index.php/Frequent_git_use_cases for extensive instructions on the ins and outs of working with git repositories.
		+
		+	To contribute code back to us, feel free to submit a pull request from git. (We can accept code in other forms, though pull requests are preferred.)
		+
		+	If you are working against a particular entry in our Bugzilla database, use the following format for commit messages:
		+
		+	1234 My Commit Description
		+
		+	...where the 1234 is the bug ID from Bugzilla. This allows Bugzilla to track back to the commits made in that entry and helps us assemble release notes consistently.

@@ Line 51: / Line 51: @@
 ** extension_dir must point to the absolute path of the version specific extension binaries
 ** enable extensions required by PKP software (e.g. database client, GD, etc.)
 ** optional: error_reporting, display_errors, log_errors, error_log, max_execution_time, xdebug
 * Test all PHP installations separately: /path/to/php -c /path/to/php.ini -v (This should discover most problems with wrong extension paths).
 == Install and Configure Apache ==
@@ Line 158: / Line 152: @@
   http -DPHP52 -DMODULE
   http -DPHP53 -DFCGI

← Older revision		Revision as of 22:11, 24 October 2012
Line 249:		Line 249:
	... = new ...		... = new ...
	in the caller. This is a little less efficient in PHP 4 but makes the code more readable and easier to maintain.		in the caller. This is a little less efficient in PHP 4 but makes the code more readable and easier to maintain.
−
−	~~= CVS Access (deprecated) =~~
−
−	~~CVS Access is now deprecated in favor of git. Please see our git documentation on the Wiki's main page. The following documentation is for those who don't have access to git.~~
−
−	~~== Web-based CVS ==~~
−
−	~~You can browse our CVS repository online [http://pkp.sfu.ca/cvs/cvsweb.cgi/#dirlist here].~~
−
−	~~== Command Line CVS access ==~~
−
−	(This is not a guide on how to use CVS. For more CVS information, try [http://www.nongnu.org/cvs/ here], [http://www.eyrie.org/~eagle/notes/cvs/basic-usage.html here], and [http://en.wikipedia.org/wiki/Concurrent_Versions_System here].
−
−	You can check out all CVS modules via anonymous CVS. Before you do so, you should know which modules, exactly, you want to work with. OJS and OCS each have a stable and devel branch; the stable branches are standalone maintenance releases (extensions of OJS 2.2.2 and OCS 2.1.1 codebases), while the devel branches also requires the PKP Web Application Library (WAL) be checked out and installed in the lib/ directory. Harvester2 and Open Monograph Press only have one devel branch, and each require the PKP WAL. Lemon8 is a standalone program with only one branch at the moment.
−
−	~~=== Setting up the Environment ===~~
−
−	The following instructions are more or less directly applicable to any *nix operating systems (OS X incl.); Windows users probably need to do things a little differently. Also, these are general instructions, pertaining to how I manage my own setup -- you might want to do things a little bit differently.
−
−	~~Firstly, create a CVS directory to store all your cvs checkouts in. I created mine in /Users/jmacgreg/ and then entered into the new directory, from which I ran the remaining commands:~~
−
−	~~mkdir /Users/jmacgreg/cvs~~
−	~~cd cvs~~
−
−	~~You'll then have to log into our CVS repository using our anonymous credentials:~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs login~~
−
−	~~You will be asked for a password — there is none, so just hit enter. After which you should be able to run the following commands to grab specific modules.~~
−
−	~~=== OJS and OCS '''stable''' branches ===~~
−
−	~~To grab the OCS and OJS stable branches, run the following commands:~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d ojs2-stable -r ojs2-branch-2_2_2 ojs2~~
−
−	The above command will download the current code for the OJS 2.2.2 branch of the ojs2 module, and deposit in a new 'ojs2-stable' directory in the directory you are currently in (you moved to your cvs/ directory, right?)
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d ocs2-stable -r ocs2-branch-2_1_1 ocs2~~
−
−	~~The above command will download the OCS 2.1.1 code into ocs2-stable/.~~
−
−	Setting this up to be served by Apache is up to you (I have it symlinked to my web folder). Remember, while this branch is still fairly stable in comparison to the heavily modified devel branch, it's still a work in progress and shouldn't be used in a production environment unless you know what you're doing.
−
−	~~=== Development Branches ===~~
−
−	OJS and OCS development branches, as well as the only Harvester2 and OMP (and de facto development) branches, all work a little differently: they all rely on the PKP WAL module as a dependency. The WAL module needs to be 'installed' (symlinking is fine) in each branches' lib/ directory.
−
−	~~First, checkout the packages you need:~~
−
−	~~'''OJS devel''' (2.3):~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d ojs2-devel ojs2~~
−
−
−	~~'''Harvester devel''' (2.3):~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d harvester2 harvester2~~
−
−
−	~~'''OMP devel''' (2.3):~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d omp omp~~
−
−
−	Now the tricky part. You need to download the PKP WAL (called 'pkp' in CVS) and either copy it or [http://en.wikipedia.org/wiki/Symbolic_link symlink] it to your devel instances' lib/ directory. I prefer symlinking, as I can do this for each devel instance I'm running, and only have to remember to update one directory.
−
−	~~Checkout the pkp module:~~
−
−	~~cvs -d :pserver:anonymous@lib-pkp.lib.sfu.ca:/cvs checkout -d pkp pkp~~
−
−	~~Symlink the module to eg. OJS' lib/ directory:~~
−
−	~~ln -s /Users/jmacgreg/cvs/pkp /Users/jmacgreg/cvs/ojs2-devel/lib/pkp~~
−
−	~~... and repeat as necessary for each application.~~
−
−	~~Alternatively, it is possible to change into the ojs2-devel/lib and create, what are called, relative symlinks:~~
−
−	~~cd ojs2-devel/lib~~
−	~~ln -s ../../pkp~~

@@ Line 9: / Line 9: @@
 == Making Patches ==
-We're always happy to receive patches, whether for contribution to a project or for general community availability on [http://pkp.sfu.ca/support/forum the forums]. The one thing we do ask is that you provide the patch in [http://en.wikipedia.org/wiki/Diff#Unified_format Unified Diff] format. If you are patching against one of the above CVS modules, the easiest thing to do is generate your patch using something like the following command (which will generate a diff of the entire directory you are currently in, for example ojs2-devel, against the entire cvs module):
+We're always happy to receive patches, whether for contribution to a project or for general community availability on [http://pkp.sfu.ca/support/forum the forums]. The one thing we do ask is that you provide the patch in [http://en.wikipedia.org/wiki/Diff#Unified_format Unified Diff] format. If you are using our [http://pkp.sfu.ca/wiki/index.php/Main_Page#Development_Topics git instructions] to work with the application codebase (highly recommended), you can create unified diffs via git using the following command:
 === Applying Patches ===

@@ Line 23: / Line 23: @@
 For more Windows (and general) information, also see [http://pkp.sfu.ca/support/forum/viewtopic.php?f=8&t=3779 this forum thread].
-= Testing your code with all supported environments =
+= Setting up a flexible development environment =
 NB: This is not a beginner's installation/configuration tutorial. We only highlight a few important differences from a standard installation as a help for experienced PKP, database, PHP and web server users.

@@ Line 247: / Line 247: @@
 in the caller. This is a little less efficient in PHP 4 but makes the code more readable and easier to maintain.
-= CVS Access =
+= CVS Access (deprecated) =
 CVS Access is now deprecated in favor of git. Please see our git documentation on the Wiki's main page. The following documentation is for those who don't have access to git.

@@ Line 314: / Line 314: @@
 Solves the problem in PHP 4 but causes a deprecation warning in PHP 5.3.
-This is especially problematic in our case as we use lambda functions for validation that are created in the constructor and often get $this passed in as a parameter. If we don't use ... =& new ... in the caller then changes made by the instantiating caller to the object later on will not appear to the validator in PHP 4. This leads to validation errors and can cause security vulnerabilities. In PHP 5.3 the deprecation warning will be raised on parse time. This means that the workaround no longer works. We have to switch of E_DEPRECATION in PHP 5.3 until we drop PHP 4 compatibility.
+This is especially problematic in our case as we use lambda functions for validation that are created in the constructor and often get $this passed in as a parameter. If we don't use ... =& new ... in the caller then changes made by the instantiating caller to the object later on will not appear to the validator in PHP 4. This leads to validation errors and can cause security vulnerabilities. In PHP 5.3 the deprecation warning will be raised on parse time. This means that the workaround no longer works. We have to switch off E_DEPRECATION in PHP 5.3 until we drop PHP 4 compatibility.
 Our solution to this problem is: