Iam facing difficulties publishing items after an import.
When i import 5-600 items through the api, the data gets saved in the items as exptected when i open the item in umbraco admin.
But the umbraco.config files dont change at all. if i through umbraco marks the root element of the items, and publish with childnodes, nothing changes either.
But i publish one of the nodes manually in umbraco admin, the xmlcache is updated.
DocumentType dct = new DocumentType(1068); umbraco.BusinessLogic.User u = new umbraco.BusinessLogic.User(0); int parent = 1073; Document d = Document.MakeNew(dr["name"].ToString(), dct, u, parent); d.getProperty("price").Value = int.Parse(dr["price"].ToString()); d.getProperty("category").Value = 6; d.getProperty("description").Value = dr["description"].ToString();
Sry i did not answer, the problem was/is that iwe changed the documenttype alias, seems like i have to manually publish all the items from the admin ui :/
When you change the alias of a doctype the cmscontentxml table is rebuild. To do this Umbraco does a truncate of all the existing records and then starts rebuilding the table from other tables in the database. If this process is terminated before it ends the table ends up in internmediate state and data seems missing. Since you have a lot of nodes it is likely you though the browser was hanging and you killed the process.
You already mentioned solving it by republishing the full tree, but this can take a while. Renaming the alias of any doctype restarts the process and goes a bit quicker. As for it being a bug: not really, but truncating a whole table without knowing if it will be fully rebuild seems a bit of a wrong programming choice.
Problems publishing through API
Hi.
Iam facing difficulties publishing items after an import.
When i import 5-600 items through the api, the data gets saved in the items as exptected when i open the item in umbraco admin.
But the umbraco.config files dont change at all. if i through umbraco marks the root element of the items, and publish with childnodes, nothing changes either.
But i publish one of the nodes manually in umbraco admin, the xmlcache is updated.
Iwe tried everything from this tutorial:
http://our.umbraco.org/wiki/reference/api-cheatsheet/publishing-and-republishing
The disk permissions should be fine.
my code:
After iwe runs though all the documents to update, i fire : umbraco.library.RefreshContent();
But the items is not published, the umbraco.config is untouched. The umbracoLog says everything is fine.
What am i doing wrong ?
Best regards
Jacob
Hi Jacob,
A sample code below works fine with me
DocumentType dct = new DocumentType(1068);
umbraco.BusinessLogic.User u = new umbraco.BusinessLogic.User(0);
int parent = 1073;
Document d = Document.MakeNew(dr["name"].ToString(), dct, u, parent);
d.getProperty("price").Value = int.Parse(dr["price"].ToString());
d.getProperty("category").Value = 6;
d.getProperty("description").Value = dr["description"].ToString();
d.Publish(u);
umbraco.library.UpdateDocumentCache(d.Id);
Hi Adi.
Sry i did not answer, the problem was/is that iwe changed the documenttype alias, seems like i have to manually publish all the items from the admin ui :/
http://umbraco.codeplex.com/workitem/26047?ProjectName=umbraco
A bug, imo, that needs to be fixed :)
Hi Jacob,
When you change the alias of a doctype the cmscontentxml table is rebuild. To do this Umbraco does a truncate of all the existing records and then starts rebuilding the table from other tables in the database. If this process is terminated before it ends the table ends up in internmediate state and data seems missing. Since you have a lot of nodes it is likely you though the browser was hanging and you killed the process.
You already mentioned solving it by republishing the full tree, but this can take a while. Renaming the alias of any doctype restarts the process and goes a bit quicker. As for it being a bug: not really, but truncating a whole table without knowing if it will be fully rebuild seems a bit of a wrong programming choice.
Grtz,
Sandor
is working on a reply...