Modified items

All recently modified items, latest first.

plone.app.controlpanel-2.3.8-1.lbn13.noarch: This package provides various control panels for Plone and some infrastrucuture to make it as easy as possible to create those with the help of zope.formlib. The general approach taken is to re-use as much of formlib as possible. This lead to the decision to use formlib's EditForm's functionality, as these provide the most automation found in formlib today. As a result of this decision we needed to take a slightly unconventional approach as EditForm's only work on one single context, as they are targeted at editing content objects, which usually are available as one context only. Control panels on the other side most commonly present settings from various sources and group these in a user-friendly way. In order to still be able to use EditForm's we introduce one abstract adapter as a middleware layer per control panel, that is used as the one context formlib's EditForm's need but internally pulls in the various settings from all the possible sources and pushes them back to the right places again. Following this approach a control panel consists of at least three classes: - An interface that describes the settings to be available in the control panel with the help of zope.schema. This gives us automatic type checking and some other basic validation of the settings. It also lets us specify vocabularies to be used for Choice-type properties. - An adapter implementing the above interface, exposing all the different settings as properties. As we don't want to have those control panels available all over the place, we restrict them to adapt the 'IPloneSiteRoot' only. Sometimes we use the 'SchemaAdapterBase' class from CMFDefault.formlib and the property wrapper 'ProxyFieldProperty' to automatically convert the values found in our site to the types expected by formlib and vica versa. For example we often need to store tuples while formlib expects sets, store encoded strings in site encoding rather than unicode or use Zope2's DateTime class instead of Python's datetime package. - And finally the form itself. We can use the common base class 'ControlPanelForm' to provide us with a consistent look and feel for all control panels. This is accomplished by using the 'control-panel.pt' template. For most cases this should be the only template that needs to be written. The 'ControlPanelForm' also provides us with two common actions and as a side effect overrides the 'handle_edit_action' in a Zope2-compatible way, where the default implementation needs the current locale to be present as part of the REQUEST, which is not the case in a Zope2 environment so far. The form is also the place to specify custom widgets for some properties. There are some custom widgets available in the widgets.py module in this package. While the above-mentioned works pretty well for simple cases it is not yet clear if it will work for complex control panels in the same way. Especially forms that use a multitude of actions (for example user/group management) or consist of more than one 'tab' (for example kupu but also smart folder settings) are not easily implemented so far. Hopefully we will be able to provide common helper classes and templates for those complex cases as well, though.

