New! Checkout our new Forums homepage! Follow the latest activity in eZ Publish Forums on Share.ez.no, Projects.ez.no and StackOverflow.com


@ezecosystem
ezecosystem pushed to master in ezecosystem/repository-forms Sep 21, 2018
1 commit to master
  • @ViniTou 23bb2ff
    EZP-29269: User draft is not discarded on edition cancel (#240)
09/21/2018 12:08 pm   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/NetgenEzFormsBundle Sep 21, 2018
1 commit to master
  • @MarioBlazek 26f6131
    Increase memory limit on TravisCI
09/21/2018 12:06 pm   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezstudio Sep 21, 2018
2 commits to master
09/21/2018 12:03 pm   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezplatform-xmltext-fieldtype Sep 21, 2018
2 commits to master
  • @vidarl 129e65b
    EZP-29601: As a editor I want to be able to insert html code in a ric…
  • @vidarl dbae354
    EZP-29595: ezxmltext -> richtext conversion : <header> inside <paragr…
09/21/2018 12:01 pm   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezplatform-com Sep 21, 2018
1 commit to master
  • @SylvainGuittard ab33ef3
    COM-20058: Add product feedback portal (#140)
09/21/2018 12:00 pm   eZecosystem @ GitHub   Mirror   Link  

Contributed by
Jérémy Derussé
in #27456.

The Lock component was introduced in Symfony 3.4 to create and manage locks, a mechanism to provide exclusive access to a shared resource. Out of the box it supports different storages for local locks (files, semaphores) and distributed locks (Memcache, Redis). In Symfony 4.2 we've added a new PDO-based lock storage.

This makes sense because most Symfony applications already use MySQL/MariaDB or PostgreSQL for data persistence. However, this new storage doesn't rely on the built-in locking mechanisms of those databases (pg_advisory_lock_shared for PostgreSQL and GET_LOCK for MySQL/MariaDB) because they are not reliable enough. They depend on the TCP connection and require to fine-tune the database engine in order to not accept new connections after a reboot or to define a connection timeout greater than the maximum lock duration.

The new PdoStore class requires a PDO object, a Doctrine DBAL Connection object or a DSN (Data Source Name) string to configure the storage:

1
2
3
4
5
6
7
8
use Symfony\Component\Lock\Store\PdoStore;

// a PDO, a Doctrine DBAL connection or DSN for lazy connecting through PDO
$databaseConnectionOrDSN = 'mysql:host=127.0.0.1;dbname=lock';
$store = new PdoStore($databaseConnectionOrDSN, [
    'db_username' => 'myuser',
    'db_password' => 'mypassword'
]);

Then, create the table that stores the lock information. You can use the createTable() method of the PdoStore class to do that:

1
2
3
4
5
try {
    $store->createTable();
} catch (\PDOException $exception) {
    // the table could not be created for some reason
}

Now you can create and manage the PDO-based locks as explained in the docs for any other lock type.


Be trained by Symfony experts - 2018-09-24 Clichy - 2018-09-24 Clichy - 2018-09-26 Clichy
09/21/2018 04:04 am   Symfony Blog   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/repository-forms Sep 21, 2018
2 commits to master
  • f419d85
    README update (#253)
  • @adamwojs 9708389
    EZP-29508: As an editor I want to manage ALT field with an image asse…
09/21/2018 12:06 am   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/PlatformUIBundle Sep 21, 2018
2 commits to master
  • @andrerom 774b853
    Merge branch '1.13'
  • @konradoboza 62b681c
    EZP-29234: As a developer, I want to read about customizing REST API …
09/21/2018 12:06 am   eZecosystem @ GitHub   Mirror   Link  

In a previous blog post we covered how to create custom tags in eZ Platform (with the legacy bridge or eZ Publish 5.x). The most difficult part of that process was building the XSL to output the custom tag HTML. But there's a simpler way to do it, which allows the developer to use Twig template code instead of XSL.

 

09/20/2018 04:36 pm   Mugo Web Blog   Mirror   Link  

In a previous blog post we covered how to create custom tags in eZ Platform (with the legacy bridge or eZ Publish 5.x). The most difficult part of that process was building the XSL to output the custom tag HTML. But there's a simpler way to do it, which allows the developer to use Twig template code instead of XSL.

09/20/2018 12:41 pm   share.ez.no/blogs   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/repository-forms Sep 20, 2018
2 commits to master
  • f419d85
    README update (#253)
  • @adamwojs 9708389
    EZP-29508: As an editor I want to manage ALT field with an image asse…
09/20/2018 12:41 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/PlatformUIBundle Sep 20, 2018
2 commits to master
  • @andrerom 774b853
    Merge branch '1.13'
  • @konradoboza 62b681c
    EZP-29234: As a developer, I want to read about customizing REST API …
09/20/2018 12:39 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/EzSystemsRecommendationBundle Sep 20, 2018
2 commits to master
09/20/2018 12:24 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-spi Sep 20, 2018
2 commits to master
  • @brookinsconsulting 2727cb7
    Merge remote-tracking branch 'upstream/master'
  • @adamwojs ee03aa1
    EZP-29508: As an editor I want to manage ALT field with an image ass…
09/20/2018 12:20 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-kernel Sep 20, 2018
2 commits to master
09/20/2018 12:19 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezflow Sep 20, 2018
1 commit to master
  • @chs2 86fa840
    Removed include_once() to avoid "Cannot redeclare class" (#76)
09/20/2018 12:13 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/EzSystemsRecommendationBundle Sep 20, 2018
2 commits to master
09/20/2018 12:03 pm   eZecosystem @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezpublish-spi Sep 20, 2018
1 commit to master
  • @adamwojs ee03aa1
    EZP-29508: As an editor I want to manage ALT field with an image ass…
09/20/2018 12:01 pm   eZecosystem @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/Cache Sep 20, 2018
2 commits to master
  • @derickr fbd76c9
    Merge pull request #3 from pbek/php72-deprecation-fixes
  • @pbek ef17cde
    PHP 7.2 deprecation fixes
09/20/2018 12:01 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezpublish-kernel Sep 20, 2018
2 commits to master
09/20/2018 12:01 pm   eZecosystem @ GitHub   Mirror   Link  

What problems are we trying to solve?

Our previous Form Builder was a part of the landing page manager from 1.7 LTS to v2. When we introduced our Page Builder with v2.2 to replace the landing page manager, we on-purposely decoupled the Form Builder from it and did not redevelop it. Now is the time to bring back this feature as a standalone part of our product, while improving the limitations the previous version possessed.

The first limitation was that editors did not have the ability to reuse forms from different locations. Each time editors needed to create a new form for different pages, which can be very annoying and time-consuming. This was due to forms being thought of as blocks within pages, without the ability to reuse them across different pages.

Re-using forms was identified as an important need for editors. Hence, we decided to build a user interface dedicated to that purpose. Users now have a full-screen mode, which will make it easier for them to edit compared to when they needed to edit a form as a block within a page in the Page Builder.

Besides updating these limitations, we also wanted to allow editors to manage translations, versions, and submissions. We will dive into these new capabilities later in the blog post. But until then let’s better understand better the benefits that the Form Builder manager will provide to marketers, editors, and developers.

Developers will be pleased to discover that with the new form builder they will be able to easily customize and extend form fields. More importantly, they should be delighted to discover that we decided to re-use the content repository and build forms on top of it, as a field type. This way, they can easily create different form content types with different fields and then save/publish them at different places within the repository (even if we provide a default location, such as the Media library for media, they have full freedom on their repository organization).

Moving forward marketers and editors will have a much more intuitive and simpler interface to create forms. Since forms are decoupled from the page, users can now create forms ahead of time and reuse and embed them in different locations. They can quickly create a form by dragging and dropping different fields resulting in collecting information within seconds.

Form Block

Creating a Form

Form Builder Interface

Drag and Drop Form Fields

Now let’s dive in and discover more about the different capabilities of the Form Builder manager block:

Versioning forms

Since forms are now attached to a content type and managed as content items in the repository, users will be able to restore a previous version of a form or preview a draft before publishing the form.

Translating forms

Another great benefit of using content types for forms is that editors can now translate their forms into different languages when working on a multilingual site. They will also be able to manage form submissions by language.

Using content relations and other perks from the content repository

Now that forms are content items, editors can create relations between forms and other content items in the repository. It can help see how and where forms are used. This simplifies the process of embedding forms within the online editor. Editors can benefit from all the other perks coming along with the content repository, such as placing a form at multiple locations, using the flex workflow to get approval before publishing a form or publishing a form in the future.

Managing form submissions

Managing form submissions can be messy and quite tricky sometimes. We decided to simplify this by keeping form submissions separate from the content repository. The information collected will be stored in a separate database. We believe this will be extremely beneficial as you will be able to access and download this data anytime. Storing form submissions outside the content repository will also allow companies to easily manage the collected data. We will also include a submissions tab on the administrative interface, so users can easily view such form submissions. This can also be handy when trying to be GDPR compliant. For example, in the future, we plan to create buttons that will allow editors to search and delete collected data.

Stored Submissions

Form Submission

What to expect in the future

We are very excited for the upcoming release. We believe that the Form Builder and other features will significantly improve the editorial experience. The Form Builder block will also be a great addition to the page builder which was introduced in v2.2. It is important to remember that this is only the first iteration of this new Form Builder. In the future we have more updates in the plan, such as, “developing more out-of-the-box GDPR capabilities, providing webhook and potential connectors to integrate the form submissions with 3rd party systems, providing extension and customization capabilities to let users customize the Form Builder to build advanced features such as polls, surveys or others, and to include more fields. If you have any need, opinion or idea, of what would be helpful for you in the future, please drop us a note.

Next week we will provide a sneak peek to the image asset field type that is also expected to be shipped with v2.3. Until then, if you’re interested or have any questions, please feel free to leave a comment here or on discuss.ezplatform.com. Feel free to reach out to us, too, at productmanagement@ez.no.

09/20/2018 10:05 am   ez.no/About-eZ/Blog   Mirror   Link  

What problems are we trying to solve?

Our previous Form Builder was a part of the landing page manager from 1.7 LTS to v2. When we introduced our Page Builder with v2.2 to replace the landing page manager, we on-purposely decoupled the Form Builder from it and did not redevelop it. Now is the time to bring back this feature as a standalone part of our product, while improving some of its weaknesses the previous version possessed.

The first limitation was that editors did not have the ability to reuse forms at different places. Each time editors needed to create a new form for different pages, which can be very annoying and time-consuming. This was due to forms being thought of as blocks within pages, without the ability to reuse them across different pages.

Re-using forms was identified as an important need for editors. Hence, we decided to build a user interface dedicated to that purpose. Users now have a full-screen mode, which will make it easier for them to edit compared to when they needed to edit a form as a block within a page in the Page Builder.

Besides removing this limitation, we also wanted to allow editors to manage translations, versions, and submissions. We will dive into these new capabilities later in the blog post. But until then let’s better understand better the benefits that the Form Builder manager will provide to marketers, editors, and developers.

Developers will be pleased to discover that with the new form builder they will be able to easily customize and extend form fields. More importantly, they should be delighted to discover that we decided to re-use the content repository and build forms on top of it, as a field type. This way, they can easily create different form content types with different fields and then save/publish them at different places within the repository (even if we provide a default location, such as the Media library for media, they have full freedom on their repository organization).

Moving forward marketers and editors will have a much more intuitive and simpler interface to create forms. Since forms are decoupled from the page, users can now create forms ahead of time and reuse and embed them in different locations. They can quickly create a form by dragging and dropping different fields resulting in collecting information within seconds.

Creating a Form

Form Builder Interface

Drag and Drop Form Fields

Now let’s dive in and discover more about the different capabilities of the Form Builder manager block:

Versioning forms

Since forms are now attached to a content type and managed as content items in the repository, users will be able to restore a previous version of a form or preview a draft before publishing the form.

Translating forms

Another great benefit of using content types for forms is that editors can now translate their forms into different languages when working on a multilingual site. They will also be able to manage form submissions by language.

Using content relations and other perks from the content repository

Now that forms are content items, editors can create relations between forms and other content items in the repository. It can help see how and where forms are used. This simplifies the process of embedding forms within the online editor. Editors can benefit from all the other perks coming along with the content repository, such as placing a form at multiple locations, using the flex workflow to get approval before publishing a form or publishing a form in the future.

Managing form submissions

We keep form submissions separate from the content repository. The data collected is stored in a separate database table. Submissions data is available to the editor or site administrator from the user interface, on the "submissions" tab, to let him view or download this data. The interface is simple and fast, and makes it handy when working with a lot of forms. In the future, we plan to create more capabilities that will allow editors to search and delete collected data, to improve further the way to support GDPR.

Stored Submissions

Form Submission

What to expect in the future

We are very excited for the upcoming release. We believe that the Form Builder and other features will significantly improve the editorial experience. The Form Builder block will also be a great addition to the page builder which was introduced in v2.2. It is important to remember that this is only the first iteration of this new feature, there are still many things we could improve and new capabilities we could add. In the future we have more updates in the plan, such as, “developing more out-of-the-box GDPR capabilities, providing webhook and potential connectors to integrate the form submissions with 3rd party systems, providing extension and customization capabilities to let users customize the Form Builder to build advanced features such as polls, surveys or others, and to include more fields. If you have any need, opinion or idea, of what would be helpful for you in the future, please drop us a note.

Next week we will provide a sneak peek at the image asset field type that is also expected to be shipped with v2.3. Until then, if you’re interested or have any questions, please feel free to leave a comment here or on discuss.ezplatform.com. Feel free to reach out to us, too, at productmanagement@ez.no.

09/20/2018 10:05 am   eZ Systems News   Mirror   Link  

Et un peu hors-sujet :

(En plus du flux RSS global, les billets veille et uniquement ceux là sont listés dans le flux RSS correspondant)

09/20/2018 07:07 am   pwet.fr/blog   Mirror   Link  

Contributed by
Nicolas Grekas
in #28234.

In modern Symfony applications, thanks to service autowiring and service autoconfiguration, there's no need to configure most (or any) of your services. However, in some edge-cases you may need to tell Symfony which exact service should be injected into other services.

This is solved with local binding which allows to bind services by type or name. For example, if you use YAML to configure services:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# config/services.yaml
services:
    _defaults:
        bind:
            # pass this value to any $adminEmail argument for any service
            # that's defined in this file (including controller arguments)
            $adminEmail: 'manager@example.com'

            # pass this service for any LoggerInterface type-hint for any
            # service that's defined in this file
            Psr\Log\LoggerInterface: '@monolog.logger.request'

In Symfony 4.2 we've improved this feature to allow binding services by type and name at the same time. This new feature allows a more precise binding because it only applies when both the argument type and the argument name match.

1
2
3
4
5
6
7
8
9
# config/services.yaml
services:
    _defaults:
        bind:
            # it works with scalar types too (string, int, array, etc.)
            string $adminEmail: 'manager@example.com'

            # but it's mostly used with classes
            Psr\Log\LoggerInterface $requestLogger: '@monolog.logger.request'

Be trained by Symfony experts - 2018-09-24 Clichy - 2018-09-24 Clichy - 2018-09-26 Clichy
09/20/2018 03:30 am   Symfony Blog   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezstudio Sep 19, 2018
1 commit to master
  • @adamwojs 8054987
    EZEE-2284: As an editor I want to see a preview of a Captcha form fie…
09/19/2018 12:22 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-kernel Sep 19, 2018
2 commits to master
09/19/2018 12:19 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezflow Sep 19, 2018
1 commit to master
  • @peterkeung 70a8964
    Fix EZP-29600: eZ Flow pool table not updated on node swap (#81)
09/19/2018 12:13 pm   eZPublishLegacy @ GitHub   Mirror   Link  
@ezecosystem
ezecosystem pushed to master in ezecosystem/ezstudio Sep 19, 2018
1 commit to master
  • @adamwojs 8054987
    EZEE-2284: As an editor I want to see a preview of a Captcha form fie…
09/19/2018 12:02 pm   eZecosystem @ GitHub   Mirror   Link