SuluArticleBundle 3.0 Roadmap

[alexander-schranz]

This issue is here to discuss where we should go with the SuluArticleBundle and also get some feedback from the community where the problems are. I will begin which things are currently in my mind:

1. Elasticsearch Dependency

I think the most feedback we did currently get from the community is the "elasticsearch" dependency. Which need to be installed on a server. SuluArticleBundle 3.0 definitely target to get rid of it or making it optional view layer. Currently we plan to push the SuluContentBundle and us it as basic for the SuluArticleBundle 3.0.

2. PHPCR Dependency

Most are not common with phpcr and is hard to debug for themhow the data is stored or query on them, the switch to use the SuluContentBundle will also here get rid of ths PHPCR layer. For this we also need to push the SuluContentBundle to support things like Versioning, Multi or Single Webspace configurations.

3. Fixing Open Issues with Types

Currently we have open issues with types for example we can not make any Deep Links into articles. Maybe not a 3.0 but 2.x topic but definitely should be fixed in 3.0.

4. Getting more Feedback

What are the current usages of the article bundle, is a optional elasticsearch view layer a thing which we should provide? Maybe over a configuration. Maybe the ContentBundle could provide additional view layer here.

[plozmun]

Hi!

I think an improvement that would help a lot of developers would be a ContentSearchAPI to do custom searches on documents. Something like:

$query = new Query\Query();
$template = new Query\Criteria\Template('page');
$excerptTitle = new Query\Criteria\Extension\Text('excerpt', 'title', 'value');
$excerptDate = new Query\Criteria\Extension\Date('excerpt', 'event_date', new \DateTime(), Query\Criteria\Extension\Date::GTE);

$and = new Query\Criteria\And([$template, $excerptTitle, excerptDate]);

$query->setQuery($and);

It's not something related to ArticleBundle but it could be used here too
Ideally it could be used with both Elasticsearch and PHPCR.

WDYT?

[ljfreelancer88]

My client uses shared hosting and there's no way to use elastic search. Making the elastic search optional is highly appreciated and to lesson the configuration also.

[alexander-schranz]

@plozmun I personally see no advantage of creating here an own Query Language for Content. The Article Content will be a normal Doctrine Entity (no PHPCR) and the unstructered data is stored as JSON, the ArticleRepository and Article Entity will be extendable. So it is possible to write specific fields into an own column if you want that or even you could just filter content by using the mysqls and postgresqls JSON Selector queries. An own Query Language would in my case just be just something which would need to be maintained and I think its better that directly DQL query builder is used and so all features of relational database can be used.