I need to patch Sitecore's pipeline to disable one of the processors.
Can I do that, or should I remove and implement whole pipeline?
There is nothing like disabling processor in Sitecore out of the box.
What you can do, you can create a patch config which will remove that processor. But you need to be aware that this processor will never be executed unless you change the configuration again and application is restarted.
Below is example how to remove RunQueries processor from the contentSearch.queryWarmup pipeline:
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<contentSearch.queryWarmup>
<processor type="Sitecore.ContentSearch.Pipelines.QueryWarmups.RunQueries, Sitecore.ContentSearch">
<patch:delete />
</processor>
</contentSearch.queryWarmup>
</pipelines>
</sitecore>
IMPORTANT:
Remember that Sitecore parses all the config files alphabetically, and then subfolders (alphabetically again). So your patch file must be added "after" the original config which adds the processor. You may want to put all your patches e.g. in App_Config/ZZ.Custom/my.patch.config.
Related
I'd like to know if Workflow process is done or not.
What I wanted to do is:
I created an assembly and once Workflow process is in Final state or Auto-Publish work is done, execute the method in the assembly.
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<events>
<!-- Once Workflow autoPublish is done, do this for CDN -->
<event name="publish:complete:remote">
<handler type="My.Class.Name, Assembly.Name" method="MethodName">
</handler>
</event>
</events>
</sitecore>
</configuration>
How can I do this??
All action that you have under workflow command work in a similar way as regular pipelines and processors that you have in your configuration files. But in this case command is pipeline and action is processor.
So, to execute something just after Auto-Publish command you should add another one command after Auto-Publish command. This new command should contain link to method that you to execute.
It depends on what you really want. Do you want to know that the particular item has passed the workflow or do you also want to know that the async publish action has completed? Defining an additional action after the auto publish is definitely the easiest way. Adding an event handler is also possible but more complex since the event handler will be triggered for each item / site publish. How are you going to differentiate?
I see you're using the publish:complete:remote event but I wonder if Sitecore even uses it. HtmlCacheClearing for example is running in the publish:end:remote event.
I would like to restrict one of my web services running under Tomcat 7. That is, I have one instance of Tomcat 7 hosting several web services. Some of these web services need not be restricted to a specific IP-address, so this restriction must be per-app.
Initial search on the subject suggests that it is possible to do so via a Remote Address Filter by adding something like:
<Context>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="10\.180\.156\.159"/>
<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/>
</Context>
in "some" XML file that is part of the deployed WAR file.
My problem is that "some XML file" is very confusingly named. My understanding is that it is supposed to be the context XML but the context XML can be named anything... (it looks like the <param-name>contextConfigLocation</param-name> in <context-param> in web.xml that determines the name)
So, in the various sources providing the tips to implement this restriction, the references were to:
META-INF/context.xml (my WAR has no META-INF subfolder, only WEB-INF)
WEB-INF/web.xml (I do have that file, but it is the file that points to the context XML, not the context XML itself)
conf\Catalina\localhost\manager.xml (looks tomcat-wide, not per-app)
My context XML is named beans.xml and is located in the WEB-INF/classes subfolder...
Can someone please clarify this issue?
I am going to experiment now with my own guess, but an authoritative answer would be nice.
If you want to include the Valve for just one application, you would do this in a <Context/> block. As you have discovered, there are a few different places where you can configure the Context. Explanations of them below.
META-INF/context.xml (my WAR has no META-INF subfolder, only WEB-INF)
This is the only place where you can configure the context from your application. If you want to do this, simply create a META-INF folder in the root of your project (same location as WEB-INF directory). Inside META-INF, create a context.xml file and put your application specific configuration in there.
When your application is deployed to Tomcat, this context file will (if Tomcat is configured to do so, see copyXML), copy the file into $CATALINA_BASE/conf/Catalina/localhost/<app-name>.xml and add include it in the configuration.
conf\Catalina\localhost\manager.xml (looks tomcat-wide, not per-app)
The actual format of this should be $CATALINA_BASE/conf/[enginename]/[hostname]/[appname].xml where [enginename] defaults to 'Catalina' and [hostname] defaults to 'localhost'. Thus for the "manager" application, the path you listed would be correct. If your application is called "myapp" then you'd use conf/Catalina/localhost/myapp.xml or for the ROOT app, you'd use conf/Catalina/localhost/ROOT.xml.
This is the second location where you can put application specific Context configuration, and would be the one that I would recommend.
There are two other places where you can put Context configuration, one is conf/context.xml and the other is conf/server.xml. Do not use conf/context.xml in this case because it would apply server-wide (i.e. across all of your apps). The conf/server.xml is possible to use, but I would suggest against it. Use of conf/server.xml for configuration like this is discouraged mainly because it's inflexible and requires a complete server restart when you make changes.
In reference to...
WEB-INF/web.xml (I do have that file, but it is the file that points to the context XML, not the context XML itself)
This cannot be used for Context configuration, but you can use it to configure Servlet Filters and Tomcat ships with a RemoteAddressFilter, which does the same thing as the RemoteAddressValve.
It's generally recommended to use a Filter, when available, versus a Valve.
My context XML is named beans.xml and is located in the WEB-INF/classes subfolder...
You cannot use a custom name or location for your Context configuration. It needs to match one of the names and locations specified by Tomcat. For more details on this, see here.
I use jetty in a maven project and logging is already in place using slf4j and logback.
Hence, I have a logback.xml where I configure logging and it works so far (format, setting levels for my project and libraries, ...).
However, now that I added jetty in the pom.xml as a dependency, I get tons of new DEBUG logs which I do not want to see (usually).
How can I set the log level for jetty to a higher level?
At the beginning, jetty reports that it recognized slf4j:
13:08:57 [main] [DEBUG] log - Logging to Logger[org.eclipse.jetty.util.log] via org.eclipse.jetty.util.log.Slf4jLog
In my logback.xml, I tried to mute jetty as follows, but it does not work:
<logger name="org.eclipse.jetty" level="INFO" />
This does the trick for other libraries that I use.
I read the jetty documentation regarding logging, but they only document the use of standalone jetty - unfortunately, I was not able to adapt it for the embedded use case.
I found the answer myself - it is slightly embarrassing.
The issue is that there are two configuration files for logging: logback.xml and logback-test.xml.
I did not adjust the level of the logger in logback-test.xml which is used during development in a maven project.
The logback.xml configuration, on the other hand, is used when a package is built, e.g. in production use.
From the logback documentation:
If you are using Maven and if you place the logback-test.xml under the
src/test/resources folder, Maven will ensure that it won't be included
in the artifact produced. Thus, you can use a different configuration
file, namely logback-test.xml during testing, and another file,
namely, logback.xml, in production.
Due to lack of experiences with logback and maven, I did not know this.
To conclude:
Adding the following to the logback-test.xml solves my issue:
<logger name="org.eclipse.jetty" level="INFO" />
In sitecore we have the possibility of agents and tasks. But it is not very clear when to use which. My situation: I want to run an (possible taking half an hour) importer each night at a specified time. The importer will import data from an external source into sitecore. What is better: an agent or a task?
They roughly mean the same thing.
In the web.config you can define scheduled agents under the <scheduling> section, however some out of the box agents are in the Sitecore.Tasks namespace. So they appear to be one in the same, but really everything is an agent.
In Sitecore itself, under /sitecore/system/tasks you will see definition items for the same thing. These are called "tasks" but in reality, they are just logical definition items that run based on the schedule. In fact, these are just a CMS-friendly way to define what's also in the web.config as agents. There exists a configured agent that processes these from the CMS:
<!-- Agent to process schedules embedded as items in a database -->
<agent type="Sitecore.Tasks.DatabaseAgent" method="Run" interval="00:10:00">
<param desc="database">master</param>
<param desc="schedule root">/sitecore/system/tasks/schedules</param>
<LogActivity>true</LogActivity>
</agent>
<!-- Agent to process tasks from the task database (TaskDatabase) -->
<agent type="Sitecore.Tasks.TaskDatabaseAgent" method="Run" interval="00:10:00" />
So if you want something to be changed in the CMS, create a tasks under the system section. If you want something to be for developers only, create a config patch and apply your own custom <agent> on whatever timer you want.
Scenario:
A section of the content tree is the home item for a site that runs under two host names (www.site1.com and www.site2.com
The purpose of the two host names is to differentiate between two target countries that are served with the same content, and the same organisation (marketing department, web editor etc.)
The content is, of course, identical across the two host names.
Except....
In a couple of places we need some small differences. A contact email, for instance, or a legal notice (these are both just Sitecore content). In other places we may wish to be able to change a presentation component for an item based on which host context it's in. We may wish to do this across all items from a specific template.
To complicate matters, the site is already cloned from another site (www.siteA.com), which is the source of several clones (some translated) for different countries. This is to enable us to push new items/content changes/features to our subsidiary companies. So all templates and presentation components are already shared across lots of host contexts and lots of portions of the content tree.
Is there any Sitecore functionality that would make this possible/simple - or do we need to code context testing into our presentation components (presumably alongside some configuration items within Sitecore to avoid hardcoding values)?
Great question. This is a long-shot, but it may work:
Why don't you create a new device for Site2 and in the cases where Site2 presentation data needs to change, configure the presentation settings for the Site2 device. If not, don't set them and the Default device will render the content. The hard part here will be configuring how the device will resolve. Maybe you can create a custom device resolver in the <httpRequestBegin> pipeline:
<processor type="Sitecore.Pipelines.HttpRequest.BeginDiagnostics, Sitecore.Kernel"/>
<!--<processor type="Sitecore.Pipelines.HttpRequest.DeviceResolver, Sitecore.Kernel"/>-->
<processor type="YourProject.Pipelines.HttpRequest.DeviceResolver, YourProject"/>
<processor type="Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel"/>
In your processor you can look at the host to determine which to use.
You can also define the Site2 device on a new <site ... /> node as Paul mentions below. Something like this:
<site name="site1" hostName="site1.com" rootPath="/sitecore/content" startItem="/home" ... />
<site name="site2" hostName="site1.com" device="Site2" rootPath="/sitecore/content" startItem="/home" ... />
Both Site1 and Site2 point to the same parts of the tree, they just use different devices.