Starting from Sitecore 7.2, there is an option to publish an item with "Publish related items" checked. If you do that, the <getItemReferences> pipeline (defined in Sitecore.config) will be executed to get additional items that are then added to the publishing queue. By default, it returns the following items related to the item ...
Publishing that many items will always be quite slow, there is a lot of reading, writing and indexing that is required however. I don't think there is going to be any code which will solve this.
I've not seem all the jobs disappearing (with the exception of, as you say Sitecore restarting - can you see this happening in the logs?). However there are some ...
Common uses I've seen is to make the following two things easier:
Preview of the site before it's published where users don't have sitecore access. This preview can be used internally in the organisation to see what is about to go live. Good especially if you have limited number of editors; full details here http://getfishtank.ca/blog/2-big-improvements-to-...
The most likely issue here is the scalability settings for the instance names. Scalability settings allow your different instances to listen to the shared event queue and know which ones to respond to.
Delivery Scalability Settings
Your delivery instances should have a config patch with something like the snippet below. The instance name is not as ...
You can find a great explanation with examples in this blog.
A few reasons to define additional publishing targets mentioned there:
Traffic, geographic distribution, redundancy and other scalability
considerations often demand that customers publish everything to
multiple publishing targets supporting different banks of content
delivery servers in a ...
You could use SiteCron to do this job.
SiteCron is a scheduling module based on Quartz.NET Job Scheduler. SiteCron can be used to create simple or complex schedules to execute jobs. This functionality is implemented using Quartz’s CronTrigger.
“Quartz.NET is a pure .NET library written in C# and is a port of very popular open source Java job scheduling ...
Here's an overview of each of the publishing methods:
This publish will simply fully publish out each item again, regardless of whether it has been published before or not. Therefore this is the slowest publish as Sitecore will still transfer over changes that may already be on the target database.
With this method, Sitecore will look at ...
Because you want to keep the content in the Master database, but you do not want to publish it to the web database, this may be a good opportunity to use Workflow.
If you're using Workflow on these pages
Here's how to fix your issue:
Establish which Workflow your fr-FR pages are using.
In that Workflow, create a new Workflow state called "Archived" or "...
I would go with Sitecore PowerShell Extensions. It supports your version as well.
My idea is to run query and process all items you want to check.
In the past I used something like this to compare revisions between master and web database:
$webItem = Get-...
I spent some time looking into this recently and we decided to use the following module (built by the Hedgehog guys) and it works really well for us so far for scheduling publishing:
It supports the following:
Editing of the ...
The problem with Sitecore.Context.Site:
Sitecore performs publishing on the publisher site, and as you noted, the publish:end is an event and is called without a request, so there isn't even a URL to work from.
Based on the above, hypothetically, if we assume that Sitecore is going to resolve a site (we don't know which yet) to put in the Sitecore.Context ...
To make an educated decision, you need to know what publishing does and what it does not.
Publishing is the process of copying content from one database to another. By default there is one source database - master and one destination database web. The web database is the publishing target.
When you publish, Sitecore copies data from 3 tables Items, ...
With a default install of Sitecore the Publishing runs as a Job. If IIS or the server is restarted, or the Application Pool for your site is Recycled the publishing task will be terminated, even if the Job did not fully complete. Once your site is brought back online, you would be required to republish in order to complete the operation.
Let's say you need create a second publishing target called staging.
You need to create an item for the new database in the content tree at the path /sitecore/system/Publishing targets. Then in the field Target Database, you enter the name like staging.
Now, you need also to create a new database. You can just ...
This can be achieved by updating your Schedule field on your task.
127 represents the days of the week, this task is meant to run. This only makes sense if you convert it to binary.
127d = %01111111
Each of the bits represent a day of the week. Like this.
So to disable the tasks for the weekend, change it to:
I did some research and for simple scenario unpublished content is deleted from the index. In my case, it was Lucene, but that shouldn't be really matter because all relevant code is stored in Sitecore.ContentSearch.dll.
Scenario that I executed:
Create the Item
In Item Publishing Setting uncheck Publishable check-box
Publish Item again
When publishing with subitems and related items, there are two important aspects to keep in mind:
related items of subitems will be published;
related items of related items will not be published.
Comparing two publishing scenarios
Let's consider the relationships between your items:
A (page item) -----------------------+
B (local content) ...
The communication between the Content Delivery and Content Management box is handled through the Event Queue.
Your Content Management instance triggers an event (i.e.: "publish:end:remote")
This event is added to the EventQueue table in the database that is targeted by the event. for the "publish:end:remote" event is usually the "web" database unless you've ...
I think this is possible with SPE. Something like this should work:
Remove-ItemLanguage -Path master:\content\home -Language "fr-FR" -Recurse
Perform this on a CM server and publish the site to move the changes to the web database and the CD servers.
It's probably also a good idea to rebuild your indexes and link database after doing this.
It might also ...
This looks like a bug with the OnPublishEndAsync strategy.
It becomes apparent when authors start creating new versions of content each time they lock and edit an item.
It has been fixed in 8.1 but still resides in the version you are using.
See this knowledge base article
My particular issue was certainly unique, but may help someone in the future. We had mistakenly added three database entries on the server when only two exist:
The web entry used the same connection string as the web-preview element. There were only two database targets defined- web-delivery and web-preview. Nonetheless, ...
You should add the missing nodes in your config. Sitecore has added these things in the database config in Sitecore9. So in your case -for a "web2" database-, add:
<eventQueue name="web2" type="Sitecore.Data.Eventing.$(database)EventQueue, Sitecore....
If your content authors are strictly following WorkFlow, use scheduled Incremental publishes.
If workflow is not strictly used, use user manual publishes (Smart Publish), and try to cover related item publishes to reduce number of cache clears.
For multisite, if you publish item of site-A. It will clear html cache for all sites. It should clear cache for ...
Ok. Well. Would definitely be possible to set something up with Unicorn for this - albeit it a highly unusual configuration. Steps I would take would look something like this:
Set up Unicorn on the CM box to serialize all of the web content you want to regularly push across to CD
This will ensure, the file system always has a copy of everything that is ...
The issue was that in my efforts to trim the index of waste, i.e. remove fields that I'm not accessing, I removed a certain special field (though it is not marked in any way as being important, though by name it makes sense in hindsight). I removed the "_uniqueid" field from the index configuration. Specifically here:
You need to create some custom code to have such a functionality, out of the box Sitecore doesn't have such a functionality.
You can create a template with two fields : Publishing Date and Publishing By.
Create your own class:
public class UpdatePublishingStatistics : PublishItemProcessor
private const string PublishedFieldName = "__Published";
When publish:end:remote event is raised, there is an entry created in the core database EventQueue table.
All the servers (including CD servers) check that table and executes all the handlers.
In terms of performance impact, it all depends on the code which generates the files.
There was a bug in earlier Sitecore 8.2, fixed in 8.2 Update 5 (rev. 170728)
A deleted language version of an item in the master database exists in the web database after publishing.
Smart Publishing does not unpublish invalid item versions.
See the information in the release notes:
You could loop through items in your tree and restrict publishing using Sitecore PowerShell.
$item = Get-Item master:/sitecore/content/home
$item["__Never publish"] = "1"
Some useful links:
As Sitecore Climber mentioned, you could use workflows if you do not need to have a future publish date. Otherwise the Automated Publsiher module might help you, but if you really want something specifically tailored to your needs, it should not be that hard to write that yourself. You could add an agent or use other possible solutions to trigger tasks.