plone.app.contenttypes-1.2a1-1.lbn13.noarch: Introduction plone.app.contenttypes offers default content types for Plone based on Dexterity. This package replaces Products.ATContenttypes and will provide the default-types in Plone 5. It contains the following types: Folder Document News item File Image Link Event (Using behaviors from plone.app.event) Collection (this already replaces plone.app.collection which is no longer needed then) The main difference from a users perspective is that these types are extendable through-the-web. This means you can add or remove fields and behaviors using the control-panel "Dexterity Content Types" (/@@dexterity-types). The aim is to mimick the default-types as closely as possible. plone.app.contenttypes has been merged into the Plone 5.0 branch and will be shipped with the next Plone release: https://dev.plone.org/ticket/12344 Warning: Using plone.app.contenttypes on a site with existing content requires migrating the sites content. Please see the chapter "Migration". It can be used on a new site without problems. Compatibility Version 1.1b1 is tested with Plone 4.3.x. The versions 1.1.x will stay compatible with Plone 4.3.x. For support of Plone 4.1 and 4.2 please use version 1.0.x. Please note that they do not provide the full functionality. The future versions 1.2.x will be compatible with Plone 5 only and add support for plone.app.widgets Installation Add this line in the eggs section of your buildout.cfg eggs = ... plone.app.contenttypes If you have a Plone site with mixed Archetypes and Dexterity content use the extra requirement atrefs. eggs = ... plone.app.contenttypes [atrefs] This will also install the package plone.app.referenceablebehavior that allows you to reference dexterity-based content from archetypes-based content. You will have to enable the behavior plone.app.referenceablebehavior.referenceable.IReferenceable for all types that need to be referenced by Archetypes-content. What happens to existing content? If you install plone.app.contenttypes in a existing site all Archetypes-based content of the default types still exists and can be viewed but can't be edited. On installation plone.app.contenttypes removes the type-definitions for the old default-types like this: <object name="Document" remove="True" /> They are then replaced by new Definitions: <object meta_type="Dexterity FTI" name="Document" /> To make the existing content editable again you need to migrate it to Dexterity (please see the section on migration) or uninstall plone.app.contenttypes (see the section on uninstalling). Archetypes-based content provided by add-ons (e.g. Products.PloneFormGen) will still work since only the default-types are replaced. If you install plone.app.contenttypes on a fresh site (i.e. when no content has been edited or added) the usual default-content (Events, News, Members...) will be created as dexterity-content. Uninstalling To remove plone.app.contenttypes and return full functionality to old content and restore the AT-based default-types you have to install the import step "Types Tool" of the current base profile. Follow the following steps: in the ZMI navigate to portal_setup and the tab "import" in "Select Profile or Snapshot" leave "Current base profile (<Name of your Plonesite>)" selected. This is usually Products.CMFPlone select the Types Tool (usually Step 44) click "import selected steps" Any content you created based on plone.app.contenttypes will not be editable until you reinstall plone.app.contenttypes. Dependencies plone.app.dexterity >= 2.0.7. Dexterity is shipped with Plone 4.3.x. Version pinns for Dexterity are included in Plone 4.2.x. For Plone 4.1.x you need to pin the correct version for Dexterity in your buildout. See Installing Dexterity on older versions of Plone. plone.dexterity >= 2.2.1. Olders version of plone.dexterity break the rss-views because plone.app.contenttypes uses behaviors for the richtext-fields. plone.app.event >= 1.1b1. This provides the behaviors used for the event-type. plone.app.portlets >= 2.5a1. In older version the event-portlet will not work with the new event-type. These are the version-pinns for Plone 4.3.3: [buildout] versions = versions [versions] plone.app.event = 1.1b1 plone.app.portlets = 2.5a1 Plone-versions before 4.3.3 need to pinn more packages: [buildout] versions = versions [versions] plone.dexterity = 2.2.1 plone.app.dexterity = 2.0.11 plone.schemaeditor = 1.3.5 plone.app.event = 1.1b1 plone.app.portlets = 2.5a1 Migration To migrate your existing content from Archetypes to Dexterity use the form at /@@atct_migrator. For migrations to work you need at least Products.contentmigration = 2.1.3 (part of Plone since Plone 4.2.5) and plone.app.intid (part of Plone since Plone 4.1.0). Migrating Archetypes-based content to plone.app.contenttypes plone.app.contenttypes can migrate the following default types: Document Event File Folder Image Link News Item Collection The following non-default types will also be migrated: The AT-based Event-type provided by plone.app.event The DX-based Event-type provided by plone.app.event The Event-type provided by plone.app.contenttypes until version 1.0 News Items with blobs (provoded by https://github.com/plone/plone.app.blob/pull/2) Files and Images without blobs AT-based collection provided by plone.app.collection Migrations that might come in a future version: from ATTopic to Collections Please note that migrating versions of content is not supported. Only the current state of items is migrated without any content- or workflow-history. Migrating content that is translated with LinguaPlone Since LinguaPlone does not support Dexterity you need to migrate from LinguaPlone to plone.app.multilingual (http://pypi.python.org/pypi/plone.app.multilingual). The migration from Products.LinguaPlone to plone.app.multilingual should happen before the migration from Archetypes to plone.app.contenttypes. For details on the migration see http://pypi.python.org/pypi/plone.app.multilingual#linguaplone-migration Migrating from old versions of plone.app.contenttypes Before version 1.0a2 the content-items did not implement marker-interfaces. They will break in newer versions since the views are now registered for these interfaces (e.g. plone.app.contenttypes.interfaces.IDocument). To fix this you can call the view /@@fix_base_classes on your site-root. Since plone.app.contenttypes 1.1a1, the Collection type uses the new Collection behavior and the Event type utilizes behaviors from plone.app.event. In order to upgrade: First run the default profile (plone.app.contenttypes:default) or reinstall plone.app.contenttypes Then run the upgrade steps. Migrating default-content that was extended with archetypes.schemaextender The migration should warn you if any of your types are extended with archetypes.schemaextender. The data contained in these fields will be lost. You need to implement a custom migration for your types and dexterity-behaviors for the functionality provided by the schemaextenders. This is an advanced development task and beyond the scope of this documentation. Migrating custom content Custom content-types will not be touched by the migration plone.app.contenttypes and will continue to work as expeced. However if you'd like to migrate your content-types to Dexterity (you'll have to create these types in Dexterity first) you might want to have a look at the code of plone.app.contenttypes.migration.migration.NewsItemMigrator as a blueprint. Widgets When used in Plone 4.x plone.app.contenttypes uses the default z3c.form widgets. All widgets work as they used to with Archetypes except for the keywords-widget for which a simple linesfield is used. It is recommended to use plone.app.widgets to switch to the widgets that will be used in Plone 5. How to use with plone.app.widgets TODO How to override widgets To override the default keywords-widgets with a nicer widget you can use the package collective.z3cform.widgets. Add collective.z3cform.widgets to your buildout and in your own package register the override in your configure.zcml: <adapter factory=".subjects.SubjectsFieldWidget" /> Then add a file subjects.py from collective.z3cform.widgets.token_input_widget import TokenInputFieldWidget from plone.app.dexterity.behaviors.metadata import ICategorization from plone.app.z3cform.interfaces import IPloneFormLayer from z3c.form.interfaces import IFieldWidget from z3c.form.util import getSpecification from z3c.form.widget import FieldWidget from zope.component import adapter from zope.interface import implementer @adapter(getSpecification(ICategorization['subjects']), IPloneFormLayer) @implementer(IFieldWidget) def SubjectsFieldWidget(field, request): widget = FieldWidget(field, TokenInputFieldWidget(field, request)) return widget Once you install collective.z3cform.widgets in the quickinstaller, the new widget will then be used for all types. Information for Addon-Developers Design decicions The schemata for the types File, Image and Link are defined in xml-files using plone.supermodel. This allows the types to be editable trough the web. The types Document, News Item, Folder and Event have no schemata but only use behaviors to provide their fields. Installation as a dependency from another product If you want to add plone.app.contenttypes as a dependency from another products use the profile plone-content in your metadata.xml to have Plone populate a new site with DX-based default-content. <metadata> <version>1</version> <dependencies> <dependency>profile-plone.app.contenttypes:plone-content</dependency> </dependencies> </metadata> If you use the profile default then the default-content in new sites will still be Archetypes-based. You'll then have to migrate that content using the migration-form @@atct_migrator or delete it by hand. Extending the types You have several options: Extend the types through-the-web by adding new fields or behaviors in the types-controlpanel /@@dexterity-types. Extend the types with a custom type-profile that extends the existing profile with behaviors, or fields. You will first have to add the type to your [yourpackage]/profiles/default/types.xml. <?xml version="1.0"?> <object name="portal_types" meta_type="Plone Types Tool"> <object name="Folder" meta_type="Dexterity FTI" /> </object> Here is an example that enables the image-behavior for Folders in [yourpackage]/profiles/default/types/Folder.xml: <?xml version="1.0"?> <object name="Folder" meta_type="Dexterity FTI"> <property name="behaviors" purge="False"> <element value="plone.app.contenttypes.behaviors.leadimage.ILeadImage"/> </property> </object> By adding a schema-definition to the profile you can add fields. <?xml version="1.0"?> <object name="Folder" meta_type="Dexterity FTI"> <property name="model_file">your.package.content:folder.xml</property> <property name="behaviors" purge="False"> <element value="plone.app.contenttypes.behaviors.leadimage.ILeadImage"/> </property> </object> Put the schema-xml in your/package/content/folder.xml (the folder content needs a __init__.py) <model xmlns:security="http://namespaces.plone.org/supermodel/security" xmlns:marshal="http://namespaces.plone.org/supermodel/marshal" xmlns:form="http://namespaces.plone.org/supermodel/form" xmlns="http://namespaces.plone.org/supermodel/schema"> <schema> <field name="teaser_title" type="zope.schema.TextLine"> <description/> <required>False</required> <title>Teaser title</title> </field> <field name="teaser_subtitle" type="zope.schema.Text"> <description/> <required>False</required> <title>Teaser subtitle</title> </field> <field name="teaser_details" type="plone.app.textfield.RichText"> <description/> <required>False</required> <title>Teaser details</title> </field> </schema> </model> For more complex features you should create custom behaviors and/or write your own content-types. For more information on creating custom dexterity-types or custom behaviors to extend these types with read the dexterity documentation. Reordering fields provided by behaviors TODO Differences to Products.ATContentTypes The image of the News Item is not a field on the contenttype but a behavior that can add a image to any contenttypes (similar to http://pypi.python.org/pypi/collective.contentleadimage) All richtext-fields are also provided by a reuseable behavior. The functionality to transform (rotate and flip) images has been removed. There is no more field Location. If you need georeferenceable consider using collective.geo.behaviour The link on the image of the newsitem triggers an overlay The link-type now allows the of the variables ${navigation_root_url} and ${portal_url} to construct relative urls. The keywords-widget is not implemented and is replaced by a simple lines-widget unless you override it or use plone.app.widgets. Please see the section on widgets. Toubleshooting Please report issues in the bugtracker at https://github.com/plone/plone.app.contenttypes/issues. ValueError on installing When you try to install plone.app.contenttypes < 1.1a1 in a existing site you might get the following error: (...) Module Products.GenericSetup.utils, line 509, in _importBody Module Products.CMFCore.exportimport.typeinfo, line 60, in _importNode Module Products.GenericSetup.utils, line 730, in _initProperties ValueError: undefined property 'schema' Before installing plone.app.contenttypes you have to reinstall plone.app.collection to update collections to the version that uses Dexterity.

