Modified items

All recently modified items, latest first.

ftw.publisher.sender-2.2.0-1.lbn25.noarch: Introduction The ftw.publisher packages provide tools for publishing plone contents from one instance to another. By providing a simple mechanism to invoke the publishing, it's possible to set up the publisher in a variety of ways, such as workflow bound, manually invoked or automated publication. The ftw.publisher package library also provides a variety of surveillance and analysis tools for making maintenance confortable. Staging The ftw.publisher is meant to be used in a environment where there are two seperate plone-sites which do not share their database. The editors work on a editorial site and the contents are published to a public site when they are ready. Setting up such an environment with ftw.publisher let you have a powerful staging solution with completly isolated instances. Network security Using an environment with two isolated installations makes it possible to protect the editorial site with firewalls or to put it even in a private company network. This way the editorial site is completly protected from the internet, which is in some use cases mandatory for protecting other - unpublished - contents (for example when publishing the internet contents from the intranet). Component support * Archetypes objects * Standard Archetypes field types * Topics: criterias are published automatically when topic is published * Backreferences - references are added automatically as soon both objects are published * Additional interfaces added on /manage_interfaces or by other products * Contextual portlets * Properties With the publisher adapter structure it is as easy as creating another adapter to support other components. For instance annotations are not supported by design, because you may not want to publish all annotations but only certain ones. Therefore it is easyer to implement custom adapters for those annotations which need to be published.

ftw.publisher.receiver-2.0.2-1.lbn25.noarch: The ftw.publisher packages provide tools for publishing plone contents from one instance to another. This package should be installed on the receiver instance. It provides tools for unserializing publishing requests and creating, updating or deleting objects.

ftw.publisher.core-2.3.3-1.lbn25.noarch: The ftw.publisher packages provide tools for publishing plone contents from one instance to another. This package provides shared tools and utils used by ftw.publisher.sender and ftw.publisher.receiver.

ftw.profilehook-1.2.1-1.lbn25.noarch: ftw.profilehook provides a hook for executing custom code after a generic setup profile is installed. Motivation We often use import steps for executing code after import a generic setup profile. Registering a lot of setup handlers is bad because it extends the import duration of every profile and the amount of import steps are limited in generic setup, causing bad effects when exceeded. Import steps are meant to import things from any profile, not for executing code after importing a specific profile. Because of these reasons ftw.profilehook exists and provides an easy method to solve this issue.

ftw.mobilenavigation-1.4.6-1.lbn25.noarch: This product helps to create a responsive design. There are following mobile_buttons in portal_actions defined: Toggle personaltools (default personaltools) Toggle searchbox (default searchbox) Toggle special navigation (special navigation, using AJAX to expand children) Navigation types You can choose between: Expandable navigation (install profile default) Sliding navigation (install profile slide navigation)

collective.zopeedit-1.0.0-2.lbn25.noarch: ZopeEdit : External Editor Client

collective.zamqp-0.14.3-1.lbn25.noarch: collective.zamqp acts as a Zope Server by co-opting Zope's asyncore mainloop (using asyncore-supporting AMQP-library pika), and injecting consumed messages as requests to be handled by ZPublisher (exactly like Zope ClockServer). Therefore AMQP-messages are handled (by default) in a similar environment to regular HTTP-requests: ZCA-hooks, events and everything else behaving normally. This package is an almost complete rewrite of affinitic.zamqp, but preserves its ideas on how to setup AMQP-messaging by configuring only producers and consumers.

collective.z3cform.mapwidget-2.1-1.lbn25.noarch: Map widget for z3c.form based on collective.geo.mapwidget. For more information about collective.geo, see the Coactivative home page.

collective.z3cform.datetimewidget-1.2.9-1.lbn25.noarch: The collective.z3cform.datetimewidget library provides a form framework and widgets. This document ensures that we implement a widget for Date and Datetime field defined in zope.schema. Take a look at the different widget doctest files for more information about the widgets.

collective.z3cform.datagridfield-demo-0.5-2.lbn25.noarch: This package provides the demo views for collective.z3cform.datagridfield. Examples of configurations are in the demo folder. Once you install this package, the demo views will be visible on your site. * http://localhost:8080/Plone/@@demo-collective.z3cform.datagrid

