I suddenly realized that the Variations has stopped copying sites and pages from the source to the targets. No recent entries in the log…
Looked into the timer job status and difinition to find that nothing for this particular web application.
I stopped it once intentionally. Unchecked the “Automatic Creation” option. Then I was believing that I had started it again by checking it back.
Found this blog entry http://www.objectsharp.com/cs/blogs/max/archive/2008/02/25/missing-timer-job-definitions-after-sharepoint-move.aspx.
Although what triggerred it is different, the situation is the same. The jobs have disappearred.
I created a “cheating” publishing site collection in the web application in question. The jobs are back. Variations started again.
Tuesday, October 7, 2008
Wednesday, October 1, 2008
FlexListViewer
http://blogs.infosupport.com/porint/archive/2006/08/15/9865.aspx
Have you ever wanted to have a list presented on a page, which resides in a site different from where you have the list?
I believe the list and view are one of the big selling points of Sharepoint. I like them very much. On the contrary, I do not like the Content Query Web Part. Out of question.
Our site is of multi-lingual. We use the Variations technique. Though there are many points of it that I am not happy. This, I believe is one of the biggest shortcomings.
If you say to your users that they have to manage a separate list for each different language, they would laugh at you.
FlexListViewer is my saviour. It allow to have a view displayed in the other site than the one the list belongs to.
Better even, the source code is available. There was a small point of it that does not really fit to our need. We are in the usual, stagin -> internet facing setting. We prepare pages in the staging, and the Content Deployment pushes them to the internet facing site. The out-of-box FlexListViewer, the view URL needs to be a full URL, starting with http://hostname. But in our case, that changes, in the course of deployment. So, do not want to really specify any host.
Thanks to the developper, who made the source available. I modified it so if the specified URL starts with “/”, it assumes the host it is on.
Have you ever wanted to have a list presented on a page, which resides in a site different from where you have the list?
I believe the list and view are one of the big selling points of Sharepoint. I like them very much. On the contrary, I do not like the Content Query Web Part. Out of question.
Our site is of multi-lingual. We use the Variations technique. Though there are many points of it that I am not happy. This, I believe is one of the biggest shortcomings.
If you say to your users that they have to manage a separate list for each different language, they would laugh at you.
FlexListViewer is my saviour. It allow to have a view displayed in the other site than the one the list belongs to.
Better even, the source code is available. There was a small point of it that does not really fit to our need. We are in the usual, stagin -> internet facing setting. We prepare pages in the staging, and the Content Deployment pushes them to the internet facing site. The out-of-box FlexListViewer, the view URL needs to be a full URL, starting with http://hostname. But in our case, that changes, in the course of deployment. So, do not want to really specify any host.
Thanks to the developper, who made the source available. I modified it so if the specified URL starts with “/”, it assumes the host it is on.
Lock down the Internet facing Sharepoint site
There is such a command, but this post is not about that. It did not seem to me what I want.
I want to “lock down” the web site so nobody including me can modify it directly. We use the Content Deployment which pushes what we prepare, permission settings as well as contents, from the staging site to the internet facing site. So the modification should happen only at the staging site.
I said we copy the permissions. Our web site is very di-centralized. Every part has own group of people managing it. The management includes “targetting audiences”, restricting access in other words.
The solution I found is the “Policy for Web application”. It allows to say “Deny Write” for everybody.
This is good. Now even the site collection administrators can not modify it.
However then found that even the user used for the Content Deployment can not write into…
Then the solution found is to Extend the Web application, and define Internet zone for the actual service, Denying Write for everybody, while keeping the Default zone still writable.
I want to “lock down” the web site so nobody including me can modify it directly. We use the Content Deployment which pushes what we prepare, permission settings as well as contents, from the staging site to the internet facing site. So the modification should happen only at the staging site.
I said we copy the permissions. Our web site is very di-centralized. Every part has own group of people managing it. The management includes “targetting audiences”, restricting access in other words.
The solution I found is the “Policy for Web application”. It allows to say “Deny Write” for everybody.
This is good. Now even the site collection administrators can not modify it.
However then found that even the user used for the Content Deployment can not write into…
Then the solution found is to Extend the Web application, and define Internet zone for the actual service, Denying Write for everybody, while keeping the Default zone still writable.
Subscribe to:
Posts (Atom)