If you go out to the ZMI, to the portal_javacripts tool, you see the resources ++resource++kukit.js and ++resource++kukit-devel.js. If you disable both of them, kss javascript is not loaded and kss is inactive.

To disable these resources, uncheck the checkbox left to these two resources, scroll down, and press Save. Then go back to the resources to see that they are in the desired state.

By default kss is default loaded for authenticated users only. The conditions of the resources mentioned in 1.1 are:

Condition for ++resource++kukit.js:

python: not here.restrictedTraverse('@@plone_portal_state').anonymous() and here.restrictedTraverse('@@kss_devel_mode').isoff()

Condition for ++resource++kukit-devel.js:

python: not here.restrictedTraverse('@@plone_portal_state').anonymous() and here.restrictedTraverse('@@kss_devel_mode').ison()

If the first part of the expressions. nothere.restrictedTraverse('@@plone_portal_state').anonymous() is deleted from both conditions, kss will be active in all pages. Similarly, you can combine them with any other condition.

The second parts of the expressions need to stay on the condition always, they control the switching between the development and production modes of kss.

Do not change other parameters of these resources.

base2 is a javascript library that we start to use instead of cssQuery in the development version, and it is doing selections much faster. Consequently, kss will be faster too. To enable this speedup, follow the next steps:

• Update kss.core to current svn trunk, http://codespeak.net/svn/kukit/kss.core/trunk. Currently, the 3.0 release contains a bug that disables the use of base2. The bugfix is not ported back to the 3.0 release branch, because of assumed risks involved.

  • Hint: you can also install the development trunk of kss.core as an egg, from the location https://codespeak.net/svn/kukit/kss.core/trunk#egg=kss.core-dev.

• Enter the base2 resource into portal_javascripts, since the Plone setup does not contain it.

  • Add a new resource ++resource++base2-dom-fp.js, with Compression type "none". Press Add. Scroll down to the bottom to see your newly created resource is not orange. (If it is orange, check for typos.)
  • Walk up the resurce with the up arrow, so that it is located above ++resource++kukit.js and ++resource++kukit-devel.js. Press Save at the bottom of the page.
  • Reload your page, and check that "Using cssQuery from base2." appears in the log. This means base2 is active.

• Optionally, you can install a lightweight compatibility wrapper replacing the original cssQuery.js. This does not affect kss, but all the other Plone javascript that calls the old cssQuery. To activate this, first

  • check that base2 is active, as described previously
  • disable cssQuery.js, by unchecking the checkbox next to it and pressing Save at the bottom of the page
  • add a new resource ++resource++cssQuery-compat.js. Walk it up next to the original cssQuery.js. Press Save.

  With this optional step your page javascript will be 20K smaller.

In case you experience problems with this setup, and you issue a bug report, let us know in particular that you used base2 instead of cssQuery.

Kss features can be disabled one by one, by manually commenting out their rules from kss files.

The list of kss files can be viewed in the portal_kss tool. You can see there are inactive files that contain features not supported by default, but that can be used for testing them.

The two active resources are located at:

Products/CMFPlone/skins/plone_kss/plone.kss
Products/Archetypes/skins/archetypes_kss/at.kss

If you edit these files, you will notice kss rules dedicated to the activation of a given feature, grouped with an initial comment. You can simply use commenting to deactivate the group you do not want in the following way:

/* Functionality that I don't want */

/*
    #id-element:click {
        ...
    }
*/

After this you need to reload your browser page and make sure caching is switched off. You also need to restart Zope, unless the Debug mode of portal_kss tool is switched on.

Plone >=3.1.5.1

You can enable/disable inline editing globally in the Control Panel: Site Setup → Site Settings. To configure it using GenericSetup, use the enable_inline_editing property of propertiestool.xml. See Plone Properties Reference - Site-wide properties for more info about that.

Plone <3.1.5.1

Although it is possible to do this in the way described in the question 1.4, there is a global variable you can define in your template:

tal:define="kss_inline_editable python:False;"

This should be put to the template generating the outer level of the page, for example, around the top of main_template.pt.

This will deactivate all inline editing, and also prevent the visual cueing that shows that the feature is available.

For developing or debugging kss in Plone, we use the FireFox browser In addition we use the following extensions:

• FireBug, this is inevitable for introspecting nodes and viewing the kss log
• Web Developer, contains a useful menu bar to complement FireBug

