Modified items

All recently modified items, latest first.

plone.app.theming-1.3.6-1.lbn25.noarch: Introduction In Plone versions 4.3 and higher you can edit your website theme through web browser in Plone's site setup control panel. Only HTML, CSS and little XML knowledge needed as the prerequisitements. This guide explains how to use this feature of Plone. See introduction video to plone.app.theming. What is a Diazo theme? A "theme" makes a website (in this case, one powered by Plone) take on a particular look and feel. Diazo (formerly known as XDV) is a technology that can be used to theme websites. It is not specific to Plone per se, but has been created by the Plone community and, as of Plone 4.3, provides the default way to apply a theme to a Plone site. You can learn more about Diazo at http://diazo.org. Diazo themes may be a little different to themes you have created in other systems, and indeed to themes you may have created for earlier versions of Plone. A Diazo theme is really about transforming some content - in this case the output from "vanilla" Plone - into a different set of HTML markup by applying a set of rules to combine a static HTML mock-up of the end result you want with the dynamic content coming from Plone. In comparison, the previous way to theme a Plone site (like the way many other content management systems are themed) relies on selectively overriding the templates and scripts that Plone uses to build a page with custom versions that produce different HTML markup. The latter approach can be more powerful, certainly, but also requires much deeper knowledge of Plone's internals and command of server-side technologies such as Zope Page Templates and even Python. Diazo themes, by contrast, are easy to understand for web designers and non- developers alike. A Diazo theme consists of three elements: One or more HTML mockups, also referred to as theme files, that represent the desired look and feel. These will contain placeholders for content that is to be provided by the Plone content management system. Mockups usually reference CSS, JavaScript and image files by relative path. The most common way to create a theme is to use desktop software like Dreamweaver or a text editor to create the relevant markup, styles and scripts, and test the theme locally in a web browser. The content that is being themed. In this case, that is the output from Plone. A rules file, which defines how the placeholders in the theme (i.e. the HTML mockup) should be replaced by relevant markup in the content. The rules file uses XML syntax (similar to HTML). Here is a very simple example: <?xml version="1.0" encoding="UTF-8"?> <rules xmlns="http://namespaces.plone.org/diazo" xmlns:css="http://namespaces.plone.org/diazo/css" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">` <theme href="theme.html" /> <replace css:content-children="#content" css:theme-children="#main" /> </rules> Here, we are replacing the contents (child nodes) of a placeholder element with HTML id main in the theme file (theme.html, found in the same directory as the rules.xml file, as referenced by the <theme /> rule) with the contents (children) of the element with the HTML id content in the markup generated by Plone. When this theme is applied, the result will look very much like the static HTML file theme.html (and its referenced CSS, JavaScript and image files), except the placeholder that is identified by the node in the theme with id main will be filled by Plone's main content area. Plone ships with an example theme called, appropriately, Example theme, which uses the venerable Twitter Bootstrap to build a simple yet functional theme exposing most of Plone's core functionality. You are advised to study it - in particular the rules.xml file - to learn more about how Diazo themes work. Using the control panel After installation of the Diazo theme support package in a Plone site, the Theming control panel will appear in Plone's Site setup. The main tab of this control panel, Themes, will show all available themes, with buttons to activate/deactivate, modify, copy or delete each, as well as buttons to create new themes or bring up this help text. Click on a theme preview image to open a preview of that theme in a new tab or window. The preview is navigable, but form submissions and some advanced features will not work. Selecting a theme To apply an existing theme, simply click the Activate button underneath the theme preview. The currently active theme will be highlighted in yellow. If you deactivate the currently active theme, no Diazo theme will be applied, i.e. "vanilla" Plone theming will apply. Note: The Theming control panel is never theemd, ensuring that you can always deactivate an errant theme that could render the control panel unusable. Thus, you may not see any difference immediately after enabling a theme. Simply navigate to another page in the Plone site, though, and you should see the theme applied. Creating a new theme New themes can be created in one of two ways: Click the New theme button at the top of the Themes tab in the Theming control panel and enter a title and description in the form that appears. A bare-bones theme will be created, and you will be taken to the Modify theme screen (see below), where you can edit or create theme and rules files. Click the Copy button underneath any existing theme and enter a title and description in the form that appears. A new theme will be created as a copy of the existing theme, and you will be taken to the Modify theme (see below), where you can edit or create theme and rules files. Uploading an existing theme Themes can be distributed as Zip files, containing the HTML mockup and rules file. To download an existing theme, click the Download button underneath the theme on the Themes tab of the Theming control panel. To upload such a Zip file into another site, use the Upload Zip file button on the Themes tab of the Theming control panel. You can choose whether or not to replace any existing theme with the same name (based on the name of the top-level directory contained within the Zip file). You can also upload a Zip file of a static HTML mockup that does not contain a rules file, such as a design provided by a Plone-agnostic web designer. In this case, a basic rules.xml file will be added for you to start building up a theme from using the Modify theme screen (see below). The generated rules file will assume the main HTML mockup file is called index.html, but you can change this in rules.xml. Once you have successfully uploaded a theme Zip file, you will be taken to the Modify theme screen (see below), where you can edit or create theme files. Hint: If you get an error message like "The uploaded file does not contain a valid theme archive", this usually means that you have uploaded a Zip file that contains multiple files and folders, rather than a single top level folder with all the theme resources in it. This could happen if you compressed a theme or HTML mockup by adding its files and folders directly a Zip archive, rather than compressing the directory in which they were found. To fix this, simply unzip the archive on your computer into a new directory, move up a level, and compress this directory on its own into a new Zip file, which you can then upload. Modifying the theme You can modify a theme by clicking Modify theme underneath a theme in the Themes tab of the Theming control panel. This screen is also launched automatically when you create or upload a new theme. Note: Only themes created or uploaded through the Theming control panel can be modified through Plone. Themes installed by third-party add-ons or distributed on the filesystem cannot, although changes made on the filesystem will be reflected immediately if Zope is running in debug mode. To modify a filesystem theme, you can copy it to a new in-Plone theme by clicking the Copy button underneath the theme in the Theming control panel. The Modify theme screen initially shows a file manager, with a file tree on the left and an editor on the right. Click on a file in the file tree to open an editor or preview: HTML, CSS, JavaScript and other text files can be edited directly through the editor. Other files (e.g. images) will be rendered as a preview. Note: The advanced editor with syntax highlighting is not available in Microsoft Internet Explorer. Click New folder to create a new folder. You can also right-click on a folder in the file tree to bring up this action. Click New file to create a new text file. You can also right-click on a folder in the file tree to bring up this action. Click Upload file to upload a file from your computer. You can also right- click on a folder in the file tree to bring up this action. Click Preview theme to preview the theme as it will be applied with the mockup and rules as currently saved. The preview is navigable, but forms and certain advanced features will not work. To save the file currently being edited, click the Save file button, or use the keyboard shortcut Ctrl+S (Windows/Linux) or Cmd+S (Mac). To rename or delete a file or folder, right-click on it in the file tree and select the appropriate action. The theme inspector The theme inspector provides an advanced interface for discovering and building up the rules of a Diazo theme. It can be launched by clicking the Show inspectors button on the Modify theme screen for in-Plone themes, or by clicking the Inspect theme button underneath a filesystem theme on the Themes tab of the Theming control panel. The theme inspector consists of two panels: The HTML mockup. If there are several HTML files in the theme, you can switch between them using the drop-down list underneath the HTML mockup panel. The Unthemed content. This shows Plone without any theme applied. Either panel can be maximised by clicking the arrows icon at the top right of either. The HTML mockups and Unthemed content panels can be switch to source view, showing their underlying HTML markup, by clicking the tags icon at the top right of either. As you hover over elements in the HTML mockup or Unthemed content panels, you will see: An outline showing the element under the cursor. A CSS or XPath selector in the status bar at the bottom if the panel which would uniquely identify this element in a Diazo rule. Click on an element or press Enter whilst hovering oveer an element to select it. The most recently selected element in each panel is shown in the bottom right of the relevant status bar. Press Esc whilst hovering over an element to select its parent. This is useful when trying to select "invisible" container elements. Press Enter to save this selection. The contents of the HTML mockup or (more commonly) Unthemed content panels can be navigated, for example to get to a content page that requires specific theme rules, by disabling the inspector. Use the toggle switches at the bottom right of the relevant panel to enable or disable the selector. The rule builder Click the Build rule button near the top of the Modify theme or Inspect theme screen to launch an interactive rule building wizard. You will be asked which type of rule to build, and then prompted to select the relevant elements in the HTML mockup and/or Unthemed content panels as required. By default, this will use any saved selections, unless you untick the Use selected elements box on the first page if the wizard. Once the wizard completes, you will be shown the generated rule. You can edit this if you wish. If you click Insert, the newly generated rule will be inserted into the rules.xml editor at or near your current cursor position. You can move it around or edit it further as you wish. Click Preview theme to preview the theme in a new tab or window. Don't forget to save the rules.xml file if you have made changes. Note: In readonly mode, you can build rules and inspect the HTML mockup and theme, but not change the rules.xml file. In this case, the Insert button of the rule builder (see below) will not be available either. Note: The ability to insert rules from the Build rule wizard are not available in Microsoft Internet Explorer, although you will be given the option to copy the rule to the clipboard when using this browser. Advanced settings The Theming control panel also contains a tab named Advanced settings. Here be dragons. The Advanced setings tab is divided into two areas. The first, Theme details, contains the underlying settings that are modified when a theme is applied from the Themes control panel. These are: Whether or not Diazo themes are enabled at all. The path to the rules file, conventionally called rules.xml, either relative to the Plone site root or as an absolute path to an external server. The prefix to apply when turning relative paths in themes (e.g. references to images in an <img /> tag's src attribute) into absolute ones at rendering time. The HTML DOCTYPE to apply to the rendered output, if different to the default XHTML 1.0 Transitional. Whether or not to allow theme resources (likes rules.xml) to be read from the network. Disabling this gives a modest performance boost. A list of host names for which a theme is never applied. Most commonly, this contains 127.0.0.1, allowing you to view an unthemed site through http://127.0.0.1:8080 and a themed one at http://localhost:8080 during development, say. A list of theme parameters and the TALES expressions to generate them (see below). The second, Theme base, controls the presentation of the unthemed content, and apply even if no Diazo theme is being applied. These are the settings that used to be found in the Themes control panel in previous versions of Plone.

plone.app.themeeditor-1.0a8-1.lbn25.noarch: The theme editor makes it possible to customize most aspects of a plone theme from a single location. After installation a new entry is added to the Plone "site setup" control panel called "Theme Editor." Using the themeeditor Log into your Plone site as a Manager Navigate to Site Setup Select Theme Editor

plone.app.textfield-1.2.11-1.lbn25.noarch: This package provides a zope.schema style field type called RichText which can be used to store a value with a related MIME type. The value can be transformed to an output MIME type, for example to transform from structured text to HTML.

plone.app.testing-4.2.7-1.lbn25.noarch: plone.app.testing provides tools for writing integration and functional tests for code that runs on top of Plone. It is based on plone.testing. If you are unfamiliar with plone.testing, the concept of layers, or the zope.testing testrunner, please take a look at the the plone.testing documentation. In fact, even if you are working exclusively with Plone, you are likely to want to use some of its features for unit testing. In short, plone.app.testing includes: A set of layers that set up fixtures containing a Plone site, intended for writing integration and functional tests. A collection of helper functions, some useful for writing your own layers and some applicable to tests themselves. A convenient layer base class, extending plone.testing.Layer, which makes it easier to write custom layers extending the Plone site fixture, with proper isolation and tear-down. Cleanup hooks for zope.testing.cleanup to clean up global state found in a Plone installation. This is useful for unit testing.

plone.app.stagingbehavior-0.1-4.lbn25.noarch: The IStagingSupport behavior is used for enabling the plone.app.iterate functionality for Dexterity content. It allows you to perform the checkout and checkin operations to work on a copy of your original content.

plone.app.search-1.2.2-1.lbn25.noarch: plone.app.search combines search results listing with Advanced Search form. This provides search results view for Plone CMS with possibilities to filter, sort and apply advanced filters to the search results without. When changing a search criteria on the search view, AJAX call is delivering you the updated results instead of reloaded page that lets you get to what you're searching for faster without much distraction caused by page reloading. The package is part of Plone 4.1. plone.app.search also updates main search field (usually located at the top right of your Plone site by default) and search portlet to return results in the updated listing view. plone.app.search has the aim to give intuitively clear and understandable interface for searching in Plone. But there might be some new things that are not so obvious. Let's see how the search results works now.

plone.app.robotframework-1.2.4-1.lbn25.noarch: plone.app.robotframework provides Robot Framework compatible resources and tools for writing functional Selenium tests (including acceptance tests) for Plone CMS and its add-ons. Plone/Robot Framework requires robot-server and an appropriate test layer: $ robot-server my.product.testing.MY_PRODUCT_ROBOT_TESTING To test plone.app.robotframework, this command would be something like: $ robot-server --no-reload plone.app.robotframework.testing.PLONE_ROBOT_TESTING Then we suggest something like the python-robotframework-ride graphical editor to open, run, and report Robotframework tests.

plone.app.relations-2.0-1.lbn25.noarch: A set of components to provide a content centric API for the engine from plone.relations, as well as a few different core relationship types and policies. See the package README.txt for details on usage.

plone.app.relationfield-1.2.3-1.lbn25.noarch: Plone support for z3c.relationfield

plone.app.linkintegrity-1.5.10-1.lbn25.noarch: This package tries to integrate PLIP 125, link integrity checking, into Plone. It is making use of the zope3 event system in order to modify Plone itself as little as possible.

plone.app.contentlisting-1.2-1.lbn25.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.collection-1.1.4-1.lbn25.noarch: Collections in Plone are the most powerful tool content editors and site managers have to construct navigation and site sections. This is a brand new implementation of collections for Plone, using ajax/javascript to make a simpler, easier and streamlined user experience for using collections. Having a more lightweight backend that does not depend on many nested criteria types. It's designed with simplicity and usability as a main focus, so content editors and site managers can create complex search queries with ease.

plone.app.changeownership-0.3-3.lbn25.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.lbn25.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.12-1.lbn25.noarch: Plone UI and default rules for plone.caching/z3c.caching

plone.app.blocks-4.3.2-1.lbn25.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.19-1.lbn25.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.7.0-1.lbn25.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.lbn25.noarch: plone.app module

plone.api-1.10.2-1.lbn25.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.

« Previous 20 items Next 20 items » 1 ... 648 649 650 651 652 653 654 ... 2449


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

Sections

Modified items