Another problem is the Publish method on the node, which needs a user to publish. Thats properly great in some situations, but in my scenario the property is changed by the system, not by any specific user.
Is this in the Umbraco back-office, or via the APIs?
If its the back-office, then if you just press "Save", then it wont publish the content. (Obviously, "Save & Publish" will).
In the API, it's the same... you can update any of the document's properties and it will not re-publish the content ... again, you'd need to manually do that via another API call.
If you need some code examples for the API, let us know.
Yeah, separating could be a solution. But wouldn't it be a nightmare for the webmaster to keep that running? Then he would have to create two nodes every time he should make one of these.
It's not possible OOTB or with the API, publish a node and you publish everything on it.
I'm a +1 for separating it, and it wouldn't be *that* much of an overhead, you could create an event handler that when a page of the primary doc type is created it will automatically create the other one(s).
It's a good idea, and would be easy to implement. The problem with this solution in our scenariio though, is that we do not know the structure of the the site and don't will/want to. So We wouldn't know when to create the ekstra node.
You can achieve that by doing the following 3 steps:
1) Change the value in the back-end (database). You can do that programmatically using the Document object by setting the value of the corresponding property. To do that simply execute: doc.getProperty("propertyName").Value= "some value";. This changes the value in the database but you can also use a doc.Save(); command. Also have a look at http://our.umbraco.org/wiki/reference/api-cheatsheet/difference-between-a-node-and-a-document.
2) Then change the value in the xml cache that is used for displaying the node. This is located in table cmsContentXml for every node. If the property does not exist (it is a new property) you will have to add it yourself.
3) Last, right click on the umbraco parent node (Content) in the api (frond-end) and use "Republish entire site", so that umbraco refreshes the cache (file umbraco.config) with the new xml data that you changed in the database in step (2).
The drawback of this approach is that it will make the audit information inaccurate as there will be changes in the nodes that are not contained in the audit trail. the changes will be for the properties that are changed programmatically.
How to change node property without publish programmatically
Hi,
I need to edit one of the the nodes properties, without publishing any other changed values, that the user might have entered and saved prior.
It would be bad just publishing everything as the user might not want he's changes published yet.
Any ideas?
/Rune
By the way.
Another problem is the Publish method on the node, which needs a user to publish. Thats properly great in some situations, but in my scenario the property is changed by the system, not by any specific user.
/Rune
Hi Rune,
Is this in the Umbraco back-office, or via the APIs?
If its the back-office, then if you just press "Save", then it wont publish the content. (Obviously, "Save & Publish" will).
In the API, it's the same... you can update any of the document's properties and it will not re-publish the content ... again, you'd need to manually do that via another API call.
If you need some code examples for the API, let us know.
Cheers, Lee.
Hi Lee,
Thanks for the fast reply. It's from the API i want to do it.
A regular save won't cut it as I need the ned property to be published. But ONLY that one.
/Rune
ned = new
Ah, sorry - I misunderstood your original question. Didn't realise that you wanted to change a single property to publish only.
Hmmm... not sure how it would be done. To be honest, I'm not even sure that it should be done!
I think it would cause problems with the Audit trail for a content document. But if I think of anything clever on how to do it, I'll let you know.
Have you considered separating out the properties into their own doc-type/content ... so that you don't have these conflicts?
Cheers, Lee.
Yeah, separating could be a solution. But wouldn't it be a nightmare for the webmaster to keep that running? Then he would have to create two nodes every time he should make one of these.
/Rune
It's not possible OOTB or with the API, publish a node and you publish everything on it.
I'm a +1 for separating it, and it wouldn't be *that* much of an overhead, you could create an event handler that when a page of the primary doc type is created it will automatically create the other one(s).
It's a good idea, and would be easy to implement. The problem with this solution in our scenariio though, is that we do not know the structure of the the site and don't will/want to. So We wouldn't know when to create the ekstra node.
/Rune
You can achieve that by doing the following 3 steps:
1) Change the value in the back-end (database). You can do that programmatically using the Document object by setting the value of the corresponding property. To do that simply execute: doc.getProperty("propertyName").Value = "some value";. This changes the value in the database but you can also use a doc.Save(); command. Also have a look at http://our.umbraco.org/wiki/reference/api-cheatsheet/difference-between-a-node-and-a-document.
2) Then change the value in the xml cache that is used for displaying the node. This is located in table cmsContentXml for every node. If the property does not exist (it is a new property) you will have to add it yourself.
3) Last, right click on the umbraco parent node (Content) in the api (frond-end) and use "Republish entire site", so that umbraco refreshes the cache (file umbraco.config) with the new xml data that you changed in the database in step (2).
The drawback of this approach is that it will make the audit information inaccurate as there will be changes in the nodes that are not contained in the audit trail. the changes will be for the properties that are changed programmatically.
For step (2) also have a look at: http://our.umbraco.org/wiki/reference/api-cheatsheet/publishing-and-republishing, but note that generating a node's xml from scratch will include any unpublished information from the users.
is working on a reply...