General Upgrading Issues Whenever updating PSE to a higher version, you should always delete any and all parsed/compiled servlets. This includes all .p[ty][co] files. The format of these files can change from version to version, and while old versions may seem to run OK, it's probably just a fluke. For example, you may use something like the following command to delete all these files from a directory tree: *** WARNING!!! THIS WILL DELETE FILES. USE AT YOUR OWN RISK!!! *** $ rm -i `find . -name '*.p[ty][co]'` Pay special attention to changes in the format and options of the pse.conf file. Keep a backup of your original pse.conf file, install the new default version that comes with PSE, and merge changes from your old pse.conf into the new one. Upgrading from PSE 2.x to 3.0 PSE 3.0 now requires Python 2.3.1 and higher. Versions older than Python 2.3.0 are not supported. The main change you will see when upgrading from 2.x to 3.0 is the package name change from pse to pse_handler. This was done mainly to avoid import confusion between the pse handler and the internal pse package used in servlets. In your apache configuration, change references from "pse.handler" to "pse_handler" for each mod_python directive that requires it. Also, PSE no longer uses the PythonAccessHandler directive in the apache configuration. All references must be removed. Additionally, you will have to change any custom tag modules you may have to import CustomTag from pse_handler.tags instead of pse.tags (which now exists solely in running servlets to access custom tags). Athentication hooks are no longer supported. They were just a thin wrapper around mod_python's PythonAuthenHandler mechanism, and as such were clunky and limited as a feature of PSE. Instead, consider using the new pse.plugins.reponse.authenticate function, or just write a simple mod_python handler from your existing authentication hook module. PSE output caching is now accomplished in a separate cache directory that can be configured in pse.conf rather than in the application directory. Additionally, output is cached according to the unparsed URI rather than simply the servlet file name. These changes were done to improve security and performance. Compiling servlets with the psecompile utility now compile to a .pto file. This is not to be confused with the old .pto files, which contained cached output, which has been replaced by the mechanism explained above. As such, PSE will no longer attempt to execute a .pt/.ptc and .py combination if the .pto file exists. This should lead to faster startup and execution times for compiled servlets. The plugin architecture has changed significantly. User plugins built to work with PSE 2.x will continue to work, though you will receive deprecation warnings in the apache error log. User plugins now can (and should) be placed in a directory outside the PSE package directory, configurable in pse.conf. Please see the manual for plugin API changes and other details to bring your plugins up to date, as deprecated features will be discontinued in a subsequent version of PSE. The choice of which session module to use is no longer controlled by manipulating the modules in the PSE plugins directory; it is now controlled in the pse.conf file using the Type parameter. The default value is dbm, which is consistent with the 2.x default. Please see the manual for details. The use of tag_hooks in custom tag modules to identify custom tag classes was deprecated in 2.x and is no longer supported in 3.0. There are no major changes in the PSE 3.0 programming interface. Modules and templates written for PSE 2.x should work without any changes in PSE 3.0. However, see Changelog.txt for information on new functions and functionality available in PSE 3.0. NOTE: PSE is now thread safe and can work with threaded MPM modules in apache 2.0. If you want to use mpm_worker or mpm_winnt, you need to make sure your custom tags and plugins are thread safe, as well as any third party library modules you want to use with PSE. Upgrading from PSE 1.2 to 2.0 1. If you use the ? in attribute values in your templates to execute arbitrary Python statements, such as: this is no longer supported in versions 2.0 and above. The ? instead has the meaning of indicating that if the following condition is true, then use the attribute; if false, do not use the attribute. Example: