Commits
-------
0be8820 [FrameworkBundle] fixed small typo in Czech translation
Discussion
----------
[FrameworkBundle] fixed small typo in Czech translation
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
fixed small typo in Czech translation in validators.cs.xliff
Commits
-------
09562df Update CHANGELOG for 2.1, describe new auth events
cf09c2d added authentication success/failure events
Discussion
----------
[Security] Implementation of a "failed login" event, replaces: PR #1307
As I have to use this feature I have completed its implementation.
Bugfix: no
Feature addition: yes
Symfopny2 tests pass: yes
Replaces/closes PR: #1307
---------------------------------------------------------------------------
by schmittjoh at 2011/11/18 23:57:56 -0800
Usually, this event is used for the wrong reasons (to customize what happens on authentication failure). Can you move your implementation to the AuthenticationProviderManager instead?
see https://github.com/schmittjoh/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/AuthenticationProviderManager.php#L103
---------------------------------------------------------------------------
by canni at 2011/11/19 06:00:36 -0800
Good point :) I'll not rewrite yours work, I've cherry-picked yours commits. (BTW you added call to `setEventDispatcher` on `security.authentication.manager` to commit related to some different work ;)
---------------------------------------------------------------------------
by fabpot at 2011/11/22 00:12:19 -0800
The new files are missing the LICENSE header. As far as I can see, @schmittjoh fork has a different license from the Symfony one. This needs to be clarified before I can merge this PR.
---------------------------------------------------------------------------
by schmittjoh at 2011/11/22 01:53:09 -0800
No biggy, MIT is fine here.
---------------------------------------------------------------------------
by canni at 2011/11/22 01:57:51 -0800
@fabpot done
---------------------------------------------------------------------------
by fabpot at 2011/11/22 02:22:47 -0800
@canni: Can you update the CHANGELOG file (to reference the changes and the BC breaks -- like the move of KernelEvents for instance).
---------------------------------------------------------------------------
by canni at 2011/11/22 02:40:33 -0800
@fabpot: no problem & done
PS I haven't realized that namespace change of `SecurityEvents` is actually a BC Break, thx for pointing this.
---------------------------------------------------------------------------
by fabpot at 2011/11/22 03:06:17 -0800
@canni: What about keeping a `SecurityEvents` class in the `Http` namespace that just extends the new one. That way, we don't break BC.
---------------------------------------------------------------------------
by canni at 2011/11/22 03:53:01 -0800
@fabpot: that will force us to remove `final` keyword form one of classes.
Maybe we can add new, not extending class e.g.: `GeneralSecurityEvents` or `AuthenticationEvents`, that way we dont break BC and dont introduce confusion in naming?
---------------------------------------------------------------------------
by canni at 2011/11/22 05:53:15 -0800
@fabpot: I've removed the BC break, and squashed schmittjoh commits, to keep things nice and clear.
Commits
-------
47ebf08 Fix some bugs
fad825e Add DoctrineValidationPass to DoctrineBundle#buildContainer
a064acd Implement feature to add validations based on the Manager-Type (ORM, MongoDB, CouchDB)
Discussion
----------
[WIP] Validation on a Doctrine Manager Basis
Hello,
we have had problems before with validation that is "persistence" related. Unique-validators or any other validation that is based on services that depend on persistence.
The problem is two-fold:
1. In annotations you cannot define validators for all persistence layers you support, because then users need them all installed.
2. In XML/YAML the same is true, since there is only one validation.xml or validation.yml file looked for.
Now one solution is to have three model classes that extend from a base class to get around this (like FOSUserBundle does) but that is cumbersome. This PR provides a new solution that is Doctrine specific (and takes the responsibility out of the Core).
Each Doctrine Bundle (ORM, CouchDB, MongoDB, PHPCR) can add this compiler pass with a manager type name:
$container->addCompilerPass(new DoctrineValidationPass('orm'));
This leads to the compiler pass searching for additional validation files "Resources/config/validation.orm.yml" and "Resources/configvalidation.orm.xml".
My first idea was to put this into the Resources/config/doctrine folder as well, but then it is detected as mapping file of course.
Regarding tests, this is not easily testable without a full fledged bundle setup, i tested this inside Acme Demo Bundle, however for a good unit-test we probably need a filesystem abstraction testing layer. Has anyone a good idea how to test this without having to setup another test-bundle? I can't use the one from DoctrineBundle since this code is in the Bridge.
---------------------------------------------------------------------------
by fabpot at 2011/11/13 23:12:06 -0800
@beberlei: Is it still WIP?
---------------------------------------------------------------------------
by beberlei at 2011/11/15 10:47:49 -0800
@fabpot it is complete, but it has no tests, that was the WIP part. :-)
---------------------------------------------------------------------------
by mvrhov at 2011/11/15 23:56:11 -0800
I wanted to refactor how validation is managed today, so it could do one validation file per class, same as with Doctrine but @stof pointed me to this PR. I still find this a great idea as the validation is easier to find.
```php
foreach ($container->getParameter('kernel.bundles') as $bundle) {
$reflection = new \ReflectionClass($bundle);
$bundleDir = dirname($reflection->getFilename());
//check for per class validation files
if (is_dir($dir = $bundleDir . '/Resources/config/validation')) {
$finder = new Finder();
$finder
->name('*'.$extension)
->in($dir);
foreach ($finder as $file) {
$files[] = realpath($file);
$container->addResource(new FileResource($file));
}
}
//global validation file?
if (is_file($file = $bundleDir . '/Resources/config/validation'.$extension)) {
$files[] = realpath($file);
$container->addResource(new FileResource($file));
}
}
```
Commits
-------
fabe818 [EventDispatcher] Add reference to the EventDispatcher on the Event
Discussion
----------
[EventDispatcher] Add reference to the EventDispatcher on the Event
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
I don't like registering event listeners unless they are really used, it seems wasteful. So I tend to register listeners for the response event in other listeners, only when they will be required. @stof has [brought to my attention](fb243ace83 (commitcomment-696467)) that this may cause issues in Silex or any other situation where event listeners are not lazy loaded, since it creates a circular reference in that case.
With this PR, avoiding the circular reference is possible, without bloating the response listener with unnecessary "do I need to do anything?" code.
---------------------------------------------------------------------------
by schmittjoh at 2011/11/06 05:28:39 -0800
Did you do any benchmarks? It's just a feeling, but registering a listener at runtime might be more expensive than just having it always executed.
Also, I find these dynamic listeners a bit of a code smell. They are not easily testable, and the control flow is harder to track. Besides, you do not take into account subrequests which might happen in between.
---------------------------------------------------------------------------
by Seldaek at 2011/11/06 09:34:27 -0800
I don't see why it would be slower, if it's a commonly fired event yes you blast away the `sorted` listener cache every time you add one, but most of the time those optional listeners are for the response, which is typically not sorted yet when you add the listener, so I don't think there is any overhead.
As for the code smell, of course it's a matter of preference, but I have the opposite view on control flow, I find it weird that listeners are registered when they are not used in the end, while doing it my way I think it's more clear what happens.
For sub-requests, I'm not sure what you mean. In this instance, and in most response listeners I have seen, the sub-requests are always ignored anyway by the listener.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:07:45 -0800
I don't see how loading up the dispatcher with a bunch of callables can be expensive - it's just loading an array basically.
Wouldn't it be better to have a separate `DispatcherAwareEvent extends Event`
class DispatcherAwareEvent extends Event
{
protected $dispatcher;
public function setDispatcher(EventDispatcher $dispatcher)
{
$this->dispatcher = $dispatcher;
}
public function getDispatcher()
{
return $this->dispatcher;
}
This can then be used as a base class for what you need `MyEvent extends DispatcherAwareEvent`
$event = new MyEvent($dispatcher, $foo);
$dispatcher->dispatch($event);
---------------------------------------------------------------------------
by Seldaek at 2011/11/10 06:18:57 -0800
@drak: Every event is part the event dispatching system and therefore should be aware of the dispatcher imo. It's not like the ContainerAwareInterface which is gluing things that do not especially have to know about the DIC together.
If we do that, then we have to start arguing every time we need the dispatcher in a given event, because the original author did not think it was necessary, and then that will only make it into the next minor version, etc. Not fun at all.
---------------------------------------------------------------------------
by drak at 2011/11/10 06:36:26 -0800
By the way, the event dispatchers looks to be pretty well optimized given the fact that it only sorts listeners if they are called, and then only once.
---------------------------------------------------------------------------
by drak at 2011/11/10 12:33:28 -0800
It just seems weird. I mean, following on, why isn't the event name a compulsory parameter also? - again, you can say both ways, if you need it, make it part of your custom Event class, or since it's a required param to be able to dispatch an event in the first place, make it part of the base Event class. All I'm saying it it seems suspicious when it could be achieved a different way.
For example, you could inject the dispatcher into the listener itself and then the event handler could access the dispatcher if it needs:
class MyListener
{
public function __construct(EventDispatcher $eventDispatcher)
{
//...
}
public function someListener(Event $event)
{
//...
}
}
---------------------------------------------------------------------------
by stof at 2011/11/10 15:20:07 -0800
@drak The issue when injecting the dispatcher in the listener is described in the issue: circular dependency: you need to create the dispatcher before the listener (as it is injected in it) and when the listener is not lazy-loaded (in Silex for instance), you need to create it before the dispatcher.
---------------------------------------------------------------------------
by drak at 2011/11/10 21:15:45 -0800
Indeed, although it might not unreasonable to expect to create the dispatcher first... but anyway I'm convinced!
Injecting the dispatcher could lead to some __very interesting possibilities__ as standard. While we are at it though, we should have a getter and setter for `$name` in the `Event` class and `$event->setName($eventname)` in the `dispatch()` method. Allowing an event to know it's name is very useful. It allows a single listener to be registered for multiple names, and even makes the event object reusable. I don't know why $name was removed, it was in the Symfony 1 dispatcher and while the new dispatcher is brilliant from an OO point of view, missing the name as standard is a big shame.
+1 from me.
Commits
-------
413756c [BC break][SecurityBundle] Changed the way to register factories
Discussion
----------
[BC break][SecurityBundle] Changed the way to register factories
As discussed in #2454, this changes the way to register the factories to let each bundles register the factories it provides.
Commits
-------
2adc36c [Security] renamed security option to erase_credentials
104b697 [Security] added configurable option security.erase_credentials_from_token
ede55d2 [Security] added configuration parameter for AuthorizationManagerProvider
Discussion
----------
[Security] added configuration parameter to AuthorizationManagerProvider
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: 2657
Todo: -
---------------------------------------------------------------------------
by fabpot at 2011/11/16 10:30:34 -0800
You should also add a configurable option under the `security` entry to ease the configurability.
Commits
-------
6d7e6a8 [DoctrineBundle] Enhance error reporting during mapping validation when nested exceptions occur.
Discussion
----------
Doctrine info mapping exception
Better error handling when nested exceptions occur (which is commonly possible with reflection errors).
---------------------------------------------------------------------------
by fabpot at 2011/11/16 02:10:13 -0800
It should probably be done on the 2.0 branch, no?
---------------------------------------------------------------------------
by beberlei at 2011/11/18 02:11:06 -0800
Its not necessarily a bugfix but an enhancement.
Commits
-------
d2195cc Fixed phpdoc and updated the changelog
9e41ff4 [SecurityBundle] Added a validation rule
b107a3f [SecurityBundle] Refactored the configuration
633f0e9 [DoctrineBundle] Moved the entity provider service to DoctrineBundle
74732dc [SecurityBundle] Added a way to extend the providers section of the config
Discussion
----------
[WIP][SecurityBundle] Added a way to extend the providers section of the config
Bug fix: no
Feature addition: yes
BC break: <del>no (for now)</del> yes
Tests pass: yes
This adds a way to extend the ``providers`` section of the security config so that other bundles can hook their stuff into it. An example is available in DoctrineBundle which is now responsible to handle the entity provider (<del>needs some cleanup as the service definition is still in SecurityBundle currently</del>). This will allow PropelBundle to provide a ``propel:`` provider for instance.
In order to keep BC with the existing configuration for the in-memory and the chain providers, I had to allow using a prototyped node instead of forcing using an array node with childrens. This introduces some issues:
- impossible to validate easily that a provider uses only one setup as prototyped node always have a default value (the empty array)
- the ``getFixableKey`` method is needed in the interface to support the XML format by pluralizing the name.
Here is my non-BC proposal for the configuration to clean this:
```yaml
security:
providers:
first:
memory: # BC break here by adding a level before the users
users:
joe: { password: foobar, roles: ROLE_USER }
john: { password: foobarbaz, roles: ROLE_USER }
second:
entity: # this one is BC
class: Acme\DemoBundle\Entity\User
third:
id: my_custom_provider # also BC
fourth:
chain: # BC break by adding a level before the providers
providers: [first, second, third]
```
What do you think about it ? Do we need to keep the BC in the config of the bundle or no ?
Btw note that the way to register the factories used by the firewall section should be refactored using the new way to provide extension points in the extensions (as done here) instead of relying on the end user to register factories, which would probably mean a BC break anyway.
---------------------------------------------------------------------------
by lsmith77 at 2011/10/23 09:19:23 -0700
i don't think we should keep BC. the security config is complex as is .. having BC stuff in there will just make it even harder and confusing.
---------------------------------------------------------------------------
by willdurand at 2011/10/23 09:41:25 -0700
Is the security component tagged with `@api` ?
So basically, we just have to create a factory (`ModelFactory` for instance) and to register it in the `security` extension, right ? Seems quite simple to extend and much better than the hardcoded version…
Why did you call the method to pluralize a key `getFixableKey` ?
---------------------------------------------------------------------------
by beberlei at 2011/10/23 14:48:26 -0700
Changing security config will introduce risk for users. We should avoid that
---------------------------------------------------------------------------
by stof at 2011/10/23 15:34:47 -0700
@beberlei as the config is validated, it will simply give them an exception during the loading of the config if they don't update their config.
---------------------------------------------------------------------------
by stof at 2011/10/24 01:01:42 -0700
@schmittjoh @fabpot Could you give your mind about it ?
---------------------------------------------------------------------------
by stof at 2011/10/31 17:08:12 -0700
@fabpot @schmittjoh ping
---------------------------------------------------------------------------
by stof at 2011/11/11 14:08:18 -0800
I updated the PR by implementing my proposal as the latest IRC meeting agreed that we don't need to keep the BC for this change. This allows to add the validation rule now.
---------------------------------------------------------------------------
by stof at 2011/11/16 11:16:06 -0800
@fabpot ping
---------------------------------------------------------------------------
by fabpot at 2011/11/16 22:29:05 -0800
@stof: Before merging, you must also add information about how to upgrade in the CHANGELOG-2.1.md file.
---------------------------------------------------------------------------
by stof at 2011/11/17 00:01:23 -0800
@fabpot done
The Firewall is now executed after the Router. This was needed to have access
to the locale and other request attributes that are set by the Router. This
change implies that all Firewall specific URLs have proper (empty) routes like
`/login_check` and `/logout`.
Commits
-------
f83ef1e [DoctrineBundle] Fix tests - incorrect class names (copy paste error most probably)
Discussion
----------
[DoctrineBundle] Fix tests - incorrect class names
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Some classes are incorrectly named resulting in failed tests for DoctrineBundle, looks like a copy paste error.
* 2.0:
[HttpKernel] fixed Content-Length header when using ESI tags (closes#2623)
[HttpFoundation] added an exception to MimeTypeGuesser::guess() when no guesser are available (closes#2636)
[Security] fixed HttpUtils::checkRequestPath() to not catch all exceptions (closes#2637)
[DoctrineBundle] added missing default parameters, needed to setup and use DBAL without ORM
[Transation] Fix grammar.
[TwigBundle] Fix trace to not show 'in at line' when file/line are empty.
Commits
-------
4858fbe [TwigBundle] Fix trace to not show 'in at line' when file/line are empty.
Discussion
----------
[TwigBundle] Fix trace to not show 'in at line' when file/line are empty.
Occasionally I saw call stacks where file/line are empty in the raw exception object, but the trace.html.twig file was still showing 'in at line' with empty values. I believe this fixes that.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
---------------------------------------------------------------------------
by fabpot at 2011/11/09 22:49:35 -0800
The current code looks correct to me. Can you try with the latest version of Twig to be sure that you don't have this issue because of a bug in Twig that has been fixed since then?
---------------------------------------------------------------------------
by dpb587 at 2011/11/10 07:20:34 -0800
Thanks for the feedback. Should I change my patch to check that both are defined and non-empty, such as `trace.file is defined and trace.file and trace.line is defined and trace.line`?
I think the issue is that I'm seeing the file and line keys are defined but empty. I created another branch with a pseudo-test case that shows a little more information. Using symfony-standard with symfony in deps as follows and symfony/twig removed from deps.lock.
[symfony]
git=git://github.com/dpb587/symfony.git
version=origin/patch-trace-debug
Then running the following:
phpunit -c app/ vendor/symfony/tests/Symfony/Tests/Bundle/TwigBundle/Controller/ExceptionController.php
The test (is backwards) and passes, dumping the following (this call happens right after a call_user_func):
Array
(
[namespace] => Symfony\Bundle\FrameworkBundle\EventListener
[short_class] => RouterListener
[class] => Symfony\Bundle\FrameworkBundle\EventListener\RouterListener
[type] => ->
[function] => onKernelRequest
[file] =>
[line] =>
[args] => Array
(
[0] => Array
(
[0] => object
[1] => Symfony\Component\HttpKernel\Event\GetResponseEvent
)
)
)
I saw the same results with two php versions:
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH
PHP 5.3.8 (cli) (built: Nov 4 2011 05:43:22)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with the ionCube PHP Loader v4.0.10, Copyright (c) 2002-2011, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
Sorry if I'm simply missing something or doing something silly.
---------------------------------------------------------------------------
by fabpot at 2011/11/11 13:12:21 -0800
`trace.file is defined and trace.file and trace.line is defined and trace.line` looks good to me.
* 2.0:
[Form] fixed previous merge
[Form] simplified previous merge
Also identify FirePHP by the X-FirePHP-Version header
[TwigBundle] Extract output buffer cleaning to method
[TwigBundle] Do not clean output buffering below initial level
Fixed rendering of FileType (value is not a valid attribute for input[type=file])
Added tests for string fix in DateTimeToArrayTransformer (8351a11286).
Added check for array fields to be integers in reverseTransform method. This prevents checkdate from getting strings as arguments and throwing incorrect ErrorException when submitting form with malformed (string) data in, for example, Date field. #2609
[Translation] removed unneeded methods
[Translation] added detection for circular references when adding a fallback catalogue
[DomCrawler] trim URI in getURI
[Yaml][Tests] Fixed missing locale string for Windows platforms which caused test to fail
The configuration is now cleaner by avoiding using prototyped nodes
as additional keys. This is a BC break for existing providers.
- MemoryProvider:
security:
providers:
my_provider:
memory: # this level has been added
users:
# ...
- ChainProvider:
security:
providers:
my_provider:
chain: # This level has been added
providers:
# ...
Commits
-------
29e12af [TwigBundle] Extract output buffer cleaning to method
ed1a6c2 [TwigBundle] Do not clean output buffering below initial level
Discussion
----------
[TwigBundle] Do not clean output buffering below initial level
This resulted in issues with PHPUnit 3.6, which will buffer all output and clean them in the end. Since
we cleaned their buffer, the subsequent clean would raise a warning. This is documented in [issue 390](https://github.com/sebastianbergmann/phpunit/issues/390) of
the PHPUnit tracker.
Closes#2531.
This also affects FOSRestBundle's ExceptionController /cc @lsmith.
---------------------------------------------------------------------------
by fabpot at 2011/11/11 07:33:24 -0800
I have a similar fix locally but I have not merged it yet as it looks a bit dirty (but I've not a better idea yet). Anyway, your PR is better than mine as you've added some unit tests already.
This resulted in issues with PHPUnit 3.6, which will buffer all output and clean them in the end. Since
we cleaned their buffer, the subsequent clean would raise a warning. This is documented in issue 390 of
the PHPUnit tracker.
Closes#2531.
* 2.0:
Added a class to the logs ol element to prevent hiding it when toggling an exception (fixes#2589).
Remove only the security token instead of the session cookie.
Clear session cookie if user was deleted, is disabled or locked to prevent infinite redirect loops to the login path (fixes#1798).
Commits
-------
d974a4a Merge pull request #4 from stealth35/test_mo_loader
cf05646 delete useless tests
19f9de9 [Translation] fix gettext tests
965f2bf Merge pull request #3 from stealth35/test_mo_loader
9c2a26d [Translation] add Mo loader tests
9af2342 [Translation] Added the gettext loaders
Discussion
----------
[Translation] Added the gettext loaders
This is the squashed version of the work done by @xaav in #634.
@stealth35 you said you will work on the dumpers. do you have some stuff on it ?
---------------------------------------------------------------------------
by drak at 2011/10/24 19:28:43 -0700
Is there any more progress with this?
---------------------------------------------------------------------------
by stealth35 at 2011/10/25 00:57:19 -0700
I work on the dumpers, but the Po loader is wrong, caus' the Po ressource can be multiline,
msgid ""
"Here is an example of how one might continue a very long string\n"
"for the common case the string represents multi-line output.\n"
http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files
Anyway the Po format is an intermediate format to Mo file, (like .txt to .res file for ICU), IMO we can just support the real gettext format : Mo
---------------------------------------------------------------------------
by stealth35 at 2011/11/03 02:00:24 -0700
@stof The MO Dumper is ready (stealth35/symfony@f2d1d5b4de), should we keep the PO format ?
---------------------------------------------------------------------------
by fabpot at 2011/11/07 08:50:59 -0800
@stealth35: The PO is what people will use for their translations. They will then dump it to MO. So, we need both PO and MO loaders and dumpers.
---------------------------------------------------------------------------
by stealth35 at 2011/11/08 01:25:39 -0800
@fabpot, I'm ready for both dumpers, you can merge this, and I'll open a PR for the dumpers
---------------------------------------------------------------------------
by fabpot at 2011/11/08 22:37:47 -0800
I've just had a look at this PR code again and I see that the unit tests are pretty slim. Is it possible to add some tests for the mo loader?
---------------------------------------------------------------------------
by stealth35 at 2011/11/09 01:15:25 -0800
@fabpot test send to @stof ✌️
---------------------------------------------------------------------------
by stof at 2011/11/09 02:22:55 -0800
and merged in this branch
---------------------------------------------------------------------------
by fabpot at 2011/11/09 02:39:09 -0800
The tests do not pass for me:
There was 1 error:
1) Symfony\Tests\Component\Translation\Loader\MoFileLoaderTest::testLoadDoesNothingIfEmpty
InvalidArgumentException: MO stream content has an invalid format.
/Users/fabien/work/symfony/git/symfony/src/Symfony/Component/Translation/Loader/MoFileLoader.php:79
/Users/fabien/work/symfony/git/symfony/src/Symfony/Component/Translation/Loader/MoFileLoader.php:46
/Users/fabien/work/symfony/git/symfony/tests/Symfony/Tests/Component/Translation/Loader/MoFileLoaderTest.php:34
--
There was 1 failure:
1) Symfony\Tests\Component\Translation\Loader\PoFileLoaderTest::testLoad
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 'foo' => 'bar'
)
/Users/fabien/work/symfony/git/symfony/tests/Symfony/Tests/Component/Translation/Loader/PoFileLoaderTest.php:25
Commits
-------
78883f9 Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Discussion
----------
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}`
Allow syntax like ``{% render "AcmeDemoBundle:Frontend/Default:index" %}``
Bug fix: yes
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #2424
---------------------------------------------------------------------------
by stof at 2011/10/18 07:44:48 -0700
@docteurklein still the same issue. github says it conflicts. Are you sure you fetched the latest version ?
Thus it should be sent to 2.0 IMO as it is a bugfix
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:51:21 -0700
@stof Yes, i'm pretty sure I followed the patches sending flow. (http://symfony.com/doc/2.0/contributing/code/patches.html
My tools are telling me it's ok.
I then merged it into master without any problem, which is up to date with upstream.
Sorry for the inconvenience.
I'll try to send it to 2.0 branch.
---------------------------------------------------------------------------
by docteurklein at 2011/10/18 07:53:52 -0700
@stof, what's wrong with https://github.com/docteurklein/symfony/commits/ticket_2424 ?
---------------------------------------------------------------------------
by stof at 2011/10/18 08:28:21 -0700
hmm, seems like github has an issue when determining if it conflicts or not. It's sad
---------------------------------------------------------------------------
by henrikbjorn at 2011/10/20 09:49:56 -0700
Dosent this already work ? as classes are namespaces the / should be a \ i think ?
Works for routes at least.
Commits
-------
661421f [Doctrine] Remove AbstractDoctrineBundle and move code into Doctrine Bridge
Discussion
----------
[WIP] [Doctrine] Remove abtract doctrine bundle
Remove AbstractDoctrineBundle and move code into Doctrine Bridge. It is a BC break because all the "other" Doctrine Bundles MongoDB ODM, CouchDB ODM and PHPCR need to be updated to cope with this.
I will prepare PRs for them aswell and then remove the [WIP] here.
Bug fix: no
Feature addition: no
Backwards compatibility break: yes
Symfony2 tests pass: yes
Fixes the following tickets: #2463
---------------------------------------------------------------------------
by beberlei at 2011/10/26 12:32:51 -0700
Here are all 3 PRs, can we coordinate on merging them somehow?
https://github.com/symfony/DoctrineMongoDBBundle/pull/50https://github.com/symfony-cmf/symfony-cmf/pull/118https://github.com/doctrine/DoctrineCouchDBBundle/pull/4
---------------------------------------------------------------------------
by beberlei at 2011/10/26 12:33:38 -0700
Ping @lsmith77 @jwage
---------------------------------------------------------------------------
by lsmith77 at 2011/10/26 12:35:29 -0700
all good for me ..
---------------------------------------------------------------------------
by stof at 2011/10/26 14:58:01 -0700
Well, this does not fix#2463. A change done in the bridge will still be able to break the service definitions of the other bundles or require tricky stuff to keep different versions of the logic.
---------------------------------------------------------------------------
by beberlei at 2011/10/26 22:49:39 -0700
@stof true, that is what https://github.com/doctrine/common/pull/71 will be about.
---------------------------------------------------------------------------
by stloyd at 2011/10/26 23:51:25 -0700
Comment just for linking cross PRs and for watching ;-) doctrine/common#71
---------------------------------------------------------------------------
by lsmith77 at 2011/10/31 08:18:45 -0700
please add forward compatibly into symfony 2.0 as per #2522
---------------------------------------------------------------------------
by beberlei at 2011/11/01 05:11:34 -0700
This doesn't make sense imho, since the number of people using the doctrine extension is 4 and everybody also prepared their pull request for this.
The problem is really that we need a branch for the MongoDB Bundle
---------------------------------------------------------------------------
by beberlei at 2011/11/01 05:40:49 -0700
@fabpot i created a branch in MongoDBBundle for 2.0 so this is ready to be merged.
