For publishagent to auto publish Items that are in final state of workflow. I have made following changes in Config file:
<agent type="Sitecore.Tasks.PublishAgent" method="Run" interval="00:02:00">
<param desc="source database">master</param>
<param desc="target database">web</param>
<param desc="mode (full or smart or incremental)">incremental</param>
<param desc="languages">en, da</param>
</agent>
Items are not getting published.While changing the mode to smart is publishing items. Does this publish agent works in incremental mode with sitecore 8.2 publishing service?
There is a bug in the combination publish agent/incremental/publish service. The development team at Sitecore is aware and it will probably be fixed in a next version.
As far as I know, there is no patch available yet.
Related
I am using Sitecore 9.1 and I set future publish/unpublish dates for some of the items.
I found two articles to do this:
This article talks about
1. Download the AUTOMATED PUBLISHER module from the Sitecore Marketplace.
2. Have your Sitecore implementers write your own custom code that is triggered by a Sitecore Task.
https://www.techguilds.com/Blog/2018/11/scheduled-and-advanced-publishing-with-sitecore-part-2
and
This article, which advises to do it by patching values in the config file:
<agent type="Sitecore.Tasks.PublishAgent" method="Run" interval="00:00:00">
<param desc="source database">master</param>
<param desc="target database">web</param>
<param desc="mode (full or smart or incremental)">incremental</param>
<param desc="languages">en, da</param>
</agent>
https://community.sitecore.net/developers/f/8/t/5496
Is auto-publishing built OOB in any version (in my case 9.1) ?
If not, which of the above would be the preferred way to do this?
From another post, confirmed that you can use the config option. Tested it out and it works.
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.
Publish error | smart publish or Republish - publish everything is stuck in initializing and does not finish
We have upgraded sitecore application from 6.2 to 7.1 recently. We are facing a critical issue when we try to publish the created items in the upgraded application where Smart Publish or Republish-Everything stuck in "Initializing" stage and will never finishes.
We have removed the staging module which was performing the media publish from CM to CD and implemented the scalability setting by enabling the scalabiltysettings.config and configuring the webdeploy.config with proper folder and permissions set. No issue with user permission and folder settings observed.
Sitecore version 7.1 13090
Sitecore\Admin and client specific accoungs with Admin role
Please let us know what is causing the issue. Also, revert back if you need more info.
This normally happens when your History table is excessively large. Try cleaning it out (under most circumstances it's completely safe to do so) and see if your publish starts picking up quickly.
If you are in an environment with many item changes, you might also oconsider decreasing the default 30 day lifetime of History table entries.
<Engines.HistoryEngine.Storage>
<obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">
<param connectionStringName="$(id)" />
<EntryLifeTime>30.00:00:00</EntryLifeTime>
</obj>
</Engines.HistoryEngine.Storage>
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.
When a I am developing a new feature for my application that uses a lot of new tables the table definitions are not stable until after a few days of development. I want to check in these unstable migration files into source control WITHOUT having them be applied on the production box, when i deploy bug fixes of the same code base.
Is there a way to have a migration file in flyway be applied on a developer machine but not on a production box?
I don't like feature branches so I want to avoid feature branches they are just too much effort for me to maintain.
Since I am using Spring 3.1 I was able to solve my problem using the spring profiles, to detect what environment the code is in. Here is how the solution works.
db.migrations is where the production migrations go
dev.db.migrations is where the development migrations go. During initial development of a new feature when tables are changing every hour or so, the migration file gets added to dev.db.migrations and checked into source control, it gets created on developer machines. Developer will typically blow away the test db and recreate it with sample data, so no harm in constantly changing the files in dev.db.migrations it also gives developers a chance to grab a version number for their changes, since they will checkin their file into source control.
below is the XML for spring profiles flyway configuration that I used.
<!-- =========================Configure Flyway ========================= -->
<bean id="flyway" class="com.googlecode.flyway.core.Flyway" init-method="migrate">
<property name="dataSource" ref="dataSource"/>
<property name="locations" ref="flyway-migration-locations" />
</bean>
<!-- ========================= Development Profile Configuration ========================= -->
<beans profile="development">
<bean id="flyway-migration-locations" class="java.util.ArrayList">
<constructor-arg>
<list>
<value>db.migration</value>
<value>dev.db.migration</value>
</list>
</constructor-arg>
</bean>
</beans>
<!-- ========================= Production Profile Configuration ========================= -->
<beans profile="production">
<bean id="flyway-migration-locations" class="java.util.ArrayList">
<constructor-arg>
<list>
<value>db.migration</value>
</list>
</constructor-arg>
</bean>
</beans>