Skip to content
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

SuluArticleBundle 3.0 Roadmap #545

Open
alexander-schranz opened this issue Jan 26, 2021 · 3 comments
Open

SuluArticleBundle 3.0 Roadmap #545

alexander-schranz opened this issue Jan 26, 2021 · 3 comments
Labels
Feature New functionality not yet included

Comments

@alexander-schranz
Copy link
Member

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.

@alexander-schranz alexander-schranz added Feature New functionality not yet included help wanted and removed help wanted labels Jan 26, 2021
@plozmun
Copy link
Contributor

plozmun commented Mar 8, 2021

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
Copy link

ljfreelancer88 commented Jun 24, 2021

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
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New functionality not yet included
Projects
None yet
Development

No branches or pull requests

3 participants