* Keep old entry points for preview plugins so people does not need to
do python setup.py develop
* Version checks should be done including the min_version parameter,
otherwise they will fail for 2.4, 2.5...
* No need to define different methods for different interfaces. If
running eg 2.3, the IResourcePreview interface methods will simply be
ignored.
* Simplified same domain checking
* Add note about these being eventually migrated to ckanext-geoviews
* Added docs
No need to choose branches, we'll aim to keep master stable and working
with different ckan versions (We'll keep the stable and release-v2.0
branches up to date for the time being)
Completely reviewed and refactored tests to support both CKAN 2.2/2.3,
geoalchemy 1/2 and PostGIS 1/2 (TODO test on PostGIS 1.5)
Removed all references to legacy ckan tests, and removed old or
incomplete tests.
This allows code in lib, model etc to not worry about GeoAlchemy
versions. This assume the correct library installed, as the check has
been done when starting up.
If using CKAN>=2.3 and GeoAlchemy2 is not installed an ImportError
will be raised with details about how to proceed. Added a section
on the Troubleshooting.
It seems like the best option for supporting both CKAN 2.2 (SQLAlchemy
0.7.x) and CKAN 2.3 (SA 0.9.x) with the same code base is to add both
GeoAlchemy and GeoALchemy2 to the requirements. As long as GeoAlchemy is
installed first, both will be installed and the SQLAlchemy install (the
CKAN requirement) won't be affected. Tested with pip 1.5.6 and 6.0.8.
When creating a minimal custom theme users may start with a blank read.html file and include only the secondary_content block. This will fail, as the template needs to start with ckan_extends.
When creating a minimal custom theme users may start with a blank read.html file and include only the secondary_content block. This will fail, as the template needs to start with ckan_extends.
fxia
amercader
Sol Lee
jqnatividad
David Read
Tom Kralidis
Tom Mortimer-Jones
John Brisbin