Hi Crispin,

I mentioned in previous post that images posted from Word go into site root folder - can you fix that? as for WLW?

I'm not sure how it was possible in the old implementation for it to work differently in word than in WLW since both are using the same api. I'm pretty sure it is consistent in the new implementation. Have you tried it on our demo site with Word?

I noticed today that publishing from WLW with the "post draft to blog" tool instead of the "Publish" tool makes no difference - the post is fully published in the mojoPortal blog. Any way of making this create a draft post in mojoPortal?

Thanks! I'll investigate that, I had not tried post draft to blog yet.

Best,

Joe

Hi Crispin,

I've just updated the demo site with the latest build which now supports editing pages (with the caveats previously discussed) along with blog posts. It now supports posting both pages or blog posts as draft in addition to direct publishing.

I could use some additional testing so if you have time please do test it on the demo site. Note that every time the demo site gets reset you will need to re-configure your settings for it in Live Writer because the ids on things change, it is a new site and a new blog when it gets reset even though it has the same content. 

Thanks,

Joe

Hi Crispin,

Regarding security, clearly this ability to post pages should be controlled...  the ability to create pages at root level or below any other page should (IMO) be governed by whether the connecting account is in the "roles that can create root level pages", or the roles permitted to create child pages under each other page. Ideally the pages returned to WLW as the possible parent pages should be only the ones you have permissions to use.  I've not tested whether this is already implemented.  If this is too complex, an interim solution would be to limit this to the administrator and content publisher roles.

Of course security rules must be enforced and are enforced when using the metaweblog api. I would never release this functionality without doing that.

For pages there are basically 2 methods for getting a list of pages wp.getPages gets the list of pages available for editing and this method only returns pages that the user can edit and that have an html instance in the center pane. From WLW UI it is the File > Open recent post > Open From: selected blog > Pages radio button that shows these.

Then there is wp.getPageList which is used to populate the parent page dropdown. However we cannot limit this to only pages the user can edit because the user may be able to edit the child page but not the parent page, and we cannot limit it to pages that have an html instance because the parent page may not. So the best solution I could think of was to limit it to pages for which the user has view permissions. Therefore we have to assume that the user cannot edit any pages that are child pages of pages for which he has no view permissions. While technically he could have such permission, even from the web UI that would be unusual since the child nodes of a page he has no view permission on would not be in the menu.

So the result is that the parent page list may include pages that the user cannot edit and cannot create child pages below. In that case if the user tries to make one of those pages the parent we throw an error with a message about it that is shown in the error dialog of WLW indicating to the user that they cannot use the selected parent page. However this is only if the user is trying to change the parent page. The page he can edit may already have a parent that he has no permission on so we have to make it show those pages and we have to let the user keep that selected in the parent dropdown. We just can't let him move other pages there or create new pages there.

Thanks for letting me know about the error on In Site Analytics demo. I've fixed that.

Best,

Joe