Symfony 4
"friendsofsymfony/ckeditor-bundle": "^1.1"

It seems that this issue egeloen/IvoryCKEditorBundle#305 is back / present on this version of the bundle.

do not forget to add 3 maintainers there and enable auto update.

My suggestion is that we create 1.x from master and continue our work there. So 1.x would be stable and master unstable. We merge 1.x into master and from master we release next majors.

Here we always check instanceof JsonBuilder::class

This should be fixed.

No clue if that is possible at all, but we should try to reach a notice through packagist, that the old package is abandoned maybe force a kind of a redirect.

maybe @naderman has an idea?

At the end we wanna move each "user" of
https://packagist.org/packages/egeloen/ckeditor-bundle
into:
https://packagist.org/packages/friendsofsymfony/ckeditor-bundle

Hello.
The settings are according to the documentation (http://prntscr.com/jt2f0f), but there is still a bug. The cache was cleaned.
Thank you.

The command is defined as a service (which is needed to support Symfony 4). But it is currently not lazy-loaded, because the name is not accessible at compile time.

there is 2 ways to fix this:

• provide the command name in the tag registering the command (thanks to the alias attribute)
• set the name in a static property (check the Symfony 3.4+ codebase to find the name of this property in the Command class, I don't remember it right now)

ToDo:

• symfony blog
• own blogs
• Twitter
• Symfony Slack
• ???

The renderTemplate implementation depends on symfony/templating, but this package is not available by default in Flex projects

Symfony packages

symfony/monolog-bundle     v3.2.0  v3.2.0 Symfony MonologBundle
symfony/phpunit-bridge     v2.8.39 v4.0.8 Symfony PHPUnit Bridge
symfony/polyfill-apcu      v1.7.0  v1.7.0 Symfony polyfill backporting apcu_* functions to lower PHP versions
symfony/polyfill-intl-icu  v1.7.0  v1.7.0 Symfony polyfill for intl's ICU-related data and classes
symfony/polyfill-mbstring  v1.7.0  v1.7.0 Symfony polyfill for the Mbstring extension
symfony/polyfill-php54     v1.7.0  v1.7.0 Symfony polyfill backporting some PHP 5.4+ features to lower PHP versions
symfony/polyfill-php55     v1.7.0  v1.7.0 Symfony polyfill backporting some PHP 5.5+ features to lower PHP versions
symfony/polyfill-php56     v1.7.0  v1.7.0 Symfony polyfill backporting some PHP 5.6+ features to lower PHP versions
symfony/polyfill-php70     v1.7.0  v1.7.0 Symfony polyfill backporting some PHP 7.0+ features to lower PHP versions
symfony/polyfill-util      v1.7.0  v1.7.0 Symfony utilities for portability of PHP codes
symfony/security-acl       v3.0.1  v3.0.1 Symfony Security Component - ACL (Access Control List)
symfony/swiftmailer-bundle v2.6.7  v3.2.2 Symfony SwiftmailerBundle
symfony/symfony            v2.8.39 v3.4.8 The Symfony PHP framework

Subject

Clean install on sf2.8 project without any kind of configuration, added form type to form type and I get an error.

Steps to reproduce

Install bundle and add form type to any form

Expected results

working page with ckeditor

Actual results

ServiceCircularReferenceException in Container.php line 264:
Circular reference detected for service "templating", path: "fos_rest.versioning.listener -> fos\restbundle\view\viewhandlerinterface -> templating -> twig -> fos_ck_editor.twig_extension -> fos_ck_editor.renderer".

I suggest we add @group to tests that run install and download stuff, for me at least, build takes so much time locally and I do not want to wait that long to confirm if I broke stuff.

Adding @group installation to:

https://github.com/FriendsOfSymfony/FOSCKEditorBundle/blob/master/Command/CKEditorInstallerCommand.php
and
https://github.com/FriendsOfSymfony/FOSCKEditorBundle/blob/master/Installer/CKEditorInstaller.php

would allow us to run tests with phpunit --exclude-group installation and build is done in 15 seconds, and then we leave travis to confirm if installation works.

Currently, there are some PHP template and twig templates, should we consider dropping PHP ones and sticking to twig only?

hints in anouncments:

• Blog Post in Symfony Blog
• @ElectricMaxxx write an own post on company blog also

more:

• Readme section
• migration page in docs
• hints on several other places in the docs with links to migration page

The CI and Docker environments currently support HHVM. But Symfony dropped HHVM support after they announced that they would not care about PHP compat anymore.
We should not care about testing HHVM compat for this bundle.

Currently, all the model services (except the ToolbarManager) are stateful mutable objects, which are cloned in the form type before being mutated. This makes them unsuited for being registered as services (the way they are used does not correspond to services).

These services should become builder objects instantiated at the right time in the form type (a factory service might be provided in case this needs to be an extension point)

when grepping through the repo, there severy ivory usages, we should remove them. At least:

• licence headers
• Readme
• docs
• CI tooling

Wouldn't this only complain about lock file being outdated?

Everything that shouldn't be overridden should be final.

In chat @kunicmarko20 an i had a discussion what to include into a v1.0. What do you think?
From my POV, i would see a goal having a release as fast as possible, which means:

• fixes to get bundle working and consistent
• SF4 comaptibility
  Doing so we would have a smal step only for migration from former repo to this one. I know that we have several ideas and stuff which needs to be fixed – even with BC-breaks. But lets get it out and work on a new major afterwards, what do you think?

At least we should have something stable to get the other bundles/packages like CMF, Sonata, into the road of releasing their SF4 compatible versions.

This would be a good addition at one point.

My IDE (PHPStorm reminds me to add

symfony/http-foundation
symfony/routing

to the list of required packages as they are not required directly. they come through framework-bundle. Is that an a real issue or not?

At least the align_double_arrow setting should be disabled, to match the Symfony coding standards

Here we trigger the error: FOSCKEditor 6.1, and will be removed in 7.0

It should be 1.0 and 2.0

Lets discuss and possibly implement.

should be fos_ckeditor

currently, the min requirements of the bundle are Symfony 2.7 (and even 2.0 for some components, but I doubt it works due to other requirements) and 5.6 for PHP.

We should at least review these to decide what we do in our new major version

Stuff like:

Should be replaced with Twig Namespaces.

We should implement a linter and a build test for docs. Escpecially when i start edititng the rst stuff, there are plenty options to break the docs.

The composer.json should be cleaned before 1.0:

• removing useless suggestion. For instance, suggesting to install Twig to use Twig templates is useless. If they want to use Twig templates, they already have Twig installed (and so don't see the suggestion). If they don't want, they don't care about the suggestion. Suggestions should be about extra packages enhancing the features of the bundle.
• updating authors to link to github contributors, like in other FOS bundles
• remove conflict with egeloen/ckeditor-bundle once we don't conflict anymore (i.e. once we have our own namespace)

@javiereguiluz you would be the one, who could do that for us, right?

Hello,
after define the proxy configuration, and run the installer command, symfony can't download the file.

Only worked with these changes in the installation command.

if ($proxy) { $context['http']['proxy'] = $proxy; $context['http']['request_fulluri'] = true; }

can i submit a pull request ?

These files should start empty, as we start over the release history.

and the docs should have a page dedicated to migrating from the Ivory bundle.

We are missing json-builder docs in that index.

Change badges, mention we took over from @egeloen, etc etc.

As we already have a CLI command to install CKEditor, we should tell people to use it in their composer scripts instead of using a CKEditorScriptHandler launching the command itself.

this would remove the optional dependency on the old sensio/distribution-bundle

https://flintci.io/

This bundle (at least for the FormType) is using the same method for the accessor and the mutator, based on whether a non-null value is provided.
Such kind of API is quite uncommon in the Symfony ecosystem (and harder to typehint)

Instead of configuring services through setters, which makes them mutable at runtime, they should be configured through the constructor, with no setter.

Move code to src.

Environment

• Travis build
• php 5.6 and php 7.0 with lowest dependencies

Subject

Steps to reproduce

• https://travis-ci.org/FriendsOfSymfony/FOSCKEditorBundle/builds/372274468?utm_source=email&utm_medium=notification

Expected results

• green build

Actual results

I think we should introduce the AbstractExtension with a condition or increase min twig version.

I checked packagist and this is a list of active libraries in the past 1-2 months that depend on IvoryCKEditorBundle:

• https://github.com/Cocolabs-SAS/cocorico
• DarvinAdminBundle
• resource-repository-bundle
• admin-translatable-bundle
• AdminCrudBundle
• init-cms-bundle
• https://github.com/shopsys/project-base
• https://github.com/shopsys/framework
• https://github.com/symfony-cmf/cmf-sandbox
• https://github.com/symfony-cmf/sonata-phpcr-admin-integration-bundle
• https://github.com/Victoire/WidgetFormBundle

My suggestion is to create PRs on that repos and help them move to FOSCKEditorBundle, like I did for SonataFormatterBundle.

This will help us spread the word about moving of the bundle.

We want to evaluate the newer CKEditor 5. So we want to know how much work it would be and if we can use the current codebase to do so. Lets evaluate and writte down some data from CKEditor 5 docs or by installing and experimenting with an example. We should document it, here in the issue or in wiki section of the package.

OLD:

/*
 * This file is part of the Ivory CKEditor package.
 *
 * (c) Eric GELOEN <[email protected]>
 *
 * For the full copyright and license information, please read the LICENSE
 * file that was distributed with this source code.
 */

NEW:

/*
 * This file is part of the FOSCKEditor Bundle.
 *
 * (c) 2018 - 2018 Friends of Symfony
 * (c) 2009 - 2017 Eric GELOEN <[email protected]>
 *
 * For the full copyright and license information, please read the LICENSE
 * file that was distributed with this source code.
 */

All deprecated layers of IvoryCKEditorBundle should be dropped when making the 1.0 release of the new bundle, as we are not backward compatible anyway (class name changes for instance).

the migration path would be to upgrade to latest Ivory version, fix deprecations, and then migrate to the FOS bundle.