New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] 7.0 kernel branch #1875

Merged
merged 34 commits into from Dec 15, 2017

Conversation

7 participants
@andrerom
Member

andrerom commented Jan 5, 2017

Related eZ Platform branch: ezsystems/ezplatform#167

This is a WIP PR, changes will come via PR's against this branch. Beneath are some candidates that can be looked into as part of this version bump, however this is not complete list, but rather a living document of technical kernel changes we want to aim for.

Branch info

7.0 branch is acting as a sort of develop branch (ref: git flow), this means the following for contributors and mergers:

Info for contributors (PRs)

Keep on targeting normal changes towards master or stable branches as normal, only breaking changes goes just into 7.0 branch.

E.g: For features that are also relevant to 6.x typically point a PR in a bc safe way towards master, if there is intention for bc breaks in 7.0 on the change that can be kept as temp commit in PR during review. If so merger takes care about applying the relevant changes to master and the 7.0 only there once master is "merged up" into 7.0.

Info for mergers

Specifically, when merging things into master, either from PR or stable branches, try to merge them up into 7.0 afterwards by merging master into 7.0.

7.0 Changes

Done:

  • Bump requirements to Symfony 3.2 (and sensio/distribution-bundle to 5.x)
  • Bump requirements to PHP 7.0 as it is available as of Ubuntu 16.04, Debian 9 and RHSCL 2.3.
  • Change from Stash to Symfony Cache
    • Add doc on this in doc/bc/7.0.md
  • Fixed postgres schema to use conventional sequences (#1906)
  • Removed use of ZetaComponents and QaFoo/RMF

Work In progress/proposed:

  • Decouple API (candidates: repo_structure branch, ...)
  • Improve password hashing security by adding default bcrypt support (#1592)
  • REST content create simplifications (Spec): #1990
  • REST includes: #1741
  • SiteAccess Language aware API: #1966 (part 1 of several future stages)

Candidates for contribution:

To be done as PRs against this branch, if you want to help tackle any of these just comment below.
Side: these notes should be moved over to epics or specs.

  • API:
    • DX efforts to reduce need for helpers, and enrich model for less verbose use by taking advantage of API Cache.
      • Languages (get just what you need, avoid helper use), multi get on value objects, ContentTypeInfo (name, identifier, group meta info, fields meta info, should only need 1 spi lookup, not the heavy building current content type has), add contentTypeInfo on ContentInfo, add Content on Location to make Location root, add LocationInfo to be used where you don't need content (can be used for main location on ContentInfo) , ..
    • Type hint search results
  • Other possible changes: backend_updates branch
  • Field types:
    • Look into simplifying use (across value, type, search index, repo forms, ui, .. use)
  • Installer:
  • Git split:
    • TBD when initial refactorings are done (ezpage out: #1500, storage/search engines, REST, "mVC", potentially also repository if kernel is abandoned or remains as glue package, ..)
    • Switch to PSR-4 as part of this as long as it does not break namspacing of API, SPI, (..)
  • Refactor to remove:
    • Buzz (can be swapped for HTTPlug as used by FOSHttpCache 2.0, see below)
  • Update:
    • mikey179/vfsStream, PHPUnit (done, 5.7 for now), FOSHttpCache (#2013, gets rid of guzzle3 use)

TODO:

  • DON'T MERGE THIS FROM GITHUB INTERFACE! Once ready, just close this PR, merge changes into master from git, and re configure master to 7.1! (leaving this branch for 7.0 release)
  • ADD UPGRADE DOC (even empty if not really needed)
@yukoff

This comment has been minimized.

Show comment
Hide comment
@yukoff

yukoff Feb 15, 2017

JFI: FOSHttpCache got 2.0.0-beta1 recently

yukoff commented Feb 15, 2017

JFI: FOSHttpCache got 2.0.0-beta1 recently

@andrerom andrerom referenced this pull request Feb 24, 2017

Merged

[WIP] 2.0 #167

2 of 3 tasks complete

@ezsystems ezsystems deleted a comment from ezrobot Nov 16, 2017

@andrerom andrerom added this to the 7.x milestone Nov 17, 2017

andrerom and others added some commits Dec 5, 2016

Move kernel to version 7.0 and bump requriments to Symfony 3.3 & PHP 7.1
To begin with this will start as a `7.0` branch, acting as a sort of `develop` branch.
So: keep on targeting changes towards master or stable branches as normal, only breaking
changes goes just into `7.0` branch

For features that are also relevant to 6.x typically in a bc safe way into master, then
adaptions to clean up 7.x into `7.0` branhc as seperate pr afterwards _(can be tmp commit on original PR during review)_.

In regards to PHP 7.1 bump:
Both Symfony 4 and newer versions of Doctrine requires PHP 7.1. And it is now avaiable on RHEL via RHSCL 3.0,
upcomming Debian 17.10, only major distro missing it right now is Debian where it is currently in testing.
So for Debian users this means either using testing packages or use thirdparty packages of PHP 7.1 or 7.2
until official packages reaches stable channel.

[Composer] Bump PHP requirement to 7.1 to align with other v2 packages (and Sf4 + Doctrine DBAL 2.6)
[SPI] Add Content\Handler->loadContentInfoList() and use for loading …
…all in one go when building LocationSearchResult
[7.x] Refactor to use Symfony Cache for performance & better cache cl…
…aring with tags (#1920)

- Removes dependency on Stash
- Improves performance by:
  1. Use Symfony Cache
  2. Use tagging to be able to cache more, and:
  3. allow cache item duplication to avoid extra identifier to id lookups before item lookup
- Reduces code complexity of cache, for instance no cache warming anymore as it was often warming the wrong object
- More reliable, thanks to cache tagging only relevant cache items are cleared on operations, not the whole cache
[Composer] Remove use of ZetaComponents Mail in favour of simple regex
Reason for using simple regex:
- Service is not de-coupled yet to inject Symfony validator cleanly
- Besides: https://davidcel.is/posts/stop-validating-email-addresses-with-regex/
[Composer] Remove usage of QaFoo/RMF
RMF is not in use by the server, so since client anyway needs large refactoring somewhat ignoring that this might furhter break it a bit.
EZP-28247: Creating an new object state does not clear the group cache (
#2150)

* EZP-28247: Creating an new object state does not clear the group cache

This clears the object state group cache when a new object state is created

* Use same cache key as loadObjectStates

* fix the key in loadObjectStates instead
[7.0] EZP-28269: Fixed inconsistent creating of eztime fromTimestamp (#…
…2159)

* EZP-28269: Aligned Time::fromTimestamp with DateAndTime::fromTimestamp

* EZP-28269: Fixed Unit Tests

* EZP-28269: Fixed eztime integration tests

* [Doc] EZP-28269: Updated 7.0 BC doc
[7.0] EZP-28309: Fixed twig template for eztime incorrectly parsing t…
…ime value (#2162)

* EZP-28309: Forces date formatter to use UTC timezone to display correct eztime value

* [Doc] EZP-28269: Updated 7.0 BC doc
[7.0] Update & Simplify install instructions (#2167)
* [7.0] Update install instructions

Now that we require PHP 7.1 and have greatly improved performance of backend placing hinst on performance tuning does not need to take space here anymore.

Besides that:
- updated to use dev, with symfony 3 builtin server is only available in dev by default
- update to use `/admin` url for backend
- somewhat simplified the text a bit

Open question:
- Do we need to run the assetic:dump command? As it's already ran by composer create-project which is what has been done when this is shown, ok if I remove?

* Update ScriptHandler.php

* Update ScriptHandler.php

* Update ScriptHandler.php
CS

@ezsystems ezsystems deleted a comment from ezrobot Dec 11, 2017

webhdx and others added some commits Dec 11, 2017

EZP-28410: Add selection limit setting to ezobjectrelationlist fieldt…
…ype (#2178)

* EZP-28410: Adds selection limit setting to ezobjectrelationlist fieldtype

* EZP-28410: Moves selection limit from `fieldSettings` to `validators` and provides value validation

* EZP-28410: Adds deprecation annotations to Relation fieldtype
EZP-28510: ContentType list for Group is not refreshed after publishi…
…ng ContentType (#2185)

* [Persistence Cache] Invalidated ContentTypeGroup on ContentType publish

* [Unit tests] Updated Cache tests to align with the change

* Created Integration test uncovering the bug
EZP-28375: As a Maintainer I want CI to run tests on behat environmen…
…t of eZ Platform v2 - part 1 (#2166)

* [Travis] Updated ezplatform docker-compose files paths

* [7.0] Updated prepare_behat script to use new meta-repository script

* [Travis] Replaced hardcoded PHP version with proper one for current job

* [Integration Tests] Changed internal name of Sf Cache adapters list

Sf 3.4 compatibility

* [Travis] Added missing EZP-27752 create language command

* EZP-27752: Added Sf command ez:behat:create-language for behat tests

The introduced for behat env command ez:behat:create-language
allows to avoid skipping test for related feature of
deleting Translation from Draft

* [Composer] Bumped Symfony requirement to 3.4 LTS

* [Travis] Simplified and adjusted .travis.yml to meta-repository changes

* [REST] Marked REST Behat test of user content feature as broken

Editing ezuser with ContentService is supported by
PlatformUIBundle (v1) only.

* [TMP] Switched ezplatform branch for behat tests

* [Composer] Change back to use 2.0 branch

* Skip updating docker

[skip ci]

* Temprary disable Function tests to get 7.0 green

[skip ci]
7.0 Conservative API/Code deprecation removal (#2190)
* WIP: Conservative 7.0 API deprecation removal

* Add new SearchResult for Trash with same design as being added for URL, keep bc for count param (could not found usage of ->query)

* Fix getMock usage

* Remove remaining TranslationInfo/Value and removePolicy() code

@andrerom andrerom merged commit d11e6e1 into master Dec 15, 2017

0 of 4 checks passed

continuous-integration/appveyor/branch Waiting for AppVeyor build to complete
Details
continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Dec 15, 2017

Member

Master is now 7.1! 🌮

Member

andrerom commented Dec 15, 2017

Master is now 7.1! 🌮

@wizhippo

This comment has been minimized.

Show comment
Hide comment
@wizhippo

wizhippo Jan 3, 2018

Contributor

Is there going to be any migration script for this as existing sequences need to be updated to the new naming?
EDIT: also will this cause any issue with legacy?

Contributor

wizhippo commented on 2bda940 Jan 3, 2018

Is there going to be any migration script for this as existing sequences need to be updated to the new naming?
EDIT: also will this cause any issue with legacy?

This comment has been minimized.

Show comment
Hide comment
@alongosz

alongosz Jan 4, 2018

Member

Is there going to be any migration script for this as existing sequences need to be updated to the new naming?

@wizhippo I knew I forgot something... I'll try to make it soon.

also will this cause any issue with legacy?

As for Legacy, it depends if any other code beside eZ\Publish\Core\Persistence\Doctrine\ConnectionHandler\PostgresConnectionHandler generates sequence name. I'm not that familiar with Legacy stack.
// cc @andrerom

Member

alongosz replied Jan 4, 2018

Is there going to be any migration script for this as existing sequences need to be updated to the new naming?

@wizhippo I knew I forgot something... I'll try to make it soon.

also will this cause any issue with legacy?

As for Legacy, it depends if any other code beside eZ\Publish\Core\Persistence\Doctrine\ConnectionHandler\PostgresConnectionHandler generates sequence name. I'm not that familiar with Legacy stack.
// cc @andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Jan 4, 2018

Member

As for Legacy, it depends if any other code beside eZ\Publish\Core\Persistence\Doctrine\ConnectionHandler\PostgresConnectionHandler generates sequence name. I'm not that familiar with Legacy stack.

@wizhippo this was merged early in the life of 7.0 branch before we went ahead and supported legacy bridge to simplify migration for customers. We'll look into what to do here, might be we will then have to revert this and re-introduced in future enhanced storage engine later this year.

Member

andrerom replied Jan 4, 2018

As for Legacy, it depends if any other code beside eZ\Publish\Core\Persistence\Doctrine\ConnectionHandler\PostgresConnectionHandler generates sequence name. I'm not that familiar with Legacy stack.

@wizhippo this was merged early in the life of 7.0 branch before we went ahead and supported legacy bridge to simplify migration for customers. We'll look into what to do here, might be we will then have to revert this and re-introduced in future enhanced storage engine later this year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment