Ask Questions and Find Answers

Hi David, 

Thanks for the feedback.  For context, I have been using/developing/designing on the Liferay Platform since version 5, and have been through many upgrades.  

I agree that content is not a developer activity, but the structures that support the content are a little more of a grey area, IMHO.

We use staging, but we also have a dev/test/UAT environment and want them to all be the same.  Our front-end developer creates fragments and/or ADTs that will use these stuctures.  Not having these created as part of the development process doesn't make sense, as they are a dependency for specific functionality, and having to create them manually in each environment will likely be error-prone, and export-import is very manual, and in my experience has failed with little information as to why from the stack traces.

Regards

100% correct, structures, templates (web content templates, ADTs, widget templates, etc), Object definitions, etc. fall into the grey area where yeah they're code, but still they're not.

For Liferay, anything that is only stored in the database is classified as content, and is therefore subject to the "content creation is not a developer activity" mindset.

For your scenario, I typically recommend doing your work in production and then, from time to time, you copy the prod database and overwrite your test and dev accounts.

Based on a recent conversation with Liferay, I am likely to recommend not using ADT, at all.  In LR 7.4 u45, they have introduced client-extensions, coupled with fragments, Master Pages, and style books, this seems like a more 'future-proof' way to move forward, as these all seem to have methods to deploy as part of CI/CD pipelines

But thank you for responding, it was a useful discussion.

Regards

Style book changes are persisted; while there may be an import/export for those, I doubt that the CI/CD route will be fun.

Fragments can be deployed, but you can also define fragments in the UI; those would not be subject to CI/CD and you may lose the ability to build and test them directly in the UI.

Master pages are still Liferay pages, I'm not sure what you were told about their export/import capabilities, but anything based on a LAR will come with the fragility of the LAR export/import process.

Trust me, my blog about "content creation is not a development activity" is still true and accurate to this day. Liferay has not changed how it treats content or how it will treat content going forward.

And yes, I know how we, as developers, want to control all of these pieces and put them under revision control, etc. I'm totally with you on that. Unfortunately, as long as Liferay stores them in the DB and treats them like content, your safest bet is to adhere to the "content creation is not a development activity" policy and save yourself some future pain and agony...

Sure, but that's not an OOTB capability, it was community-driven and as you've seen it has fallen out of date. If you face a problem using that library, Liferay's not going to help you solve the problems and clean up the data. Since the project was abandoned, its maintenance falls on your shoulders; maybe that's okay with you, but we often have other work we need to do and have little time to maintain someone else's code base.

Just as I point out in my blog, as a developer you have the mindset that everything goes through the promotion process, dev -> test -> uat -> prod. And that's understandable, as a developer I too originally was looking for the same support for promoting content as I did customizations.

Unfortunately, Liferay from a product perspective does not support that (except via the dreadful and fragile LAR export/import process).

Tools like the one you found (and there have been others) have been able to support a kind of content promotion, but these typically solve specific concerns of the author(s) of the packages, not general or complete coverage, plus they fall out of date rather quickly once the author(s) stop working on them.

Ultimately I keep recommending going back to the blog post and recognize Liferay's implementation of a publication process, not a development process, and perform your content creation activities in production, leveraging workflow, staging and/or publications to verify prior to going live.

That's how the product is designed to operate. And while you can find ways to fight the current and paddle upstream, you're going to face a much harder challenge than just going with the flow and doing things the Liferay way...

Hey Eric,

Thanks for the link, I will certainly have a look at this.  Sounds interesting.