Commits
-------
38cbbe7 Moved JSON encoding and decoding to separate classes which expose all their available parameters
Discussion
----------
[Serializer][JsonEncoder] Exposed json_encode and json_decode params
In `JsonEncoder::decode()` you are unable to change the `$assoc` parameter from `json_decode`. I created two sub-classes that handle JSON encoding and decoding while exposing all the available parameters from `json_encode` and `json_decode`. You can now do this:
```php
$jsonEncoder = new JsonEncoder(new JsonEncode(JSON_HEX_TAG), new JsonDecode(true, 1024));
$serializer = new Serializer(array(), array($jsonEncoder));
```
Additionally I made `json_last_error()` available from `JsonEncoder`:
```php
$jsonEncoder->getLastEncodingError();
$jsonEncoder->getLastDecodingError();
```
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: N/A
Todo: -
License of the code: MIT
Documentation PR: -
---------------------------------------------------------------------------
by travisbot at 2012-05-14T18:46:16Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1329496) (merged 38cbbe71 into 46ffbd52).
---------------------------------------------------------------------------
by fabpot at 2012-05-15T05:07:04Z
ping @Seldaek / @lsmith77
---------------------------------------------------------------------------
by Seldaek at 2012-05-15T09:47:48Z
This looks fine to me, I asked him to submit the PR, but I wanted to get feedback from others.
Commits
-------
b2afd9f use require instead of include
1ed8b72 Autoloader should not throw exception because PHP will continue to call other registered autoloaders.
Discussion
----------
[DoctrineBundle] Proxy autoloader should not throw exception
Also change 'require' to non-fatal '@include' in the event no file is generated.
---------------------------------------------------------------------------
by stof at 2012-05-01T06:13:34Z
The goal of the exception was to make debugging easier. And all Symfony2 autoloaders are using ``require``
---------------------------------------------------------------------------
by robocoder at 2012-05-01T16:09:04Z
I changed the include back to a require.
Whether or not the exception makes debugging easier is debatable. But throwing an exception from an autoloader is both unconventional and unexpected given that (1) exceptions are propagated while php calls other registered autoloaders, and (2) php will throw a fatal error where the usage actually occurs if the class doesn't exist.
---------------------------------------------------------------------------
by fabpot at 2012-05-15T06:01:11Z
ping @beberlei
---------------------------------------------------------------------------
by beberlei at 2012-05-15T10:20:06Z
Its tricky, the message does try to give some additional information - but later autoloaders could handle this issue anyways. I guess the PR makes sense as users have absolutely no control over this autoloader and it should therefore behave less strictly.
Commits
-------
47605f6 [Form][DataMapper] Do not update form to data when form is read only
Discussion
----------
[Form] [DataMapper] Read only form datamapper fix
The current 2.0.13 ``Symfony\Component\Form\Extension\Core\DataMapper\PropertyPathMapper`` enables to overwrite data from form values, no matter the form fields are read only or not.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
---------------------------------------------------------------------------
by travisbot at 2012-05-14T15:50:02Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1328279) (merged 47605f63 into 72b2f698).
---------------------------------------------------------------------------
by bschussek at 2012-05-14T18:06:41Z
Forms don't bind when they are read only, so why is this change necessary?
---------------------------------------------------------------------------
by stof at 2012-05-14T19:29:45Z
@bschussek A read-only child will not be bound but the setter will still be called on the parent object for this field (with the old value), making it mandatory to define setters for read-only fields.
---------------------------------------------------------------------------
by Romain-Geissler at 2012-05-14T19:43:11Z
In my case, the property is still set through a setter even if the field for this property is read only. The problem is the setter is not called with the legacy value it held, but with the value given by the form. In my case the value is transformed from a string to an object by a ``DataMapper``, which returns ``null`` for an empty string/value. Thus, the setter is called with ``null`` instead of the previous non ``null`` value (and not always the same) it held.
This PR just prevent the setter for an object property marked as read only in the form definition from being called.
---------------------------------------------------------------------------
by bschussek at 2012-05-15T08:20:28Z
Ok, 👍 then
Commits
-------
95727ff [OptionsResolver] Updated PHP requirements to 5.3.3
1c5f6c7 [OptionsResolver] Fixed issues mentioned in the PR comments
d60626e [OptionsResolver] Fixed clear() and remove() method in Options class
2b46975 [OptionsResolver] Fixed Options::replace() method
16f7d20 [OptionsResolver] Improved implementation and clarity of the Options class
6ce68b1 [OptionsResolver] Removed reference to non-existing property
9c76750 [OptionsResolver] Fixed doc and block nesting
876fd9b [OptionsResolver] Implemented fluid interface
95454f5 [OptionsResolver] Fixed typos
256b708 [OptionsParser] Renamed OptionsParser to OptionsResolver
04522ca [OptionsParser] Added method replaceDefaults()
b9d053e [Form] Moved Options classes to new OptionsParser component
Discussion
----------
Extracted OptionsResolver component out of Form
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
This PR refactors the options-related code of the Form component into a separate component. See the README file for usage examples.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-17T18:11:03Z
To me it seems like we have some redundancy with the Config/Definition component. I'm wondering if these two can/should be merged somehow?
---------------------------------------------------------------------------
by kriswallsmith at 2012-04-17T18:14:44Z
I would also suggest merging this into the Config component. Its current name too closely resembles Python's optparser lib, which could create confusion.
---------------------------------------------------------------------------
by bschussek at 2012-04-17T18:18:49Z
Merge conflict artifacts are fixed now.
@schmittjoh Do we? Isn't the idea of the Config component to read complex configuration from different configuration providers? (YAML, XML, Annotations etc.)
The idea of this parser is to be highly performant and to be usable in simple classes. If this can be achieved with the Config component, I'm happy to learn more.
---------------------------------------------------------------------------
by schmittjoh at 2012-04-17T18:27:08Z
The config component is basically a super intelligent version of array_merge and the like.
About performance, I haven't really done any tests to say something about the impact. I think it's safe to say that it would be at least slower than your implementation in its current form due to the additional indirection. However, we could probably add a caching layer.
---------------------------------------------------------------------------
by bschussek at 2012-04-17T18:31:22Z
Have you checked the README I wrote? Are you sure the Config component is intended for the same purpose and not *way* too complex in this case?
---------------------------------------------------------------------------
by stof at 2012-04-17T18:51:14Z
You also forgot to update the ``replace`` section of the root composer.json file.
And regarding doing such thing with the Config Definition stuff, it would be more difficult: it builds the tree of values with their defaults, and then merges stuff coming from different sources. The form component however receives defaults from different places (which also define the allowed keys at the same time) and then receives user options only once. And it needs to handle easily default values which depend from other values. So I think both implementations are useful for different needs (however, we could argue about making it a subnamespace in the Config component, but this would add yet another different stuff in it)
---------------------------------------------------------------------------
by jalliot at 2012-04-17T18:58:03Z
@bschussek You need to add this component to the main composer.json too.
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T06:54:17Z
doesn't this overlap a bit with the ``TreeBuilder`` in the Config component?
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T06:59:12Z
ah just saw @stof's comment .. i think the biggest argument against TreeBuilder is that it was designed for a very specific purpose and performance wasn't one of them. where as Form needs something that performs fast. so yeah i do see different use cases, but i don't think this means we should have a new component.
furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T08:10:49Z
@stof, @jalliot: Fixed.
> furthermore while i haven't read the code in details i am surprised it doesn't make use of http://php.net/manual/en/function.array-replace-recursive.php to merge defaults into a user supplied options array.
@lsmith77: Because that's not what this component does. The key feature of this component is to resolve default values of options that depend on the *concrete* values of other options. I invite you to read the README.
Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configurations from storage providers, such as the filesystem.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T08:18:48Z
Note: Not all relevant code of this component is shown in the diff. The (crucial) Options and LazyOption classes have only been moved out of Form.
---------------------------------------------------------------------------
by lsmith77 at 2012-04-18T08:20:02Z
> Is it a good idea to merge this into Config? I think that both components address different audiences and different purposes. The idea of this one is to initialize classes with simple, run-time provided arrays. The idea of Config is to load and validate complex configuration values from the filesystem (typically).
decoupled is all fine, but to me this feels a bit too granular. but i am just expressing a gut feeling here
---------------------------------------------------------------------------
by jalliot at 2012-04-18T08:34:03Z
I think too it should be included in the config component (maybe in a subnamespace). Indeed the behaviour is too different to be merged into the current component but its purpose is similar and is all about *configuration* (hence the name of the component). Otherwise we could also split the current Config component into smaller components as it seems to me there are already parts of it that are totally unrelated to each other.
---------------------------------------------------------------------------
by bschussek at 2012-04-18T11:30:55Z
@jalliot Can you go into detail which parts that are and what changes you suggest?
@kriswallsmith Any other naming suggestion?
---------------------------------------------------------------------------
by jalliot at 2012-04-18T11:34:35Z
@bschussek I don't know the current component well enough but that's the impression I had last time I looked at its code but I may be wrong.
---------------------------------------------------------------------------
by stof at 2012-04-18T19:30:43Z
@bschussek the Definition subnamespace of the Config component is standalone. It is not directly related to the Loader part
---------------------------------------------------------------------------
by bschussek at 2012-04-19T09:32:48Z
@stof So what do you recommend?
I think this is also a question of marketing. Is the Definition subnamespace intended to be used totally separately of the loaders? What are the use cases? If there are good use cases, it makes sense to me to extract the Definition part into a separate component. Otherwise not.
It is also a question of marketing, because the purpose of a component should be communicable in simple words (quoting @fabpot). The purpose of Config is (copied from the README):
> Config provides the infrastructure for loading configurations from different data sources and optionally monitoring these data sources for changes. There are additional tools for validating, normalizing and handling of defaults that can optionally be used to convert from different formats to arrays.
I think this purpose is completely different than that of OptionsParser.
---------------------------------------------------------------------------
by stof at 2012-04-19T11:39:50Z
The current description itself shows the current state: what is advocated as the main goal of the component (and was the original part) is the loader stuff. But the Definition part (mentioned as "additional tools") is bigger in term of LOC
---------------------------------------------------------------------------
by bschussek at 2012-04-19T11:55:17Z
@stof: Yes, this is a fact, but what's your opinion? How do we proceed with this PR?
---------------------------------------------------------------------------
by stof at 2012-04-19T12:21:44Z
Well, my opinion is that the current Config component may deserve to be split into 2 components (as someone may need only part of it). But this would be a huge BC break. @fabpot what do you think ?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T10:14:57Z
@fabpot Can we merge this?
---------------------------------------------------------------------------
by fabpot at 2012-05-10T06:45:20Z
@bschussek I'm +1 for this PR but as mentioned by @kriswallsmith, we must find another name as `OptionsParser` immediately make me think of something related to the CLI.
---------------------------------------------------------------------------
by stof at 2012-05-10T06:47:45Z
However, after thinking about it again, I would vote for keeping it in its own component instead of adding yet another independant part in Config, to avoid forcing Form users to get the whole Config component
---------------------------------------------------------------------------
by bschussek at 2012-05-10T09:09:36Z
I'm having difficulties finding a better name. The main difference to CLI option parsers is that these actualy *parse* a string, while this class only receives an array of options (does not do any parsing). Otherwise both have the same purpose.
A couple of other suggestions:
* OptionsLoader (likely confused with our filesystem loaders)
* OptionsResolver
* OptionsMerger
* OptionsMatcher (not accurate)
* OptionsBuilder (likely confused with the builder pattern)
* OptionsJoiner
* OptionsBag (likely confused with the session bags)
* OptionsConfig (likely confused with Config)
* OptionsDefinition (likely confused with Config\Definition)
* OptionsSpec
* OptionsCombiner
* OptionsInitializer
* OptionsComposer
The difficulty is to find a name that best reflects its purpose:
```
$parser->setDefaults(...);
$parser->setRequired(...);
$parser->setOptional(...);
$parser->setAllowedValues(...)
$parser->parse($userOptions);
```
The only of the above examples that makes sense to me here is OptionsResolver -> resolve($userOptions).
Ideas?
---------------------------------------------------------------------------
by stof at 2012-05-10T09:56:54Z
OptionsResolver seems a better name than OptionsParser
---------------------------------------------------------------------------
by luxifer at 2012-05-10T09:59:45Z
Agree with @stof
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T10:03:53Z
I don't really like the plural in the name, but OptionsResolver seems better than OptionsParser. OptionResolver maybe?
---------------------------------------------------------------------------
by sstok at 2012-05-10T10:10:14Z
@r1pp3rj4ck Options makes more sense as they can be nested/deeper, and thus are multiple.
Agree with @stof also.
---------------------------------------------------------------------------
by r1pp3rj4ck at 2012-05-10T10:13:01Z
@sstok well, we have multiple events too and the name is EventDispatcher, not EventsDispatcher. Actually none of the component names are plural.
---------------------------------------------------------------------------
by newicz at 2012-05-10T10:33:50Z
OptionsResolver - I find it suggesting that there is some kind of problem to be resolved and there's not,
maybe OptionsDefiner but it isn't good aswell this is a tough one
Commits
-------
ceb5ce6 [Form] fixed tests
a1e3a59 [TwigBridge] Switched to composer
df36afb [Form] Added tests
6d5ad3b [Form] Added right HTML types to Datetime/Date/Time types if single_text is true
Discussion
----------
[Form] Added right HTML types to Datetime/Date/Time types if single_text is true
When you set the `widget` option to `single_text`, you get a HTML input tag which is fine, but you the type is `text`, and it's wrong. You don't have any other way to get the right `type` as this attribute is defined to the FormView instance itself (see FileType for instance).
This PR adds right HTML types like the FileType does.
Cheers,
William
---------------------------------------------------------------------------
by willdurand at 2012-05-09T16:04:16Z
@fabpot anything else to do there?
---------------------------------------------------------------------------
by fabpot at 2012-05-11T16:28:43Z
adding some unit tests?
---------------------------------------------------------------------------
by willdurand at 2012-05-11T16:35:40Z
fair point :)
---------------------------------------------------------------------------
by travisbot at 2012-05-12T16:34:43Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1314731) (merged 2631c8b7 into cb905c5f).
---------------------------------------------------------------------------
by travisbot at 2012-05-12T17:14:12Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1314902) (merged ceb5ce6e into e1934527).
---------------------------------------------------------------------------
by willdurand at 2012-05-12T17:16:17Z
@fabpot ok, so I had to fix some other tests but there is a weird dependency between the tests in TwigBridge, and the Form component. I fixed the test suite's setup in the TwigBridge, and fixed some failing tests.
Commits
-------
6438c80 [Locale] Updated exception messages
Discussion
----------
[Locale] Updated exception messages
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:12:46Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296098) (merged 60eabc7c into fae4523f).
---------------------------------------------------------------------------
by travisbot at 2012-05-11T21:27:29Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1309320) (merged 6438c808 into dd0da03c).
---------------------------------------------------------------------------
by hason at 2012-05-14T09:23:26Z
@fabpot corrected
Commits
-------
498b814 [FrameworkBundle] minor fix in TranslationUpdateCommand <info> was not properly closed.
Discussion
----------
[FrameworkBundle] TranslationUpdateCommand <info> was not properly closed.
---------------------------------------------------------------------------
by travisbot at 2012-05-13T13:43:06Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1319869) (merged 498b8140 into e1934527).
---------------------------------------------------------------------------
by fabpot at 2012-05-13T17:06:25Z
Can you reopen a PR on the 2.0 branch as this is a bug fix? Thanks.
---------------------------------------------------------------------------
by stof at 2012-05-13T18:09:39Z
@fabpot this command is a 2.1 feature (even if it was added 6 month ago and so seems already old). There is nothing to fix in 2.0
Since the redesign of the Web-Debug-Toolbar, a new PHP icon has been
set, but its color was a bit darker (#000000) than the other icons in
the toolbar (#302e32 for the Symfony2 logo). This commit aims to ajust
the background color of the PHP logo to keep a certain homogeneity.
Commits
-------
f2fea97 [Component][Finder] tests and condition: contains() used on dir
Discussion
----------
[Component][Finder] tests and condition: contains() used on dir
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
`Finder::contains()` and `Finder::notContains()` can't be used on directories.
---------------------------------------------------------------------------
by travisbot at 2012-05-08T06:33:11Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1273818) (merged f2fea974 into 919604ab).
Commits
-------
709be4b [WDT] added documentation link
Discussion
----------
[WDT] added documentation link
This adds a documentation link in the WDT for the appropriate branch according to the current symfony version.
@weaverryan there is no documentation branch yet for the currently created 2.1 branch.
Also it might be a nice feature to redirect the dev branch to master automatically on the website. I.e. `http://symfony.com/doc/2.1/index.html` -> `http://symfony.com/doc/master/index.html`
@fabpot It might be a good idea to introduce a `Kernel::BRANCH` constant. So there would be no need to extract the branch from the symfony version in `ConfigDataCollector`. And bumping new versions/branches would be in one place.
---------------------------------------------------------------------------
by vicb at 2012-04-27T14:17:07Z
Maybe the documentation server should redirect to the right version according to `Kernel::VERSION` (i.e. using rewritting) ?
---------------------------------------------------------------------------
by Tobion at 2012-04-27T14:31:49Z
That would be best yes.
---------------------------------------------------------------------------
by fabpot at 2012-05-10T06:03:45Z
FYI, I've added some more constants about the Symfony version: 48099a852c (modeled after PHP constants)
---------------------------------------------------------------------------
by fabpot at 2012-05-10T07:08:57Z
I've just updated the website to accept any `HttpKernel::VERSION` string. Some redirection examples:
* 2.0.12 -> current
* 2.0 -> current
* 2.0.12-DEV -> current
* 2.1 -> master
* 2.1.0-DEV -> master
---------------------------------------------------------------------------
by Tobion at 2012-05-10T12:49:16Z
👍 for updating the website. But I think you missed to return 404 for a non-existent main doc page.
http://symfony.com/doc/2.4/book/controller.html -> 404 as expected
http://symfony.com/doc/2.4/index.html -> does not return 404 (and all links there are dead)
---------------------------------------------------------------------------
by travisbot at 2012-05-10T15:12:07Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1296057) (merged 04adf361 into a01dec00).
---------------------------------------------------------------------------
by fabpot at 2012-05-10T17:21:06Z
I've fixed the doc index for non-existing versions. Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by Tobion at 2012-05-10T22:49:18Z
done
---------------------------------------------------------------------------
by travisbot at 2012-05-10T22:52:13Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1300414) (merged 709be4b7 into fae4523f).
Commits
-------
b865b09 [Session] Fix the PDO handler for mysql concurrent write
Discussion
----------
[RFC][Session] Make the PDO handler looks less hacky
Related discussion: ebc2f01e5b (commitcomment-1304221)
The current code works but looks hacky (`$dbTimeCol = CASE WHEN $dbTimeCol = :time THEN (VALUES($dbTimeCol) + 1) ELSE VALUES($dbTimeCol) END`).
Todo: wrap the mysql specific code in a `try...catch` if we choose this PR way (to be consistent with all other PDO invocations).
---------------------------------------------------------------------------
by travisbot at 2012-05-10T07:50:39Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1293131) (merged b865b096 into 48099a85).
Commits
-------
12e22c0 [Session] Memcache/d cleanup, test improvements
788adfb [Session] Pdo Handler cleanup
0216e05 [HttpFoundation][Session] Assume that memcache(d) instances are already configured
72d21c6 [HttpFoundation][Session] change possible replace() & set() for set only()
Discussion
----------
[Session] Non-native Session handlers
A few item to discuss. Needs @drak inputs.
* 72d21c66 is trivial,
* 0216e056 is about memcache(d) handlers
* I don't think the handlers should configure the memcache(d) instances. Those instances are injected into the storage so they should already be confidured (this will be done in the CacheBundle when available)
* A SW prefix has been added to the memcached handlers so that the same instance of memcached can be shared - you can still set the `Memcached::OPT_PREFIX_KEY` before injecting the memcached instance.
* It was not possible to use an expiration > 30days before, see [php.net](http://www.php.net/manual/en/memcached.expiration.php)
* 788adfb6 is trivial (cleanup in the PDO handler)
---------------------------------------------------------------------------
by travisbot at 2012-05-08T09:49:03Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1274808) (merged 788adfb6 into e54f4e46).
---------------------------------------------------------------------------
by drak at 2012-05-09T15:20:38Z
Overall this PR looks good to me. Since Memcache/d objects are passed by DI anyway, there is no need to provide a way to configure the objects here.
However, I am not sure it's consistent to provide internal handling of the prefix/expire if we are saying the objects should be configured and injected - if we hand over all configuration to the injected objects, that's exactly what we should do. In the case of the `Memcache` handler there is no handling for prefix by the Memcache object that is why it's handled internally.
Unless there are some other technical consideration I've missed, I would also not expect the same Memcache/d object to be used in all use cases (e.g. session storage and database caching layer). I realise we are trying to unify things in one cache component, but I am not entirely convinced session storage would necessarily have to be part of that nor that "one object fits all" is practical or wise.
As far as I am aware, apart from default settings, memcache/memcached instances retain their own settings once configured so it's quite feasible to expect there might be a couple of differently configured instances in a complex system.
In summary, I would remove the `$memcachedOptions` config entirely from the `MemcachedHander` along with the associated prefix and time and let it all be configured by the injected `Memcached` instance.
---------------------------------------------------------------------------
by travisbot at 2012-05-10T07:32:53Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1293064) (merged 12e22c0d into e54f4e46).
---------------------------------------------------------------------------
by vicb at 2012-05-10T07:34:31Z
@drak thanks for your feeback.
About the prefix: it might be necessary to avoid collisions when you re-use the same instance of `memcache/d`. This is why the prefix is handled internally and not by `memcached` (it would be global and not serve the purpose then).
About the ttl:
* `memcache/d` can not handle ttl > 30 days (they would consider the time as an absolute timestamp then) and this is why the PR always convert the ttl to an absolute ts (`time() + $ttl`)
* Moreover I think that the ttl should be initialized by the `Session`: there is no reason why the ttl should be different from the `gc_maxlifetime`. I think this is out of the scope of this PR.
About sharing `memcache/d ` instances: it will be possible but it does not mean that you have to, you still can use different instances if this suit your needs.
The tests have been improved.
If you are ok with the latest changes, this PR should be ready to be merged
---------------------------------------------------------------------------
by drak at 2012-05-10T09:29:18Z
@vicb - I think it's ok to merge now. You are right about the TTL since PHP will pass a maxlifetime not a timestamp, and since memcached varies how it treats $expire, it does need to be normalised in the handler. I'm not necessarily 100% convinced about the prefix, but I don't object. Nice work.
/cc @fabpot
Commits
-------
a2b3d3c added cache service definition
Discussion
----------
[Doctrine Bridge] Added a method to load a cache definition
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Following this discussion (https://github.com/doctrine/DoctrineBundle/pull/62), this will let DoctrineBundle, MongodbBundle and CouchdbBundle share the same code for cache definitions.
---------------------------------------------------------------------------
by dlsniper at 2012-04-30T06:56:49Z
+1 for this PR.
---------------------------------------------------------------------------
by stof at 2012-04-30T06:57:58Z
👍
---------------------------------------------------------------------------
by fabpot at 2012-04-30T15:41:05Z
Can you add a note abou this change in the CHANGELOG?
---------------------------------------------------------------------------
by stof at 2012-04-30T15:46:48Z
does it really need to be in the changelog ? End-users don't know about this at all. The only guys affected by this change are the maintainers of the different Doctrine bundles as they can remove some code now.
---------------------------------------------------------------------------
by fabpot at 2012-04-30T16:41:21Z
@stof: right
@bamarni: Can you squash your commits?
---------------------------------------------------------------------------
by bamarni at 2012-04-30T17:03:38Z
@fabpot : done
---------------------------------------------------------------------------
by dlsniper at 2012-04-30T17:22:07Z
@bamarni can you also do a patch for the docs after this gets merged so that people know about this change and know how to use it?
Thank you!
---------------------------------------------------------------------------
by bamarni at 2012-04-30T17:29:05Z
@dlsniper : no problem ;)
---------------------------------------------------------------------------
by fabpot at 2012-04-30T18:29:03Z
ping @beberlei
Commits
-------
be35099 Replaced » and for XHTML compatibility
0a0e74b Replaced » by » (for XHTML compatibility)
Discussion
----------
Changes for XHTML compatibility
When using Symfony in XHTML mode, some entities cause YSODs. These changes should prevent that.
---------------------------------------------------------------------------
by travisbot at 2012-05-09T00:24:35Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1281344) (merged be350994 into e54f4e46).
---------------------------------------------------------------------------
by Tobion at 2012-05-09T00:46:19Z
+1
Commits
-------
8009675 [Validator] corrected small docblock typo
Discussion
----------
[Validator] corrected small docblock typo
---------------------------------------------------------------------------
by travisbot at 2012-05-09T10:30:15Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1284151) (merged 8009675d into e54f4e46).
Commits
-------
80a2a92 [2.1][Component][Yaml] fix 4022
Discussion
----------
[2.1][Component][Yaml] fix 4022
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: [](http://travis-ci.org/gajdaw/symfony)
Fixes the following tickets: #4121, #4022, #4135
Todo:
---------------------------------------------------------------------------
by stof at 2012-04-27T13:03:15Z
Why is it marked as ``[2.2]`` if it is a bugfix ?
@fabpot ping
---------------------------------------------------------------------------
by gajdaw at 2012-04-27T14:42:21Z
The title should be [2.1] - now it is correct.
I marked it 2.0 and PR was for 2.0 originally.
Fabien suggested that it should go to master branch: https://github.com/symfony/symfony/pull/4121#issuecomment-5362990
---------------------------------------------------------------------------
by fabpot at 2012-05-07T09:17:31Z
That does not work when you have something after the unindented collection:
collection:
key:
- a
- b
- c
foo: bar
---------------------------------------------------------------------------
by gajdaw at 2012-05-07T11:11:30Z
@fabpot Last commit contains test with your yaml:
collection:
key:
- a
- b
- c
foo: bar
Everything seems fine. Can you give me a hint: what do you mean, when you say "That does not work"?
---------------------------------------------------------------------------
by fabpot at 2012-05-07T12:36:19Z
Sorry, the failing test is the following:
test: Key/value after unindented collection
brief: >
Key/value after unindented collection
yaml: |
collection:
key:
- a
- b
- c
foo: bar
php: |
array('collection' => array('key' => array('a', 'b', 'c'), 'foo' => 'bar'))
---------------------------------------------------------------------------
by gajdaw at 2012-05-07T15:48:26Z
@fabpot Last commit passed your test.
---------------------------------------------------------------------------
by fabpot at 2012-05-07T17:28:21Z
Can you squash your commits? Thanks.
---------------------------------------------------------------------------
by travisbot at 2012-05-08T05:32:58Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/1273487) (merged 20891c58 into 919604ab).
---------------------------------------------------------------------------
by gajdaw at 2012-05-08T05:36:51Z
Done.
---------------------------------------------------------------------------
by travisbot at 2012-05-08T07:23:47Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/1274162) (merged 80a2a92e into 898ff4e0).
Commits
-------
c9ebe67 [DomCrawler] fixed encoding when using addHtmlContent() (fixes#3881)
Discussion
----------
[DomCrawler] fixed encoding when using addHtmlContent() (fixes#3881)
After looking around, this is clear that loadHtml() resets the encoding set on the DomDocument instance. So, the only workaround that actually works (and which is not an ugly hack) is to use `mb_convert_encoding` when it exists.
---------------------------------------------------------------------------
by Seldaek at 2012-05-07T12:38:43Z
+1 (Side note: Using your fork of symfony for PRs would be good I think, otherwise it creates noisy versions on packagist.)
Commits
-------
8ff11c1 [HttpFoundation] fixed docblock typos in session class
Discussion
----------
[HttpFoundation] fixed docblock typos in session class
Commits
-------
1e84f1e [TwigBundle] implemented context auto-escaping in Twig templates based on the template extension
Discussion
----------
[2.2] Implements context escaping for Twig (fixes#839)
Commits
-------
bdc21b4 [Validator] Add a base AbstractLoader
ead4908 [Validator] Some cleanup of the GraphWalker
23e15bb [Validator] Fix a bug in the ExecutionContext
Discussion
----------
[Validator] Fix/cleanup
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: [](http://travis-ci.org/vicb/symfony)
* d2100a27 has some fixes for the EC,
* 51769e03 has some cleanup in the graph walker,
* f9b3591c add an AbstractLoader (namespace aliases does not belong to FileLoaders).
---------------------------------------------------------------------------
by vicb at 2012-05-07T08:32:40Z
@fabpot PR ready
Commits
-------
a196ca0 [Routing] Compiler: remove lazy quantifiers with no effect
8232aa1 [Routing] Compiler: fix in the computing of the segment separators
Discussion
----------
[Routing] Fix the matching process
This PR is based on the PR #3678, #4139.
[](http://travis-ci.org/vicb/symfony)
**The spec**
A pattern is composed of both text and variable segments: `/{variable}-test/{other_variable}`.
A variable segment will match anything until a separator is encountered. The separator is the character following the variable segment when available or preceding the variable otherwise (i.e. at the end of the pattern).
That is:
* the separator is `-` for the `variable`,
* the separator is `/` for the `other_variable`.
*Note: This default matching behavior can be overridden if a requirement is specified for a variable)*
**Fixes**
* The current behavior is to consider booth the preceding and following characters as separators (considering availability),
* The "preceding" separator of the first variable is always set to `/` whatever the preceding character is (due to `$pos = 0` for the first iteration).
**Todo**
Update the doc once this is merged
Commits
-------
bc63fb2 Fix some cs
Discussion
----------
Fix some cs
---------------------------------------------------------------------------
by fabpot at 2012-05-03T21:13:33Z
Can you squash your commits? Thanks.
---------------------------------------------------------------------------
by stephpy at 2012-05-03T22:18:07Z
It's ok
Commits
-------
95b8e29 [BrowserKit] Remove dependency of CookieJar to Response
Discussion
----------
[BrowserKit] Remove dependency of CookieJar to Response
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
The CookieJar has currently a hard dependency to `BrowserKit\Response`, but this dependency could be avoided.
---------------------------------------------------------------------------
by stof at 2012-05-01T21:52:34Z
Renaming a method *is* a BC break.
You should add a new method and keep the old one accepting the Response (and make it calling the new method internally). This way, it would add the new feature without breaking the BC.
---------------------------------------------------------------------------
by stof at 2012-05-01T21:53:31Z
And btw, I don't see the issue with BrowerKit depending on BrowserKit. If you have a class, you also have the other one.
---------------------------------------------------------------------------
by GromNaN at 2012-05-02T05:57:51Z
The issue is that I want to use the CookieJar without the Request/Response of BrowserKit.
---------------------------------------------------------------------------
by fabpot at 2012-05-03T06:37:02Z
You should also keep some unit tests for the old method.
---------------------------------------------------------------------------
by GromNaN at 2012-05-03T08:22:39Z
@fabpot I've made the changes.
---------------------------------------------------------------------------
by fabpot at 2012-05-03T10:53:47Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by GromNaN at 2012-05-03T10:57:30Z
@fabpot Squashed
Commits
-------
b1de2a2 [HttpKernel] fix typo, commit 9fed41 fixed only half of it
Discussion
----------
[HttpKernel] fix typo
commit 9fed41 fixed only half of it
Commits
-------
69e0451 [Security] fixed English grammar in exception message
Discussion
----------
[Security] fixed English grammar in exception message
Commits
-------
c195957 [Components] Tests/Autoloading fixes
Discussion
----------
Fix components
See #4141
----
This PR:
* configures each component to use composer to manage "dev" dependencies instead of env variables;
* adds phpunit configuration file on Filesystem component;
* fixes READMEs.
It's mergeable without any problems, but I would recommend to wait a fix in Composer in order to use `self.version` in `require`/`require-dev` sections.
Note: I kept `suggest` sections because it makes sense but this PR doesn't aim to provide useful explanations for each entry. It could be another PR, not that one.
---------------------------------------------------------------------------
by willdurand at 2012-04-30T20:43:13Z
@fabpot I reviewed each component, one by one. Now `phpunit` always works, even if tests are skipped. A simple `composer install --dev` allows to run the complete test suite. Each commit is well separated from the others. I guess, everything is ok now.
---------------------------------------------------------------------------
by Tobion at 2012-04-30T20:47:00Z
Please squash, as it makes no sense to have the same commit for each component.
---------------------------------------------------------------------------
by fabpot at 2012-05-01T14:26:11Z
Can you squash your commits before I merge? Thanks.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T14:29:38Z
done
---------------------------------------------------------------------------
by fabpot at 2012-05-01T15:48:25Z
It does not seem that the commits are squashed.
---------------------------------------------------------------------------
by willdurand at 2012-05-01T15:54:08Z
done
* Switched to Composer to manage "dev" dependencies
* Fixed READMEs
* Excluded vendor in phpunit.xml.dist files
* Fixed message in bootstrap.php files
* Added autoloader for the component itself
Commits
-------
1f6c8d5 [HttpKernel] Added mock objects for Memcache(d) and Redis
e17217b [HttpKernel] Remove destructive flush() from memcache(d) storage profilers
Discussion
----------
[HttpKernel] Memcache and Redis profiler storage update
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
Changes of this PR:
- change ```purge()``` method of memcache(d) profiler storage to delete only required items and be less destructive,
- mock objects for Redis and Memcache(d) storages were added to make unit tests independent from memcache(d)/redis extensions and memcache(d)/redis servers running on localhost.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Currently the ports in RetryAuthenticationEntryPoint are fixed in the constructor call, there is no way to set them when you run your application on different ports.
With this fix the ports are taken from the router configuration.
Addresses issues with writing console output for IBM i5 Series (OS400).
The normal QP2TERM shell outputs garbage text when attempting to write
directly to STDOUT, likely because of EBCDIC character-encoding used
on IBM platforms. Writing to the OUTPUT mimics using 'echo' or 'print'
and prints properly in the console.
Fixes#1434
Commits
-------
689a40d [MonologBridge] Fixed the WebProcessor
Discussion
----------
[MonologBridge] Fixed the WebProcessor
The WebProcessor can now be registered as a kernel.request listener to
get the request instead of passing it as a constructor argument, which
was broken as the request is not yet available when the logger is
instantiated.
I'm sending it to 2.0 even if the way to use the processor is not BC as this is really a bugfix. The processor was simply unusable with the previous way. Tell me if you think it should only be fixed for 2.1
Fixes#3311
Commits
-------
246c885 [Form] Fixed: Default value of 'error_bubbling' is now determined by the 'single_control' option
d3bb4d0 [Form] Renamed option 'primitive' to 'single_control'
167e64f [Form] Fixed: Field attributes are not rendered in the label anymore. Label attributes are now passed in "label_attr"
68018a1 [Form] Dropped useless test that is guaranteed by OptionsParser tests and that needs to be adapted very often
649752c [Form] Fixed: CSRF token was not displayed on empty complex forms
c623fcf [Form] Fixed: CSRF protection did not run if token was missing
eb75ab1 [Form] Fixed results of the FieldType+FormType merge.
Discussion
----------
[Form] Fixed errors introduced in the FieldType+FormType merge
Bug fix: yes
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #3994, #4000, #2294, #4118
Todo: -
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:39:20Z
`primitive` is a pretty abstract option name. It depends on the person what he considers primitive. Maybe more explicit naming or better documentation what it means.
---------------------------------------------------------------------------
by bschussek at 2012-04-22T15:47:29Z
Better suggestions?
The distinction here is between primitive and complex forms, where primitive forms are such forms that can be represented by a single HTML tag. This obviously needs to be documented.
---------------------------------------------------------------------------
by Tobion at 2012-04-22T15:49:45Z
Maybe `single_widget` or something like that.
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:09:43Z
@Tobion @bschussek would `elementary` be better than `primitive` ?
---------------------------------------------------------------------------
by vicb at 2012-04-23T13:17:04Z
and `compound \ composite` better than `complex` ?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:08:33Z
@vicb I fail to see how elementary/compound is easier to understand than primitive/complex. Maybe single_widget, but what's the opposite of this case? multi_widget?
---------------------------------------------------------------------------
by vicb at 2012-04-23T14:15:09Z
Actually I am fine with anything... as long as it is documented.
---------------------------------------------------------------------------
by bschussek at 2012-04-23T14:22:31Z
Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
Should we refer to them as
* forms and fields?
* complex and primitive forms?
* ...
We must first answer this question before we can find an intuitive option name. If the documentation always switches between different terminologies, neither will it be understandable nor will this option be easy to remember.
---------------------------------------------------------------------------
by vicb at 2012-04-23T15:10:32Z
> Still I think that this unveals a more profound naming problem. How do we (also in the documentation) name forms with children (formerly "forms") and forms without children (formerly "fields")?
To make it clear, I would rather say forms that **can have** children and forms that **can not have** children (i.e. Empty collections have no children but they can have and this is reason why you have to introduce those options, right ? - that could be a good example for the doc).
It will probably be better to refer to "complex" / "primitive" forms in the doc (and use the "form" / "field" terms to explain them).
Note: I think @Tobion concern is that "primitive" / "complex" could be pejorative terms (this is why I have proposed "elementary" / "compound").
---------------------------------------------------------------------------
by Tobion at 2012-04-23T16:00:54Z
1. primitive/complex is subjective (and could be pejorative too)
2. elementary/compound is more explicit so probably better than primitive/complex
3. I dislike this option in general. Does it make sense to change this option from a user perspective? I guess it's always the same as long as the widget structure stays the same. So it should be resolved at a higher level dynamically from the widget structure and not exposed to any configuration.
4. In documentation I would use the terms forms and fields. Because all people with HTML knowledge will understand that fields cannot have sub-fields whereas forms can. But since this distinction is not findable in code, it should be mentioned that all these are implemented as a form hierarchy.
---------------------------------------------------------------------------
by mvrhov at 2012-04-23T16:02:00Z
how about simple and complex?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T16:06:33Z
@Tobion It does not make sense to change this option from the user perspective, still the overloading type has to propagate to FormType whether it is a form or a field, so that the default behaviour is correct.
A second option how to implement this is to add a method `isField` to FormTypeInterface that can be overloaded and receives the options. I don't really like to introduce new methods here unless absolutely required.
What about renaming the option "primitive" to "is_field"? The blocks in the template would then be named "form_widget_field" and "form_widget_form".
---------------------------------------------------------------------------
by tristanbes at 2012-04-25T14:01:06Z
Oh, I should've seen this before, i thought I was doing something wrong. (empty collections gets an input field bug)
Please big :UP: on this. When will it be merged ? @bschussek
---------------------------------------------------------------------------
by Tobion at 2012-04-25T15:30:28Z
+1 for "is_field" and "form_widget_field" but I would rather use "form_widget_compound" instead of "form_widget_form" which is quite strange.
---------------------------------------------------------------------------
by bschussek at 2012-04-26T16:34:04Z
@Tobion "simple" and "compound" then?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T16:49:58Z
no "field" and "compound"
---------------------------------------------------------------------------
by bschussek at 2012-04-26T17:17:02Z
I don't like "field" for a simple reason: Consider the "date" type. We are typically speaking of the "date" field there. But technically, the "date" field is a compound field. So?
---------------------------------------------------------------------------
by Tobion at 2012-04-26T21:17:37Z
I don't understand the open question. You proposed "is_field" and "form_widget_field" yourself. So calling the template block "form_widget_field" is a comprehensible consequence of "is_field". I wouldn't call the date type with multiple inputs a field.
---------------------------------------------------------------------------
by tristanbes at 2012-04-26T21:52:39Z
We should take a decision cause right here i got all my forms that are broken because of the empty collection rendering as input field :-).
I guess we are many in that situation.
---------------------------------------------------------------------------
by bschussek at 2012-04-27T08:28:16Z
I renamed "primitive" to "single_control" now to match with the HTML specification which names all input elements (input, select etc.) "controls". The opposite is now "compound".
Meanwhile, I added a fix for #4118.
@fabpot This is ready for merge now.
---------------------------------------------------------------------------
by Tobion at 2012-04-27T10:22:49Z
Hm, I know naming things is hard and sometimes not really important. But since users need to know which block to override, it is essential to make it clear. I think there is still one issue.
The block is named `form_widget_single_control` in order, as you said, to abstract away if it's an input, select etc. But in fact it can only render `input` and nothing else. So this is misleading.
So you could also simply name it `form_widget_input`.
Apart from that I agree with everything.
English:
The value is not a country.
Danish translation in the latest commit:
Denne værdi er ikke et land.
Danish translation in the first commit and mine version:
Værdien er ikke et land
So this commit is simply to make the danish translation the same, and
not two different expressions..
Commits
-------
6756f28 [Session] Fixed Backward Compatibility issue with getFlashes()
Discussion
----------
[Session] Fixed Backward Compatibility issue with getFlashes()
---------------------------------------------------------------------------
by fabpot at 2012-04-25T22:35:42Z
ping @drak
---------------------------------------------------------------------------
by willdurand at 2012-04-25T22:37:01Z
By the way, I had this issue on a real application I upgraded from Symfony2 2.0.x to 2.1 (and written by @Seldaek)
The code looks like:
``` php
<?php
// in a controller
$this->session->setFlash('foo', array(
'code' => 'success',
'message' => 'lalala',
'params' => array())
);
```
---------------------------------------------------------------------------
by Seldaek at 2012-04-26T07:25:03Z
Yup, to be fair in retrospective maybe that should have been translated in the controller directly (that's why it had message + params as an array), but this is code that predates 2.0 by at least six months, so it was obviously not clear what best practices were. Anyway it seems it can be fixed without much harm, so for the sake of safety and because I may not be the only crazy person having done this, it'd be good to fix IMO.
Commits
-------
1c03a16 [Process] Fixed ProcessFailedException not populating exception message due to a missing sprintf parameter
Discussion
----------
[Process] Fixed ProcessFailedException not populating exception message ...
...due to a missing sprintf parameter
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: http://travis-ci.org/#!/proofek/symfony/builds/1172817
Fixes the following tickets: -
Todo: -
Found the issue when started using Cilex with Process and raised an exception using ProcessFailedException. Not sure whether this will get into the main release, as I couldn't find that on 2.0 branch, so I am guessing it's quite a recent addition to Process component.
Commits
-------
4171305 [Console] Use proc_open instead of exec to suppress errors when run on windows and stty is not present
Discussion
----------
[Console] Use proc_open instead of exec to suppress errors.
stty is *sometimes* there on windows, but not always, so with proc_open we can quietly return null instead of outputting errors.
/cc @gnutix: that's the error you told me about this morning in https://gist.github.com/2478037
---------------------------------------------------------------------------
by maoueh at 2012-04-24T17:46:25Z
Thx, I'm getting this in my output each time an exception is thrown in CLI. Good this should fix it :)
Commits
-------
9f0daf4 put parentheses back
885104c fix typo
Discussion
----------
fix typo
Fix typo introduced in #4069
Past participle of `read` is `read`
The WebProcessor can now be registered as a kernel.request listener to
get the request instead of passing it as a constructor argument, which
was broken as the request is not yet available when the logger is
instantiated.
Commits
-------
2e7d3b1 http_build_query fix
de73de0 http_build_query fix
3b7ee9a http_build_query fix
Discussion
----------
[2.0] http_build_query extra parameters
Bug fix: yes
arg_separator.output is not always "&", so it is better ini_set it or put an extra parameters to http_build_query
---------------------------------------------------------------------------
by fabpot at 2012-04-23T10:20:05Z
Can you squash your commits? It will be much easier to get back to this change later on. Thanks.
---------------------------------------------------------------------------
by Ziumin at 2012-04-23T10:46:35Z
I have no idea how to do it using web interface. I'm not familiar with git (prefer hg). Sorry.
Commits
-------
f7200e4 [Form] added method `guessPattern` to FormTypeGuesserInterface
Discussion
----------
[Form] add guess pattern
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: https://github.com/symfony/symfony/issues/3766
Todo: -
Due to some trouble when rebase my previous PR i open a new one with Master merged
Refs PR: https://github.com/symfony/symfony/pull/3927
---------------------------------------------------------------------------
by fabpot at 2012-04-23T10:25:57Z
@vicb @bschussek ok for you?
---------------------------------------------------------------------------
by bschussek at 2012-04-23T10:26:51Z
please do also rephrase the commit message to something clearer, like
[Form] added method `guessPattern` to FormTypeGuesserInterface
---------------------------------------------------------------------------
by bschussek at 2012-04-23T10:27:35Z
Otherwise this looks good :)
---------------------------------------------------------------------------
by ruian at 2012-04-23T10:29:18Z
every changes done
Commits
-------
40df3bf Add mongodb session storage
Discussion
----------
[HttpFoundation][Session] Add mongodb session storage
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by Baachi at 2012-04-19T19:05:19Z
Review please :)
---------------------------------------------------------------------------
by Baachi at 2012-04-19T19:49:42Z
@stof Can be merged?
---------------------------------------------------------------------------
by stof at 2012-04-19T19:51:28Z
I'm not a Mongo expert but it seems fine. You simply need to wait @fabpot's final review now
---------------------------------------------------------------------------
by Baachi at 2012-04-19T19:52:53Z
Okay, thanks :)
---------------------------------------------------------------------------
by Baachi at 2012-04-20T06:21:52Z
@vicb Sorry, for the email flood :)
I implemented all your suggestions.
---------------------------------------------------------------------------
by fabpot at 2012-04-22T08:27:19Z
@drak, @vicb: Is it ok now?
---------------------------------------------------------------------------
by vicb at 2012-04-22T08:33:31Z
I am ok with this PR
Commits
-------
e3296cb fix php5.4 problem
c2405c0 fix hanging of unit tests on Windows
Discussion
----------
[WIP] [Process] Fix hanging of unit tests on Windows
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #3798
Todo: -
This PR tries to fix hanging unit tests on Windows platform. The problem is caused by known [PHP bug](https://bugs.php.net/bug.php?id=51800). PHP hangs forever while reading from STDOUT pipe if the output is too big.
I tried different combinatios and this is not ideal, but a working patch - STDOUT is sending to a file.
@Tobion, @drak and other developers working on Windows - can you please confirm, if this solution works for you, too?
---------------------------------------------------------------------------
by Seldaek at 2012-04-22T20:56:20Z
Tried it on 5.4.0 - I get the following when I checkout your branch:
```
SS..........ESSSSSSSSSS...E.S
Time: 0 seconds, Memory: 19.75Mb
There were 2 errors:
1) Symfony\Component\Process\Tests\ProcessTest::testProcessResponses with data set #0 ('output', 'getOutput', 'echo \'output\';')
Undefined offset: 1
C:\Users\seld\Web\symfony\framework\src\Symfony\Component\Process\Process.php:342
C:\Users\seld\Web\symfony\framework\src\Symfony\Component\Process\Process.php:168
C:\Users\seld\Web\symfony\framework\src\Symfony\Component\Process\Tests\ProcessTest.php:46
2) Symfony\Component\Process\Tests\ProcessTest::testIsRunning
Undefined offset: 1
C:\Users\seld\Web\symfony\framework\src\Symfony\Component\Process\Process.php:342
C:\Users\seld\Web\symfony\framework\src\Symfony\Component\Process\Tests\ProcessTest.php:106
```
When I remove the skipping of `ProcessTest::testProcessPipes` - it still hangs so it looks like your fix is not working.
Just for reference, with latest master checkout I get this:
```
SS...........SSSSSSSSSS.....S
Time: 2 seconds, Memory: 19.75Mb
OK, but incomplete or skipped tests!
```
Don't have time right now, but if I find time to look at your diff in more details I will, maybe it's possible to fix it.
---------------------------------------------------------------------------
by pulzarraider at 2012-04-22T22:23:05Z
@Seldaek Thanks, fixed php5.4 problem, my php5.3.8 passed every Process tests.
This patch isn't fixing problem with pipes in general. I don't think it's even possible from PHP code. We have to wait for PHP core developers to fix this problem. This patch only fix issue with hanging unit tests (not the one with pipes you mentioned). In my environment, symfony unit tests never finished and hangs on SwitchUserTest from SecurityBundle on 98%. Now with this patch, I can see final informations about all tests and their errors.
---------------------------------------------------------------------------
by Seldaek at 2012-04-23T07:44:16Z
Ok, it passes again on 5.4.
Commits
-------
bc8855e [2.1][Component][ClassLoader] cs
Discussion
----------
[2.1][Component][ClassLoader] cs
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
---------------------------------------------------------------------------
by fabpot at 2012-04-23T06:18:26Z
Can you please remove the changes you have already made in the other PR as I merge 2.0 into master regularly. Then, you will need to squash you commits to avoid any conflict when merging will occur. Thanks.
---------------------------------------------------------------------------
by gajdaw at 2012-04-23T06:50:58Z
I hope that's it.
Commits
-------
e344609 [DependencyInjection] Fixed composer.json
1aa0786 [FrameworkBundle] Fixed composer.json
3601f61 [DoctrineBridge] Fixed composer.json
Discussion
----------
Fix composer json
---------------------------------------------------------------------------
by jalliot at 2012-04-22T14:22:24Z
`suggest` no longer requires a version constraint. While you're at it, maybe you could change those to more meaningful strings explaining what each optional dependency provides.
---------------------------------------------------------------------------
by willdurand at 2012-04-22T14:24:27Z
I know, but the version is fine. It's more up to @fabpot to add description in each `suggest` entries.
Anyway, this is not the purpose of this PR. If you want to contribute on that, feel free :)
Commits
-------
dff92e7 [Bridge][Monolog] Fixed WebProcessorTest
Discussion
----------
[Bridge][Monolog] Fixed WebProcessorTest
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes [](http://travis-ci.org/michal-pipa/symfony)
Fixes the following tickets: -
Todo: -
Fixed WebProcessorTest in compliance with latest monolog changes: Seldaek/monolog@3c4bc178cc.
Test was failing with message: `Symfony\Bridge\Monolog\Tests\Processor\WebProcessorTest::testUsesRequestServerData
Undefined index: SERVER_NAME`
---------------------------------------------------------------------------
by ManuelAC at 2012-04-22T13:47:59Z
👍
---------------------------------------------------------------------------
by willdurand at 2012-04-22T13:49:27Z
👍
Commits
-------
e509e6f Skip PDOSessionHandlerTest if PDO SQLite is not available
Discussion
----------
Skip PDOSessionHandlerTest if PDO SQLite is not available
Commits
-------
128ac26 Added missing '%' in DI component README
Discussion
----------
Added missing '%' in DI component README
---------------------------------------------------------------------------
by ruian at 2012-04-21T10:37:12Z
@fabpot PR ok
