Vulnerability in EPiServer.Forms
I am using EPiServer CMS 6 R2, and I have mistakenly cloned the XHTML String (>255) with a defunkt namespace attribute.
I can edit this custom property type, change its name, namespace ect, but the delete button is greyed out. The field (And the field it was cloned from) are not used in any page types (I have a single page with no properties) however I am still unable to remove this property type.
Can anyone advise how to remove said property type? Or give me a hint as to where the reference/data might be thats causing the CMS to think the field is in use?
Further to the above...
If I hover over the delete button it says "System types can not be deleted". Not sure if its relivent at all, but it indicates its marked as system when in fact its a clone of a valid system property type...
Sounds to me like a bug, I would report this to EPiServer. You can probably delete it directly in the database though, in the tblPageDefinitionType table.
If you need to do it in the DB, you should consider using the procedure netPageDefinitionTypeDelete since it will do the needful for you =)
Hi guys, thanks for the quick responses.
Indeed, my own curiosity led me to the tblPageDefinitionType table soon after posting this, however the problem becomes a little more obvuscated. Careful inspection of the table shows only 1 instance of the XHtmlString property type! It has the namespace of EPiServer and clearly relates to the correct property type.
I'v tried to replicate the problem, from a vanilla working copy of AlloyTech example. WHat I did to result in a 'clone' was edit the XHtmlString Property Type via the CMS panels, Enter a new namespace and saved. This results in a duplicate for me, that does not exist in the tblPageDefinitionType table.
Any suggestions where this duplicate might be coming from? I can rename the duplicate so its not a show-stopper but I am thinking if I can at least track down the source of this duplicate it might be worth raising as a bug...
Thanks again guys,
Very sorry guys, it seems I had connected to the wrong database in VWD, apologies. I have now located the errand table entry, in the correct database!
I'll reply tomorrow, just to confirm the problems sorted, I will try the function first in case it takes care of anything else not covered by just deleting the row from the table.
Thanks for the advise guys!
It's always a good start to look in the right database =)
Just a word of caution - be careful about deleting a row from tblPageDefinitionType since it may be refered to from tblPageDefinition (which might be a property in a page type or a dynamic property).
Serves my self right for running a few different versions of AlloyTech Demo as sort of sandboxes while I get to grips with the CMS and fgetting it to play nice with VWD.
I realised this potential relationship, fortunately the site in question is essentually completely empty, no page types or property values defined as of yet. I resolved to fix this property type problem before I started defining my page types and properties.
Great advise and worth considering though, thanks. I wonder, does the netPageDefinitionTypeDelete functiontake this relation into account when called? Will it raise an eror or recursively delete exisiting field values if called on a populated database?
LOL. I just checked the code for netPageDefinitionTypeDelete and it didn't really do what I was hoping for... basically it tries to perform a DELETE FROM tblPageDefinitionType, and if it fails (due to references) it will raise an error. I think I mixed it up with netPageDefinitionDelete which will in fact remove a property from a page type and all its occurances in pages too...
Since you don't seem to have any definitions using this type it should be safe to delete (either with a raw DELETE or by using the SP)... =)
Just to confirm, deleting the erronious PageProperty using the Stored Procedure worked a treat.
Thanks for the help guys!