Deprecations and removals in 1.3
This document lists all settings, classes, methods, functions, and tasks that have been deprecated or removed in symfony 1.3.
The following core plugins have been deprecated in symfony 1.3 and will be removed in symfony 1.4:
sfCompat10Plugin: By deprecating this plugin, we also deprecate all other elements in the framework that rely on this plugin to work (1.0 admin generator, and 1.0 form system). It also includes the default admin generator theme for 1.0 located in
sfProtoculousPlugin: The helpers provided by this plugin do not support unobstrusiveness, and as such should not be used anymore.
The following methods and functions have been deprecated in symfony 1.3 or before, and will be removed in symfony 1.4:
sfToolkit::getTmpDir(): You can replace all occurrences of this method by
sfValidatorBase::setInvalidMessage(): You can replace it by a call to the new
sfValidatorBase::setRequiredMessage(): You can replace it by a call to the new
sfTesterResponse::contains(): You can use the more powerful
checkResponseElement(): These methods have been deprecated since 1.2, and replaced with the tester classes.
isUriCached(): These methods have been deprecated since 1.2, and replaced with the tester classes.
sfFilesystem::sh(): You can replace all occurrences of this method by calls to the new
sfFilesystem::execute()method. Be warned that the returned value of this method is an array composed of the
stdoutoutput and the
sfAction::validate(): These methods have been deprecated in symfony 1.1, and they was not really useful. As of symfony 1.1, they need the
compat_10setting set to
sfComponent::debugMessage(): Use the
sfLoader::loadHelpers(): Use the same methods from the
sfApplicationConfigurationobject. As all methods of the class
sfLoaderare deprecated, the
sfLoaderclass will be removed in symfony 1.4.
sfController::sendEmail(): Use the new mailer feature of Symfony 1.3 instead.
sfGeneratorManager::initialize(): It does nothing.
debug_message(): Use the
sfVarLogger: The logged
debug_stackvalue is deprecated in favor of the
sfContext::retrieveObjects(): The method is only used by ObjectHelper, which is deprecated
The following methods and functions have been removed in symfony 1.3:
sfApplicationConfiguration::checkSymfonyVersion(): see below for the explanation (
The following classes have been deprecated in symfony 1.3 and will be removed in symfony 1.4:
sfRichTextEditorTinyMCE: They have been replaced by the widget system (see the "Helpers" section below)
sfPropelAdminGenerator: These classes were used by the 1.0 admin generator
sfDoctrineUniqueValidator: These classes were used by the 1.0 form system
sfLoader: see the "Methods and Functions" section
sfPropelDataRetriever: These classes are only used by ObjectHelper, which is deprecated
sfWidgetFormI18nSelectCountry: Use the corresponding
sfWidgetFormI18nChoiceCountryrespectively) as they act exactly in the same way, except they have more customization possibilities
sfValidatorPropelDoctrineMany: Use the same classes but without
Manyat the end, and set the
SfPeerBuilder: The custom Propel builder classes have been ported to Propel 1.4's new behaviors system
The following classes have been removed in symfony 1.3:
sfCommonFilter: see the "Removal of the common filter" section of the UPGRADE_TO_1_3 file for more information about the consequences and how to migrate your code.
The following helper groups have been deprecated in symfony 1.3 and will be removed in symfony 1.4:
- All helpers related to the 1.0 form system as provided by the
The following settings (managed in the
settings.yml configuration file) have
been removed from symfony 1.3:
check_symfony_version: This setting was introduced years ago to allow automatic cache cleaning in case of a change of the symfony version. It was mainly useful for shared hosting configuration where the symfony version is shared amongst all customers. As this is bad practice since symfony 1.1 (you need to embed the symfony version in each of your project), the settings does not make sense anymore. Moreover, when the setting is set to
on, the check adds a small overhead to each request, as we need to get the content of a file.
max_forwards: This settings controls the number of forwards allowed before symfony throws an exception. Making it configurable has no value. If you need more than 5 forwards, you have both a conception problem and a performance one.
sf_lazy_cache_key: Introduced as a big performance improvement in symfony 1.2.6, this setting allowed you to turn on a lazy cache key generation for the view cache. While we think doing it lazy was the best idea, some people might have relied on
sfViewCacheManager::isCacheable()being called even when the action itself wasn't cacheable. As of symfony 1.3, the behavior is the same as if
sf_lazy_cache_keywas set to
strip_commentswas introduced to be able to disable the comment stripping because of some bugs in the tokenizer of some PHP 5.0.X versions. It was also used later on to avoid large memory consumption when the Tokenizer extension was not compiled with PHP. The first problem is not relevant anymore as the minimum version of PHP needed is 5.2 and the second one has already been fixed by removing the regular expression that simulated the comment stripping.
lazy_routes_deserialize: This option is not needed anymore.
The following settings have been deprecated in symfony 1.3 and will be removed in symfony 1.4:
rich_text_js_dir: These settings are used by the Form helper group, which is deprecated in symfony 1.3.
validation_error_id_prefix: These settings are used by the Validation helper group, which is deprecated in symfony 1.3.
is_internalflag was used to prevent actions from being called from a browser. This was added to protect email sending in symfony 1.0. As email support does not require this trick anymore, this flag will be removed and not checked anymore in the symfony core code.
The following tasks have been removed in symfony 1.3:
project:unfreeze: These tasks used to embed the symfony version used by a project inside the project itself. They are not needed anymore as the best practice has been to embed symfony in the project for a very long time now. Moreover, switching from one version of symfony to another is really simple now as you only need to change the path in the
ProjectConfigurationclass. Embedding by hand symfony is also very simple as you just need to copy the whole symfony directory somewhere in your project (
lib/vendor/symfony/is the recommended one).
The following tasks are deprecated in symfony 1.3, and will be removed in symfony 1.4:
All symfony 1.0 task aliases.
propel:init-admin: This task generated admin generator modules for symfony 1.0.
The following Doctrine tasks have been merged into
doctrine:build and will
be removed in symfony 1.4:
The following behaviors are deprecated in symfony 1.3, and will be removed in symfony 1.4:
sfNamespacedParameterHolder::remove()methods support for the array notation (
) is deprecated and won't be available in symfony 1.4 (better for performance).
The symfony CLI does not accept anymore the global
--dry-run option as it
was not used by any symfony built-in task. If one of your task relies on this
option, you can just add it as a local option of your task class.
The Propel templates for the 1.0 admin generator and the 1.0 CRUD will be
removed in symfony 1.4
The "Dynarch calendar" (found in data/web/calendar/) will be removed in symfony 1.4 as it is only used by the Form helper group, which will be also removed in symfony 1.4.
As of symfony 1.3, the unavailable page will only be looked for in the
%SF_CONFIG_DIR%/ directories. If you still have
it stored in
%SF_WEB_DIR%/errors/, you must move it before migrating to
doc/ directory at the root of a project is not generated anymore, as it
was not used by symfony itself. And so the related
sf_doc_dir has also been