plone.app.contentrules-3.0.6-1.lbn13.noarch: plone.app.contentrules provides Plone-specific conditions and actions, as well as a user interface for plone.contentrules.

plone.app.contentmenu-2.0.10-1.lbn13.noarch: ============ plone.app.contentmenu contains the logic that powers Plone's content menu (the green one with the drop-down menus).

plone.app.contentlisting-1.0.5-1.lbn13.noarch: Listing and working with Plone content objects using plone.app.contentlisting This is valid for Plone 4.1 upwards. Many of the operations for customizations, templates, views and portlets in Plone are related to lists of content objects. Their sources can be different, although usually they are some sort of catalog search, the contents of a particular folder or a list of objects from a relation. To make it simpler to work with these, we have made plone.app.contentlisting, which ensures that lists of content objects always behave in the same way and according to predefined interfaces, regardless of what the source of the objects are. The integrator shouldn't have to care whether the list of objects came from the catalog, an ORM or they are the actual objects.

plone.app.content-2.1.3-1.lbn13.noarch: plone.app.content contains various views for Plone, such as folder_contents, as well as general content infrastructure, such as base classes and name choosers.

plone.app.collection-1.0.11-1.lbn13.noarch: plone.app.collection

plone.app.changeownership-0.3-3.lbn13.noarch: Introduction plone.app.changeownership as it sounds is a plone package to change objects ownership. Problem There is no way in plone to transfer ownership of all objects owned by an user to a new user. To delete a plone member in such case is not an option. Solution plone.app.changeownership makes easy to transfer ownership from one ore more members to a new member. It also can change content metadata, like Creators field.

plone.app.celery-1.0-3.lbn13.noarch: This package integrates the `Celery` distributed task queue into Plone. It allows you to configure Celery from your zope.conf configuration file, and make sending task messages honor the Zope transaction manager. Configuration ============= You can provide Celery configuration via the Zope configuration file. Here is an example:: %import plone.app.celery <celery-config celery> server-email no-reply@vandelay.com admins George Costanza, george@vandelay.com admins Cosmo Kramer, kosmo@vandelay.com <broker> host localhost port 5672 user guest password guest vhost / </broker> <celery> ignore-result true disable-rate-limits true task-publish-retry true <task-publish-retry-policy> max-retries 5 interval-start 0 interval-step 1 interval-max 0.5 </task-publish-retry-policy> default-queue default <queues> default dict(binding_key='default', exchange='default') feeds dict(binding_key='feeds', exchange='feeds') </queues> <routes> feed.tasks.import_feed dict(queue='feeds') images.compress image.compression.Compress </routes> </celery> </celery-config> You must use the `%import plone.app.celery` statement to import the Celery configuration schema. The top-level section always is called `<celery-config>` and that section must have a name (due to zope.conf limitations), but it's name is otherwise ignored. The Celery configuration is subdivided into namespaced sub-sections. Each Celery configuration key (as defined in the `Celery configuration documentation`_) consists of a namespace (such as `CELERY`, `CELERYD` or `BROKER`) and a configuration option (such as `HOST` or `ROUTES`); the only exceptions are the `SERVER_EMAIL` and `ADMINS` options. See the `Celery configuration defaults module`_ for a complete listing. Note that many Celery options make no sense in a Zope server context as you would normally only send task messages, not run a worker to process tasks. Using this subdivision, the ZConfig schema for Celery puts these options into a section for each namespace. Thus, all `BROKER` configuration is contained in a `<broker>` section, with each broker option lower-cased, underscores replaced with dashes. An option like `CELERY_TASK_PUBLISH_RETRY` thus becomes `task_publish_retry` in the `<celery>` section. The ZConfig schema enforces the type information set by Celery, and any option that takes a tuple (such as `CELERY_TASK_ERROR_WHITELIST` or `ADMINS`) can be listed multiple times in zope.conf to list all items. Options that take a dictionary (such as `CELERY_RESULT_ENGINE_OPTIONS` or `CELERY_QUEUES`) are configured in zope.conf using a new section with the option name, so in the case of `CELERY_QUEUES` add a `<queues>` section to the `celery` section listing each queue on a new line. Values are interpreted as python expressions. Some options are handled specially: * The `ADMINS` option takes a `name, email address` pair. * `CELERY_TASK_RESULT_EXPIRES` is listed as a time delta using ZConfig formatting. The set of suffixes recognized by ZConfig are: ‘w’ (weeks), ‘d’ (days), ‘h’ (hours), ‘m’ (minutes), ‘s’ (seconds). Values may be floats, for example:4w 2.5d 7h 12m 0.001s. * For the `CELERY_ROUTES` option, you can either specify python classes named by a dotted path or a python dictionary. By using the `%import plone.app.celery` line in your zope.conf configuration file, you automatically configure Celery to use the plone.app.celery loader. If you want to use a different loader, you need to set the `CELERY_LOADER` environment variable before the configuration file is processed.

