Closed matuzalemsteles closed 4 months ago
ethib137
commented
4 months ago Thanks @matuzalemsteles ! This is looking great!
Regarding authentication, I think we should be able to just set a service access policy as Default so that guest access is allowed. Then we won't need to provide any auth.
For images, should we be hosting them statically as well? Does it make sense to do something like this.
matuzalemsteles
commented
4 months ago Regarding authentication, I think we should be able to just set a service access policy as Default so that guest access is allowed. Then we won't need to provide any auth.
Oh good to know, I'll update the code so I don't need this anymore, thanks.
For images, should we be hosting them statically as well? Does it make sense to do something like this.
This will not work well because we need the image to be structured within the Gatsby data, otherwise it will not work, for example if we were searching for the image via graphql, in our case the images are all within the html string.
matuzalemsteles
commented
4 months ago This is ready now, send the commits cleaning up some of the code and mistakes. I also cleaned up the html that the API returns to obtain only the content, it also fix the case for images.
matuzalemsteles
commented
4 months ago One separate minor thing... When I tried this locally I got errors at first when I was on node/18.18.2. Downgrading to Node 16 fixed it. It might be good to look into fixing that or indicate that we need to use an early version of node.
Oh yes, there are a lot of things in the repository that only work with Node 16, mainly Gatsby things and dependencies, I think we can create a task for that.
I also tested directly against our LXC instance and it works there as well.
Can you then send me the LXC link and the Site ID so I can add this to the Netlify env?
Ticket LPD-4623
Well, this PR implements the option of consuming documents or pages that can come from an instance of Liferay DXP, this adds a new tab to the existing local document, this generates it with each new build made, so if a change is made in DXP it is necessary to rebuild.
The implementation is a little simple, I added a new gatsby plugin that searches all pages and adds it as a new node the gatsby data structure so in the stage of creating the pages we search for all Liferay documents and match them with the existing page this avoids having to fetch all existing pages locally and check if they exist in Liferay this would cause a huge slowdown in the build.
The page's match with the local document is done via friendly url, so the two documents must be the same to create the match.
As we had some conversations, we are using a very old version of Gatsby and it also seems that after the acquisition of Gatsby by Netlify they are not investing as much as before in evolving the project, which increases my desire to migrate to Next.js a little more. this would be a little simpler due to the nature of the Next.js architecture with the file-based routing system and other features that we could use, Iike ISR that the pages could be recreated as soon as a new document is published and still keep everything static with the cache on the CDN.
Well basically we have some small limitations with just rendering the html content, images that are being hosted on Liferay we cannot show in the documentation because there is no absolute path in the image url, maybe this is a bug in the API?! but I believe we could try to fix this on our side using a little regex, we also need to clean up the rendered html a little because it brings the entire body of the page and we only need to get the body of the document, it still looks like an empty form is coming, is a little strange but I think we managed to remove that too. In general this works well but I think we can test more with more complex pages as we add new pages.
I tried using OAuth authentication but the authentication flow doesn't make sense for this case because we would need to build the OAuth authentication flow just to get a token to get the data, the ideal would actually be if Liferay had Token API management but I didn't find it so I just went with Basic Auth, I don't think this is a big security risk because all the data that will be available in the instance will only be public documents and we can also create a user account with restrictions for reading only if it is the In any case, the authentication data will not be visible on the client side, only in the build when running on Netlify.
ToDo