Publish Objects per Locale

[passioneight]

Description

Publishing objects on a per-locale basis is something I need in many projects. Mostly because the client wants a single data object (e.g. product) and decide whether it is available for a specific locale or not. So, I figured, maybe I'm not the only one and this functionality could be a feature for Pimcore. Or maybe I am the only one and noone else needs this - in this case, maybe you can provide some details about your approach?

Let's have an example for clarification.

Note that I usually need this feature for various classes, not just products.

Example

Assume a Product class exists and the product index is setup as multi-tenant - with each tenant representing a locale (e.g., en, de). Now, assume that the corresponding assortment tenants were implemented too - one per supported locale (e.g., AssortmentTenantEn, AssortmentTenantDe).

To exclude products from indexing, one would implement either inIndex or getOSDoIndexProduct. So, in this case, I'd implement the assortment tenant, since we have one per locale (see above), which makes it possible to check the object against a specific locale (e.g., $inIndex = in_array($tenantLocale, $object->getAvailableLocales());).

Now, the product will no longer be indexed - which is what we wanted. However, we are not quite done just yet. Imagine the product was already indexed and the client decided to un-publish it for a specific locale only.

In this case, we also need to ensure that the prev. available URL is not available in the sitemap anymore. This means we need to create the sitemap based on our index, which will need some effort too (instead of just using Pimcore's PublishedFilter (which could handle the locale specific use case if this feature was added to Pimcore).

Let's assume we implemented the sitemap generation correctly, we still may have users who bookmarked the prev. available URL - or they access the URL some other way (e.g., manually or via browser history). In this case, we'd need to implement some more logic and throw a NotFoundHttpException.

Now, we've implemented everything as needed by the most basic implementation.

A more sophisticated solution also contains an exception listener to redirect to a products overview page, for example. Another aspect to improve is the performance, as all products are loaded with the described implementation, instead of adding an additional condition to the listing.

As you can see, this is quite the workload for something that - to me - should be a feature provided by Pimcore. Especially, since this feature may be needed for other use cases as well (e.g. blog).

Further thoughts

The most challenging parts probably are:

• Identifying all uses of the published-state within Pimcore, so that the feature can be supported consistently (wherever it makes sense).
• Providing a proper user interface that makes it easy to select available system locales when publishing.
• Displaying the current published state (e.g. in the object tree).
• Saving the published state per locale in an efficient way.
• ... (probably some more I cannot think of at the moment)

I'm really looking forward to the thoughts of you guys (both Pimcore & the community).

[passioneight]

@dvesh3 any feedback would be much appreciated.

[dvesh3]

Sorry, a bit occupied with Release tasks. will definitely take a look later on 😉

[passioneight]

@dvesh3 did you have any chance to have a look at this already?

[dpfaffenbauer]

I think that is nothing Pimcore should handle and is application specific. What if you have more requirements than per language? should pimcore solve that then too....

[passioneight]

@dpfaffenbauer thanks for the feedback!

While I too think Pimcore shouldn't add features that are only application specific (i.e., needed for 1 or maybe 2 projects), I feel like publishing objects per locale is not really application specific, considering that I need this in every project (and it seems it's not just me who needs this, based on the votes).

Also, since Pimcore provides the locales, it should add features related to them - or do you disagree? Specifically considering your argument, from your point of view: in what way is adding this feature different from adding features like "Paste as new language variant" for documents, for example?

[dpfaffenbauer]

I usually always have multi-site Projects now, where one objects is published to one or more site in different languages.

so basically:

 - site1
   - de/product-1
   - en/product-1
   - fr/product-1
 - site2
   - de/product-1
 - site3
   - en/product-1
   - es/product-1

Your feature suggestion would limit me or even make it harder to fulfill these use-cases since Pimcore would automatically publish for language "de/product-1" even though it is not needed on site3.

[passioneight]

I think there might be a bit of a misunderstanding as to what the suggested feature should do. Let me quickly recap everything, so we can rule that out:

The save & publish button should, for example, have a drop down to be able to save objects for a specific language. Regardless of the UI, one can imagine the feature as a checkbox in a localized field, which holds the published state.

Everything else in the description was intended to help explain why this would be useful only.

So, ultimately, there shouldn't be any restriction for your setup at all, because you still need to implement the logic for generating and displaying your index. That is, even if you share your products between sites, you should have a separate tenant for each of your sites and locales anyway - unless they are exactly the same.

---

If, however, you did understand exactly that the first time around, maybe you can clarify a bit more, because in this case I don't seem to understand your argument.

[fashxp]

I wouldn't go that road because it adds huge complexity to Pimcore. Especially when thinking about further consequences like content f the query tables and querying, visualization in UI, fallback languages, creating new unpublished versions (per locale?), data inheritance, etc.

Also, as outlined by @dpfaffenbauer, locale does not always equal to tenant. There are many other structures like specific tenants have multi-language content. These structures you cannot be handled with a published state per locale.

So, I would use flexibility of the data model and suggest to use custom data attributes/state flags (whatever fits the use case) for that kind for requirement.

[passioneight]

@fashxp thanks, I'm always happy to see the core team find some time for a discussion like this! Here's my 2 cents:

It really depends on how you implement this. Using the following approach we can resolve most of your (very valid) concerns:

1. Add a checkbox in the class definition to enable the feature for a specific object
2. Add a hidden localized field containing a checkbox to handle the published state
3. Extend the save & publish dropdown to publish only for a specific language

With this, the UI is probably the hardest part if we want to achieve proper UX. Querying the data - in this case - should really not be too hard nor should it have any negative performance impacts, though, it will require some work.

With this approach, it does not matter which tenants you have, because as a developer, you are still responsible for building the index. All other concerns you mentioned should be resolved too:

• inheritance is handled like it usually is when using a checkbox
• fallback language logic can be kept as is too as the current behaviour is the expected one anyway
• versions only include the change of the checkbox, thus, they do not need to be localized
• even UrlSlugs could be handled this way (i.e., triggering a 404 if the object is unpublished).

Obviously, the decision is yours to make, but I still don't see too much trouble with this. Maybe you have a specific example (i.e. pseudo-code) in mind you can share?

[dpfaffenbauer]

why not make a plugin that does exactly that?

[passioneight]

Because I feel like this should be part of the core :-)

[twin-elements]

Have you found a solution to the problem?

At the moment, the situation in Pimcore looks like this:

• Documents have a language version and for different language versions we can create different document trees.

• We can no longer create language versions for objects, only translations for localized fields. And this has been a serious problem for me for a long time as well.
  For example, blog entries are often written only for a specific language version and either the base language version or null is displayed in uncompleted versions. This behavior is unacceptable.

Previously, I used KnpDoctrineBehaviors translatable and in this package we have a separate table for the base entity and a separate table for localized data. But we have the ability to create objects for individual language versions.

[passioneight]

Hi @twin-elements ,

yes, we created our own bundle as we need this in pretty much every project. Unfortunately, I'm not allowed to disclose any information on the implementation.

[twin-elements]

I see. Thanks for the info