I have some static variables used the XSL which are currently stored in sitemap.xml as global variables.
<map:pipelines>
<map:component-configurations>
<global-variables>
...
</global-variables>
</map:component-configurations>
...
This is all well and good but, some of the variables are deployment specific so need to be changed when the web app starts up. Basically, I need a small number of properties, stored externally to the .WAR to be available in the XSLT.
Has anyone needed to do something similar? If so what approach did you use?
thanks
For reference, it's worth checking out the cocoon input module RequestModule
Why exactly do these properties need to be stored outside of the WAR? Cocoon already keeps plenty of deployment-specific configuration inside WEB-INF.
If you're simply trying to keep the configuration out of the sitemap, .properties files may be your solution. The properties defined in **.properties in WEB-INF are available for use in Cocoon's sitemaps using ${property-name} notation.
Note that my answer is based off my experience with Cocoon 2.1.11; it may work differently in other versions.
Related
I look for a tutorial, help or an example that tells me what I have to do to write a grid element like 2-colums in basic typo3 (v9) with fluid but no other extension like gridelements, DCE, Templa Voila, etc. I want the same gridelements can do but I dont want to be depended to this extention and move it in my own site extention.
I tried the same with normal content elements (CE) like here:
https://docs.typo3.org/c/typo3/cms-fluid-styled-content/9.5/en-us/AddingYourOwnContentElements/Index.html
But how can I nest a CE in a CE? And how can I do this by drag&drop in the backend?
You can't. The page module doesn't support nesting
You can't nest CEs in a CE. On database level this would mean that you have to make a tt_content record a subrecord of a parent tt_content record. You run into several problems, basically the multilanguage support will be broken and the shortcut element does not function as you will expect it to. That is why the extensions "gridelements" and "mask" exist.
I integrated the gridelements configuration into my sitepackage. So I do not need to bother anymore with it.
Just for your info:
There is now an initiative that works on integrating this functionality into the core (Structured Content Initiative, https://typo3.org/article/a-structured-content-initiative/). Stay tuned to it.
There is nothing special about providing Gridelements via external files, since it's based on TSconfig, TypoScript and Fluid. That's why there is not that much about it in the documentation, since it's the same thing you would do with any other kind of sitepackage. The TSconfig and TypoScript parameters are already explained there, while the Fluid would be up to you anyway.
To have a kind of kickstarter just take any extensions providing Gridelements layouts as an example. A very popular one would be bootstrap_grids, which can be found in the TER or here: https://github.com/laxap/bootstrap_grids
You don't necessarily need the flexform controller of that extension, but the Configuration and Resources folders, show you how to configure stuff and you can see how that is included via ext_localconf.php
There are even comments i.e. in the TSconfig files to explain what is possible there and how to handle i.e. mixed environments with record and file based setups. Although it would be recommended to go for files.
You would at least have to add the necessary backend rendering methods to a draw item hook, that will modify the preview of the container element.
So basically you would have to rewrite everything that DCE, Flux, Gridelements or other similar extensions already do.
Which brings us to the question, why you want to avoid those extensions, since especially those three are well known, widely spread, well supported and available for currently supported TYPO3 versions.
In my Liferay module, I want to use Liferay's SomeConvenientClass.
What is the recommended way to find out what module provides that class?
So that I can quickly add it to my build.gradle.
Ideally it should either:
return the module's group/name/version,
or say with certitude that this class does not exist in Liferay or is not exported.
Until now I go by trial-and-error and copy/paste from build.gradle files found in the wild, but I am looking for a more reliable method.
I have Liferay installed, and the source code of the exact same Liferay version, if that helps.
I tried mvnrepository but it does not seem to return anything, example: https://mvnrepository.com/search?q=AuditMessageProcessor
Have you tried http://search.maven.org/#advancedsearch ?
For example:
http://search.maven.org/#search|ga|1|c:"AuditMessageProcessor"
This is more an option than a real thing, but this is how I normally do:
be familiar with package naming conventions used by liferay and
inside apps: api, service, web...
be familiar with the bundle structure used by liferay, as their
use of resource folders, which are not so obvious sometimes...
With that in mind, normally on github is enough to navigate: portal->(kernel/impl/services/apps)->app service/api/web...
But this is a natural process that comes when you spend your day inside the code.
Normally, online jar locators help, but quite often I just rely on my IDE.
On my IDE I have all set-up with Spring dependency management, after I extracted the dependencies using Gogo shell with a running bundle. With Gogo you will not find classes, but modules and packs will be listed. (Gogo is probably what you are looking for btw, as it is able to list with version numbers)
Bottom line, if you need a list as a picture of a running environment, use Gogo.
With regards to the master code, just do not trust it! When it comes to modularity and bundles versioning Liferay is pretty messy (read The dependency management problem here: https://www.e-systems.tech/blog/-/blogs/liferay-digital-experience-platform-review-7-0-ga4).
For your step 7, you will need to chose an api version and code against it. The apis are more stable. You can impose a limit for compatibility on you bnd file, which will cause the system to issue warnings. On your environment, you can catch api changes earlier, let's say, you can ask gradle to use a module with an version number but any patch (using the "+" sing), when you build with a fresh cache or if you change gradle resolution strategy to download you dependencies more frequently, if the build breaks, well, you will see it.
Helpful start point: https://dev.liferay.com/pt/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell
This is how I do, it is slow and manual, so don't hesitate to suggest other methods.
Download Liferay's source code if you don't have it already.
Run find . -name SomeConvenientClass.java. If nothing is found, you can be sure the class is not part of Liferay.
In the path to the class, find the src folder level, and go just under that, so for instance if it is modules/apps/collaboration/document-library/document-library-web/src/main/java/com/liferay/document/library/web/portlet/action/DLViewMVCRenderCommand.java then go to modules/apps/collaboration/document-library/document-library-web/.
Hopefully there is a bnd.bnd file there, open it.
If the package of the class is not in the Export-Package section, then either give up (duplicate Liferay's code into your module), or use some dark tricks. If you believe the class should be exported, you can explain your case at https://issues.liferay.com/browse/LPS-70480 for future generations to enjoy.
Module name is the value of Bundle-SymbolicName.
Version is the value of Bundle-Version.
Group is probably com.liferay, although sometimes it is com.liferay.portal, not sure how to tell.
Build. Sometimes it fails because Maven repositories are missing a version, for instance com.liferay.document.library.web 1.0.11 is not available despite being used by DXP fix pack 30. Not sure what to do in such cases except choosing a "similar" version and hoping for the best.
I have deployed a document library hook which includes many jsp files under custom_jsps.
Recently, I wanted to change folder_action.jsp, so I changed it and deployed it normally in document library portlet.
As it was expected, a folder_action.portal.jsp was created containing the original file.
However, I've noticed something strange. After stopping Tomcat both folder_action.jsp and folder_action.portal.jsp are deleted(this is not happening for the other files that come from the hook), and when it is up again a really strange thing happens. The folder_action.portal.jsp contains the changed file and the folder_action.jsp is the original file.
Has anyone met something similar ever? Any help would be appreciated.
You might run into a very nasty issue: You must only override a particular jsp from exactly one hook. If you override the same jsp from two different hooks, the scenario that you describe might happen (on undeploy). Worse: Order is not maintained, you might have some "wrong" files left over.
Find the two hooks that override the same jsp and determine which you like better (or merge the two). Find some more horror in this answer to a similar question
I want to send log messages to several files (i.e. different appenders) based upon some property of the message.
The problem is that each appender needs to specify quite a verbose layout (that contains a compication conversionPattern and a couple of converters). I have ended up duplicating this configuration in each appender. This works but is not ideal as it makes the config much longer than I would like as well as the pain of having to update 3 complicated bit of configuration when the layout changes.
I want to be able to define the layout once and have all my appenders refer back to that one definition (in the same way that several loggers can refer to the same appender). But perhaps there is a better way to achieve my goal of reducing duplication in the configuration?
My google-foo is weak and I could not find an answer. Can anyone here help?
TIA.
I am sorry but unless you are ready to code your own Layout class there is currently no way to skip on the copy-pasted configuration.
You can inherit from the LayoutSkeleton to get started, and either build your layout in code or use an alternate configuration file (I don't think that log4net would be kind to a dangling layout configuration in its config file)
I'm trying to find a better way to move my Expression Engine 2 sites from development to live servers. I have a checklist that I go through, starting with running a find and replace for the old/new URLs and server paths, then I update the database config file. This however misses out a huge amount of settings that I then have to go through and change manually, but I don't see why I should need to (unless these are encrypyed somewhere).
For example, I have to change the "Basepath to Template File Directory" in the Global Template Settings manually, along with member settings and a handful of others. There must be a file or entry with these in somewhere that I can change before I upload but I can't find it.
Does anyone know where these are stored?
Those are stored in the database, unless you are using global config variables.
I would highly recommend looking into some sort of config bootstrap. There are quite a few solutions to this, but it's really up to you to pick what's right for your development style / environment(s).
Take a look at the following articles:
http://eeinsider.com/articles/creating-a-robust-config.php-file/
http://boblet.tumblr.com/post/68095239/ee-localhost
http://eeinsider.com/articles/multi-server-setup-for-ee-2/
I've tried those solutions, but in my opinion the best option is NSM config bootstrap.
Check it out here: [http://ee-garage.com/nsm-config-bootstrap][4]
The only thing (currently) missing from these solutions are new config vars regarding file upload paths and locations. You can add those to any of these solutions by adding the variables detailed in this article:
http://expressionengine.com/user_guide/cp/content/files/file_upload_preferences.html#overriding-upload-paths-and-urls-using-configuration-variables
I know I'm late on this one, but for anyone else searching, this plugin is very useful and I have used it on numerous occasions.
ExpressionEngine stores your website URL and Server Path in a ridiculous number of places.
REElocate helps you update these in one simple step.
https://github.com/expressodev/reelocate