plone.app.caching-1.1.8-1.lbn13.noarch: Plone UI and default rules for plone.caching/z3c.caching

plone.app.blocks-1.1.1-1.lbn13.noarch: This package implements the 'blocks' rendering model, by providing several transform stages that hook into plone.transformchain. The rendering stages are: plone.app.blocks.parsexml (order 8000) Turns the response in a repoze.xmliter XMLSerializer object. This is then used by the subsequent stages. If the input is not HTML, the transformation is aborted. plone.app.blocks.mergepanels (order 8100) Looks up the site layout and executes the panel merge algorithm. Sets a request variable ('plone.app.blocks.merged') to indicate that it has done its job. plone.app.blocks.tiles (order 8500) Resolve tiles and place them directly into the merged layout. This is the fallback for views that do not opt into ITilePageRendered. plone.app.blocks.esirender (order 8900) Only executed if the request key plone.app.blocks.esi is set and has a true value, as would be the case if any ESI-rendered tiles are included and ESI rendering is enabled globally. This step will serialise the response down to a string and perform some substitution to make ESI rendering work. The package also registers the sitelayout plone.resource resource type, allowing site layouts to be created easily as static HTML files served from resource directories. The URL to a site layout is typically something like: /++sitelayout++my.layout/site.html See plone.resource for more information about how to register resource directories. For site layouts, the type of the resource directory is sitelayout. It is possible to provide a manifest file that gives a title, description and alternative default file for a site layout HTML file in a resource directory. To create such a manifest, put a manifest.cfg file in the layout directory with the following structure: [sitelayout] title = My layout title description = Some description file = some-html-file.html All keys are optional. The file defaults to site.html. A vocabulary factory called plone.availableSiteLayouts is registered to allow lookup of all registered site layouts. The terms in this vocabulary use the URL as a value, the resource directory name as a token, and the title from the manifest (falling back on a sanitised version of the resource directory name) as the title. The current default site layout can be identified by the plone.registry key plone.defaultSiteLayout, which is set to None by default. To always use the current site default, use: <html data-layout="./@@default-site-layout"> The @@default-site-layout view will render the current default site layout. It is possible for the default site layout to be overridden per section, by having parent objects provide or be adaptable to plone.app.blocks.layoutbehavior.ILayoutAware. As the module name implies, this interface can be used as a plone.behavior behavior, but it can also be implemented directly or used as a standard adapter. The ILayoutAware interface defines three properties: content, which contains the body of the page to be rendered pageSiteLayout, which contains the path to the site layout to be used for the given page. It can be None if the default is to be used. sectionSiteLayout, which contains the path to the site layout to be used for pages underneath the given page (but not for the page itself). Again, it can be None if the default is to be used. To make use of the page site layout, use the following: <html data-layout="./@@default-site-layout"> See rendering.txt for detailed examples of how the processing is applied, and esi.txt for details about how Edge Side Includes can be supported.