collective.z3cform.datagridfield-1.3.3-1.lbn25.noarch: This module provides a z3c.form version of the Products.DataGridField . This product was developed for use with Plone4/5 and Dexterity.

collective.z3cform.colorpicker-1.4-1.lbn25.noarch: collective.z3cform.colorpicker provides two different jQuery based widgets: Farbtastic, a simple color picker. jPicker, a jQuery Color Picker Plugin supporting transparency.

collective.xmpp.core-0.3-1.lbn25.noarch: Introduction collective.xmpp.core is a fork/merge of jarn.xmpp.twisted and jarn.xmpp.core both written by Yiorgis Gozadinos (@ggozad). It removes the PubSub and Messaging features from the jarn.xmpp.core and is intended to instead serve only as a base on which Plone add-ons with XMPP-enabled features can depend. Currently it provides the following features: Extensions to the wokkel package by implementing parts of the following XMPP extensions: XEP-0071 XHTML-IM. XEP-0144 Roster Item Exchange. XEP-0060 Publish-Subscribe. XEP-0248 PubSub Collection Nodes. XEP-0133 Service Administration. A Twisted reactor that runs side-by-side with the Zope instance. Utilities that provide XMPP clients of two sorts, a deferred client that initially connects, executes a task and disconnects as soon as it is done, as well as a normal client that remains connected and can respond to XMPP events. An XMPP component base class for writing custom components. Integration of plone user accounts with XMPP accounts and authentication. Installation Before setting up the package you need to have a working XMPP server and access to the administration account on the server. The package has only been tested with ejabberd version 2.1.5 and above which is recommended. In any case the following XMPP extensions need to be supported by the server you are going to use: XEP-0144 Roster Item Exchange. XEP-0133 Service Administration. XEP-0124 Bidirectional-streams Over Synchronous HTTP (BOSH) XEP-0206 XMPP over BOSH Buildout A sample buildout you can use as a starting point can be found at collective.xmpp.buildout. Setting up ejabberd (>=2.1.5) Automatic configuration Use the recipe provided in collective.xmpp.buildout (in which case you will need to have erlang installed, erlang-nox on Debian) or download the ejabberd installer. A minimal configuration for ejabberd can be generated for convenience by the ejabberd.cfg part of collective.xmpp.buildout. You will need to copy the templates directory and modify the recipe configuration accordingly: [ejabberd.cfg] recipe = collective.recipe.template input = templates/ejabberd.cfg.in output = ${buildout:directory}/etc/ejabberd.cfg xmppdomain = localhost admin_userid = admin collaboration_allowed_subnet = 0,0,0,0 collaboration_port = 5347 component_password = secret where xmppdomain is the domain (or virtual host) running on your XMPP server and admin_userid is the id the the administrator account that Plone is going to use to interact with the server. The rest of the options are used by collective.xmpp.collaboration for the collaborative editing component connecting to the XMPP server. Here, collaboration_allowed_subnet specifies from which IPs the XMPP server is going to accept connections and should match the IPs your Plone instances are going to be using. Leaving it to 0,0,0,0 will allow all IPs, 127,0,0,1 will allow only localhost. Finally collaboration_port is the port to which the collaboration component is going to connect to and component_password is the shared password between the component and the XMPP server. Manual configuration If you already run an XMPP server here are some hints on how to set it up: We assume that your xmpp domain is localhost. There should exist an administrator account admin@localhost. In addition if you intend to run some of the tests in any of the collective.xmpp.* packages you will need to be running an additional XMPP node on localhost if you use some other domain for production. You can safely remove any references to localhost if you are not interested in doing that. Make sure you have enabled the http_bind module, as this is what the javascript clients will use to connect. You should have something like this in your ejabberd.cfg: {5280, ejabberd_http, [ http_bind, web_admin ]} In order to test and run custom XMPP components (for instance the collaborative editing component provided by collective.xmpp.collaboration) you will need to allow them to connect. This means you should have something similar to this configuration: {5347, ejabberd_service, [ {access, all}, {shaper_rule, fast}, {ip, {127, 0, 0, 1}}, {hosts, ["collaboration.localhost"], [{password, "secret"}] } ]}, The rest of the standard options should be fine. Administrator account If you have not done so during installation you might need to create manually the administrator account. In the ejabberd folder execute: ./bin/ejabberdctl register admin localhost your_password Test that you can access your ejabberd by logging to the admin interface (typically http://localhost:5280/admin). You should also be able to access the http-bind interface at http://localhost:5280/http-bind. Setting up your front-end proxy On the client-side every authenticated user will be connected to your jabber server through an emulated bidirectional stream through HTTP. To allow for this you need a proxy in front of Plone that will be redirecting the XMPP stream to your XMPP server. It is possible to do without one using the inferior solution of Flash plugins but this is not going to be supported. Assuming you run your webserver as a proxy at port 8080 for the domain localhost, Zope listens on 8081, there exists a Plone site with id Plone and your ejabberd has the http_bind configured for port 5280, your nginx or apache configuration will look as follows: Nginx http { server { listen 8080; server_name localhost; location ~ ^/http-bind/ { proxy_pass http://localhost:5280; } location / { proxy_pass http://localhost:8081/VirtualHostBase/http/localhost:8080/Plone/VirtualHostRoot/; } } } Apache <VirtualHost *:8080> ServerName localhost RewriteEngine On RewriteRule ^/http-bind(.*) http://localhost:5280/http-bind$1 [P,L] RewriteRule ^/(.*) http://localhost:8081/VirtualHostBase/http/%{HTTP_HOST}:8080/Plone/VirtualHostRoot/$1 [P,L] </VirtualHost> Setting up your Plone instances Your instances will need to maintain a connection to the administrator account of your XMPP server. This is accomplished through Twisted and you will need to run a Twisted reactor on each of them. To do so include this in your instance section of your buildout: zcml-additional = <configure xmlns="http://namespaces.zope.org/zope"> <include package="collective.xmpp.core" file="reactor.zcml" /> </configure> Moreover, if your Plone buildout is not using plone.dexterity and you want to avoid this dependency being brought just add the bellow line to your CFG file: [versions] Products.UserAndGroupSelectionWidget = 2.0.4 Again, it will help you to have a look at the sample buildout provided in collective.xmpp.buildout. Setting up a new Plone site Start ejabberd (if you used the recipe to build ejabberd, bin/ejabberd will do the job). Start the Nginx frontend. bin/frontend start Start your zope instance. Access Zope directly at http://localhost:8081/manage and create a new Plone site with collective.xmpp.core. Go to the Plone control panel and click on the XMPP Integration link under Plone Configuration. Make sure the XMPP settings reflect your installation. Restart your Plone instance. Upon the first request the administrator will log to his account. You should see things happening in the logs and if there are any errors something might be wrong with your installation. When you create a new Plone user, they will automatically be registered on the XMPP server. Your existing users can also be registered by going back to the XMPP Integration configlet in the control panel, and then clicking on the User Registration tab. Keep an eye on your instance.log traceback in the console to make sure there aren't any errors. You can see the registered users by going to the XMPP admin interface at localhost:5280/admin. Making sure things work ;) This is a complex infrastructure so it can be hard to know what goes wrong sometimes. Do not despair, here are a few things to try: Make sure your ejabberd is running. Connect to it normal client as the admin user. Verify that http-binding is setup properly on ejabberd. Visiting http://localhost:5280/http-bind should tell you it's working. Verify that XMPP requests will get properly through your proxy. Visiting http://localhost:8080/http-bind/ should give you the same result as above. When you start your Zope instance in foreground you can verify the Twisted reactor is running fine: 2011-09-01 14:37:38 INFO collective.xmpp.core Starting Twisted reactor... 2011-09-01 14:37:38 INFO collective.xmpp.core Twisted reactor started 2011-09-01 14:37:38 INFO Zope Ready to handle requests After the first request to the site, you should also see in the logs: 2011-09-01 14:45:48 INFO collective.xmpp.core XMPP admin client has authenticated succesfully. If your Plone user was succesfully registered on the XMPP server, logging-in to the Plone site with a user should also authenticate him with the XMPP server. This is indicated in the logs by: 2011-09-01 14:45:50 INFO collective.xmpp.core Pre-binded ggozad@localhost/auto-QravOoyEeE Experimenting Usage Add a few users. Login as one of them, and in a different browser as some other. Use the frontend to access the site, if you used the settings above this should be http://localhost:8080. All actions are performed through the viewlet on the top right: Online users will display the users currently logged in. Clicking it will give you the list of users. You can message them directly or look at their personal feed. Try posting an entry to your feed. Links will be transformed automatically. As soon as you submit other logged-in users will receive a notification in real-time. Using a recent browser that supports geolocation will allow you also share your location at the time of the post. Try commenting on a feed post. By clicking on the "Following" user action you can select which users you want to follow, or follow them all. You can see all posts by clicking on Site feed on the viewlet. Security Included is an implementation of an authenticating client over BOSH according to XEP-0206. This practically means that the javascript client never needs to know the password of the XMPP user. Instead, the user is authenticated directly between the XMPP server and the Plone instance. A pair of secret tokens are exchanged, valid for a short time (~2 minutes). It is this pair that is given to the javascript client and not the password. When a Plone user is registered on the XMPP server, a random password is generated and stored in the ZODB in a persistent utility. If you do not need to access the XMPP accounts outside of the Plone instance you can additionally hide the entire XMPP service behind a firewall and only allow connections to it from the Plone instances. This in combination with HTTPS should be enough for the paranoid among us.

collective.xmltestreport-1.3.4-1.lbn25.noarch: This package provides an extension to the test runner to the one that ships with zope.testrunner, as well as a buildout recipe based on zc.recipe.testrunner to install a test script for this test runner. The test runner is identical to the one in zope.testrunner, but it is capable of writing test reports in the XML format output by JUnit/Ant. This allows the test results to be analysed by tools such as the Jenkins continuous integration server. The recipe accepts the same options as zc.recipe.testrunner, so look at its documentation for details. When buildout is run, you should have a script in bin/test and a directory parts/test. To run the tests, use the bin/test script. If you pass the --xml option, test reports will be written to parts/test/testreports directory: $ bin/test --xml -s my.package Use bin/test --help for a full list of options. If you are using Jenkins, you can now configure the build to publish JUnit test reports for <buildoutdir>/parts/test/testreports/*.xml.

collective.workspace-1.1-1.lbn25.noarch: collective.workspace package for providing 'membership' in specific areas of a Plone Site. It allows you to grant people access to areas of content using a membership group rather than local roles for each user, and to delegate control over that group to people who don't have access to the site-wide user/group control panel. collective.workspace provides a behavior that can be enabled for any Dexterity content type. When enabled, it adds a "Roster" tab which is where you can manage the team. All the functionality takes place via an IWorkspace adapter, which can be overridden to specify: A list of groups, and the roles that each group should receive. These groups are created automatically via a PAS plugin, and automatically granted local roles using a borg.localrole adapter. The schema for which fields should be stored for each member in the roster. This includes checkboxes for the groups, to determine which groups the member is in. Action links for each row in the roster. The default is an "Edit" link which brings up a popup to edit the fields for that person's roster membership. Action buttons at the bottom of the roster which apply to the rows the user selects. An example of this could be a 'Send email' action, so a roster admin can easily email users in the roster. Unlike similar previous packages (see slc.teamfolder and collective.local.*), collective.workspace supplies its own PAS groups plugin, instead of using standard Plone groups. This means that Workspace-specific groups do not appear in the sitewide group control panel. Some other features are: Membership in a roster is indexed, so you can search the catalog for items of portal_type X that have a particular user in their roster. Events are fired when roster memberships are added/modified/removed.

collective.whoiswho-1.0-1.lbn25.noarch: Plone addon that provides read-only views which display all groups, the members per group and the member's details. The views are made available to the user through a link in the user's menu (iow, a user action).

collective.vdexvocabulary-0.1.2-1.lbn25.noarch: What this package do? IMS VDEX is a standard for exchanging vocabularies. collective.vdexvocabulary create bridge between vdex vocabularies and zope vocabularies, so you can easily use it in systems like Plone / Zope. Contents What this package do? Whats so special about it? How do I use it? Example VDEX file How to access relations (from code) Where can I complain / help / send rum? Credit TODO History 0.1.2 (2014-01-07) 0.1.1 (2010-10-11) 0.1 (2010-06-23) 0.1a1 (2010-04-29) Whats so special about it? Imagine you have big vocabularies with a lot of relations. I'm talking +10.000 terms with +30.000 relations. So this would be perfect use case to use collective.vdexvocabulary. Also there are other stuff which I didn't found in other vocabulary packages for Plone/Zope: i18n support (as it is defined in IMS VDEX) proper order also with unicode charecters (if zope.ucol is installed) easy registration using zcml relations as it specified in IMS VDEX standard How do I use it? In your configure.zcml add: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <include package="collective.vdexvocabulary" file="meta.zcml" /> <include package="collective.vdexvocabulary" /> And to register a vdex vocabulary simply add line bellow pointing to file containing vdex vocabulary: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <vdex:vocabulary file="path-to/very-interesting.xml" /> To make registration of vocabularies even easier you can also register several vocabularies and just point to directory: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <vdex:vocabulary directory="path-to/my-vdex-vocabularies" /> vdex files in path-to/my-vdex-vocabularies directory should have ending .vdex to be recognized by vdex:vocabulary ZCML directive. Example VDEX file Example of car manufacturers list (car_manufacturers.vdex).: <?xml version="1.0" encoding="utf-8"?> <vdex xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" orderSignificant="false" language="en"> <vocabIdentifier>your.package.car_manufacturers</vocabIdentifier> <term> <termIdentifier>ford</termIdentifier> <caption> <langstring language="en">Ford</langstring> <langstring language="es">Una miedra de coche</langstring> </caption> </term> <term> <termIdentifier>bmw</termIdentifier> <caption> <langstring language="en">BMW</langstring> <langstring language="es">Be-eMe-uWe, mierda</langstring> </caption> </term> <relationship> <sourceTerm>bmw</sourceTerm> <targetTerm vocabIdentifier="your.package.car_models">very-special-bmw-model</targetTerm> <relationshipType source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml">NT</relationshipType> </relationship> ... </vdex> List of car models (car_models.vdex).: <?xml version="1.0" encoding="utf-8"?> <vdex xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" orderSignificant="false" language="en"> <vocabIdentifier>your.package.car_models</vocabIdentifier> <term> <termIdentifier>very-special-bmw-model</termIdentifier> <caption> <langstring language="en">Very special BMW model</langstring> <langstring language="es">Un modelo de Be-eMe-uWe</langstring> </caption> </term> <relationship> <sourceTerm>very-special-bmw-model</sourceTerm> <targetTerm vocabIdentifier="your.package.car_manufacturers">bmw</targetTerm> <relationshipType source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml">BT</relationshipType> </relationship> ... </vdex> How to access relations (from code) Relations are defined by ISO2788. To get listing of BMW car models from above VDEX example you have to: from zope.schema.vocabulary import getVocabularyRegistry vr = getVocabularyRegistry() car_manufacturers = vr.get(self.context, 'your.package.car_manufacturers') car_models = vr.get(self.context, 'your.package.car_models') bmw = car_manufacturers.getTerm('bmw') bmw_car_models = bmw.related.get('NT', [])

collective.usernamelogger-1.2-2.lbn25.noarch: Log user names when using cookie authentication in Zope/Plone.

collective.uploadify-1.2-1.lbn25.noarch: Multifileupload for Plone using uploadify Usage After install, go to http://your-plone-site/@@upload

collective.upload-9.18.0rc2-1.lbn25.noarch: Support for Archetypes and Dexterity-based content types No browser plugins required: The implementation is based on open standards like HTML5 and JavaScript and requires no additional browser plugins Multiple file upload: Allows to select multiple files at once and upload them simultaneously Drag & Drop support: Allows to upload files by dragging them from your desktop or filemanager and dropping them on your browser window Support for Exif metadata: Uploading images with Exif metadata will pre-populate description and rights Preview for images, audios and videos: A preview of image, video and audio files is displayed before uploading with browsers supporting the required JS APIs Client-side image resizing: Images can be automatically resized on client-side with browsers supporting the required JS APIs Upload progress bar: Shows a progress bar indicating the upload progress for individual files and for all uploads combined Cancelable uploads: Individual file uploads can be canceled to stop the upload progress Graceful fallback for legacy browsers: Uploads files via XMLHttpRequests if supported and uses iframes as fallback for legacy browsers Drag and drop uploads from another web page: Supports uploading files dragged from one page into another (tested with Firefox and Chrome

« Previous 20 items Next 20 items » 1 ... 667 668 669 670 671 672 673 ... 2449


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

Sections

Modified items