On Safari, the kss log is placed into the console. On IE, the Firebug Lite can be used.

• Reload your page in IE. Pressing F12 toggles the tool in the bottom of the page area. The functionality is very simple: it comes with a console and an area to show kss logs.

It also works in Safari.

It is harmless to enable this file for all the time during development.

To do development, it is a good idea to avoid caching, otherwise you change some file, but the result will not be shown.

To achieve this, first you must disable caching from your browser. The Firefox Developer Extension gives a convenient switch for this. You can also force the browser to reload the page each time manually.

Second, if you change kss files you need to switch portal_kss tool to Debug mode, similarly if you change javascript you need to do similarly with portal_javascripts, to have your changes in effect without restarting Zope. Restarting after each change is another option.

kss.core in lib/python of your instance contains the server side python, and the javascript of kss, including the core kss plugins.

The component plone.app.kss contains the kss application part of Plone. It contains the "zope" and "plone" kss plugins. It is at the moment scattered between different packages:

• plone.app.kss and archetypes.kss contain the kss application part of Plone.
• Products.CMFPlone contains the GS profile needed to load kss, as well as skins/plone_kss/plone.kss. that contains the kss rules. Similarly Products.Archetypes contains skins/archatypes_kss/at.kss.
• Products.CMFPlone and Products.Archetypes contain several other templates that contain kss markup.
• In addition to the core, other components can also define their kss application, inside their own package space. This means that if you install that component, its kss plugin becomes available globally.

plone.app.kss is released with version number 1.2 in Plone 3. The current development version of plone.app.kss is 1.4, and it will be usable with Plone 3.5.

kss.core also followed the same versioning scheme, so 1.2 version is for the 3.0 release, 1.4 will be usable with 3.5.

kss.demo contains zope-only demonstration pages. We also use these for testing kss.core. It is not by default contained by Plone, so it needs to be installed separately, from svn using the 1.2  branch, or as an egg: https://codespeak.net/svn/kukit/kss.demo/branch/1.2#egg=kss.demo-dev

For the newest Plone versions, you can also use the egg downloaded from the Cheeseshop, ie. for Plone 3.0.6 you would need to use kss.demo 1.2.6,  that is, the corresponding  minor version from the 1.2 development line.

After installing kss.demo into products, you need to copy the "slugs" kss.demo-configure.zcml and kss.demo-meta.zcml into etc/package-includes in your instance.

After restarting zope, you need to create a "KssDemo SimpleContent" object. It will provide an index for all the demos.

Due to a CMF issue, you cannot create this object in the Zope root. You need to create it inside a portal, and then cut-and-paste it to the Zope root. It should be called "demo".

Look at kss.demo, there is an example case.

However instead of currentFormVar and formVar please consider using the following to send up an entire form:

action-server:                     myServerAction;
myServerAction-kssSubmitForm:      currentForm();

This has the disadvantage that it sends up all form fields, but it works naturally with all the :list, etc. variables.

In the future we plan to implement a way to filter fields in this construct.

Kss runs in Production mode as default. This means that although you will get a visible javascript error, the error message will be meaningless. In return the javascript code is slightly faster and more compact.

You can switch at any time to Development mode, to see the error. Visit the url anywhere in your portal: @@kss_devel_mode/ui. You can switch between the two modes and currently active mode is displayed. After that, you need to reload your page to operate it in the selected mode.

This setting works with browser cookies. So you can use this method to debug a production server. However if Debug mode is switched on in the portal_javascripts tool, kss will always operate in Development mode, regardless of the cookie setting. If yyou have one instance that you use for development continously, this may also be a comfortable way of switching.

Kss bugs in Plone3 should go into Plone's bug tracker, by selecting "KSS (Ajax)" as component name. Besides a detailed description of your problem, you should give in particular

• your browser version where you discovered it,
  
• and the kss log transcript from the loading of the page until the error, including the full traceback, copypasted from Firebug. To do this you must run kss in Development mode, as described in 2.8.

If you report a bug on IE, you need to copy the kss log transcript from Firebug Lite, after enabling it as described in point 2.2.

Switch on KSS Development Mode as described in 2.8.

Visit your error_log object from the ZMI, and remove Unauthorized and NotFound from the filter. Save.

Restart Zope, and reload your page in the client. You are supposed to see any log now, both on the client side (kss log console) and the server side (event.log).

If you have an Unauthorized bug, please enable VerboseSecurity as described here, and attach the information to the report.