plone.app.blob-1.5.9-1.lbn13.noarch: This package aims to be an add-on for Plone (>= 3.x) integrating ZODB (>=3.8) blob support, which allows large binary data to be managed by the ZODB, but separately from your usual FileStorage database, i.e. Data.fs. This has several advantages, most importantly a much smaller Data.fs and better performance both cpu- as well as memory-wise.

plone.app.async-1.1-2.lbn13.noarch: You will typically run plone.app.async in a ZEO environment, where you will have one or more worker instances that act as dispatchers carrying out jobs queued by your main zope instances. For the sake of simplicity it is assumed that you have one instance that can queue new jobs, and one worker instance that consumes them, both operating on a single database. * Each instance has to set the ZC_ASYNC_UUID environment variable in order to integrate properly with zc.async. * Each instance loads the single_db_instance.zcml configuration. The worker instance loads the single_db_worker.zcml configuration in order to setup the queue and configure itself as a dispatcher. For more details please look at the example buildout configurations included in the package.

plone.app-1.0.0-1.lbn13.noarch: plone.app module

plone.api-1.1.0-1.lbn13.noarch: The plone.api is an elegant and simple API, built for humans wishing to develop with Plone. It comes with cookbook-like documentation and step-by-step instructions for doing common development tasks in Plone. Recipes try to assume the user does not have extensive knowledge about Plone internals. The intention of this package is to provide clear API methods for Plone functionality which may be confusing or difficult to access. As the underlying code improves some API methods may be deprecated and the documentation here will be updated to show how to use the improved code (even if it means not using plone.api) Some parts of the documentation do not use plone.api methods directly, but simply provide guidance on achieving a task using Plone's internal API. For example, using the portal catalog (see 'Find content objects'). The intention is to cover 20% of the tasks any Plone developer does 80% of the time. By keeping everything in one place, the API stays introspectable and discoverable, important aspects of being Pythonic.

plone.alterego-1.0-2.lbn13.noarch: Now you see it, it now you don't! This package defines a dynamic module type that lets you create objects in the dynamic module on demand. Usage To use this package, you should: * Identify an appropriate parent module where the dynamic module will live. * Ensure that plone.alterego.dynamic.create() is called with this module and a dynamic module name. Typically, you'd do this in the parent module itself, so that the dynamic module is instantiated as soon as the parent module is imported. * Register a named utility providing IDynamicObjectFactory. The name should be the same as the full dotted path to the dynamic module. This utility will be responsible for creating the objects that inhabit the dynamic module.

plone-wc.pageturner-1.2.3-3.lbn13.noarch: This package is a Plone product that will add a Page Turner view to the PDF File content type. The result is that you'll be able to view PDFs much in the same way you can view them on scribd.com. It uses the open source project, Flex Paper, to display the PDFs. You can find information about it at http://flexpaper.devaldi.com/.

plone-4.3.3-1.lbn13.noarch: Plone is ideal as an intranet and extranet server, as a document publishing system, a portal server and as a groupware tool for collaboration between separately located entities. A versatile software product like Plone can be used in a myriad of ways. Look through the sites that use Plone section to see a variety of ways people have implemented Plone and Zope solutions.

perl-Geo-IP-1.40-2.lbn13.x86_64: This package contains Perl bindings for the GeoIP IP/hostname to country/location/organization database. This package requires Maxmind's GeoIP libraries but is often faster than other, similar modules.

perl-Geo-IP-1.40-1.fc18.1302272143kf.armv6hl: This package contains Perl bindings for the GeoIP IP/hostname to country/location/organization database. This package requires Maxmind's GeoIP libraries but is often faster than other, similar modules.

« Previous 20 items Next 20 items » 1 ... 2306 2307 2308 2309 2310 2311 2312 ... 2359


	Copyright © 2000-2024 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items