Upgrade to Symfony 3.4

[wbloszyk]

Hello,

My name is Wojciech Błoszyk, a PHP developer from Poland. I work with sonata-project bundles for many years.

I want upgrade sandbox for 3.0 (stable) to use Symfony 3.4 (minimum require for ecommerce 3.x)

Work i done for now:

• [x] create new symfony project
• [x] configure require bundles
• [x] extends bundles
• [x] fix bin/load_data.php and fixtures (without LoadOrderData)
• [x] quick fix blocks to run alfa version with bugs

Work to do:

• [x] run Test
• [x] add User Block
• [x] fix TwitterEmbedTweetBlockService
• [x] fix LoadOrderData Fixtures
• [x] upgrade behat to 3.4
• [x] config and check API
• [x] update documentation
• [x] change assetic to assets or symfony/webpack-encore
• [ ] config travis

Also i have questions:

1. Should I renew User Block in SonataUserBundle or create it in SonataDemoBundle?
2. Could someone help me with Test and travis config?
3. Do u have any roadmap for sonata bundles?

link to my fork - branch 3.0

[greg0ire]

Hey! Thanks for working on this!

1. I don't understand the question, maybe elaborate?
2. Sure, what's the issue? If you create a PR, tests will run.
3. We don't, sorry.

[wbloszyk]

BlockService: sonata.user.block.account and sonata.user.block.menu are in SonataUserBunle >= 3.x. Missing in 4.x. Now i add them to SonataDemoBundle. Better solution will be:

• add this blocks to SonataBlockBundle (based on Symfony-UserInterface)
• extends them in SonataDemoBundle or SonataUserBundle (based on Sonata UserInterface)

Also make some change in SonataBlockBundle to make it more stanadalone:

• move BlockAdmin and Entity from SonataPageBundle (of course with deprecated)
• add extra bundle config for define Block which developer set for site owner editing
• script for generate them in seperate Admin without delete posibility

[greg0ire]

The fewer dependencies between block and user bundle, the better IMO, so I think extending it in SonataDemoBundle would be ok.

[wbloszyk]

Some update! I done! Of course some are some things to like:

• format code
• update documentation
• config new futures like liip/monitor-bundle

For stable version is needed:

• stable sonata-project/ecommerce 3.x
• stable sonata-project/page-bundle 4.x
• fix sonata-project/block-bundle (issue with macro not in some block scope) (i override this template)
• fix ProductController:view (it is redirecting to viewActionAction)
• fix rest route (now i cant import route from service)

Should i create PR with current code? It can be tag as 4.0@dev. Or w8 for stable version and finish update all project code?

[greg0ire]

You can completely create a PR right now, not an issue. That way you can get feedback, and it does not mean we are forced to merge it immediately anyway :)

[wbloszyk]

Ok. I will update documentation then make PR.

[wbloszyk]

Before i create PR can you reorganize branches?

Archive branches

Mark this bundles as archive/2.x

• 2.0
• 2.1
• 2.2
• phpcr

Branches with bug fix support only

Make only stable version after fix composer (in future)

• 2.3 - merge 2.3 and 2.3-develop
• 2.4 - make 2.4-develop stable and rename it

Maintained version

Create this branches after make stable version in -develop version

• 3.0 for Symfony 3.4 stable version
• 4.0 for Symfony 4.4 stable version

Develop version

• 3.0-develop for Symfony 3.4 stable version (rename 3.0)
• 4.0-develop for Symfony 4.4 stable version (create it for my PR)

It will be more understandable naming.

[wbloszyk]

Update. What do you think about it? @Bladrak, @rande ,@greg0ire, @phansys

[greg0ire]

Mark this bundles as archive/2.x

Does that mean removing the branches or what?

[greg0ire]

The sandbox is not a bundle, not sure we really need to maintain all these branches. IMO, if we want to revive the sandbox, we should just have one branch with the latest version of Symfony (bear in mind that Symfony 5 is for this month).

[core23]

IMHO we can drop all branches, except the master branch

[wbloszyk]

At first I working on stable Symfony3.4. It is easy way to upgrade for Symfony4. I made behat test working (without api) and got some errors. Some of it (like "Login" => "Log in" button rename) i fix. Other need change in ecommerce.

I'm working on 3.0 branch to make is stable. After that and release Symfony 4.4 i upgrade sandbox. Then we decide what to do with other branches. @greg0ire

Symfony 4.4 is long term support. @core23

BTW I this week I want release sandbox-develop version to easy fix ecommerce (by using tests).

[wbloszyk]

@greg0ire @core23 can u release SonataBlockBundle in 3.x branch? I need fix macros issue in stable version.

[greg0ire]

@wbloszyk you mean 4.x, right?

[wbloszyk]

@greg0ire

roadmap for sandbox releases:

sandbox 3.x-dev: (Support for ecommerce 3.x minimum dependencies - symfony/symfony 3.4).

• today

sandbox 3.x:

• fix some code
• release SonataBlockBundle 3.18.3 or 3.19 (macros issue)
• merge SonataEcommerce#634 and release new version

sandbox 4.x:

• release SonataEcommerce 4.0

[greg0ire]

My bad, we indeed have an unreleased commit in 3.x, I'll fix this

[greg0ire]

Released :) https://github.com/sonata-project/SonataBlockBundle/releases/tag/3.18.3

[wbloszyk]

@greg0ire thanks

[wbloszyk]

@greg0ire Can u release next ecommerce minor version? This is last dev version in sandbox.

[greg0ire]

Ping me if I forget to do it this week-end

[wbloszyk]

@core23 @greg0ire Can you review SonataUserBundle#1136?

It is last dependencies to update sandbox without additional code. After merge I will update sandbox:3.x, then update roadmap for this version and prepere for sandbox:4.0.

[wbloszyk]

This issue was resolved in upgrade process. More information here: https://github.com/sonata-project/sandbox/pull/616