We just installed a new Umbraco 7.2.6 site to do some testing of various packages. We are doing development on local versions of the site that all share the same database.
When someone creates a new form in the Forms section, it doesn't show up on everyone else's machine. I was trying to figure out if it was some sort of cache, so I deleted everything in the App_Data/ folder except access.configand packages/ and then recycled the app pool. No luck.
On a whim, I did some searching around in the file system and found App_Plugins/UmbracoForms/Data/forms/e15b9c6e-196c-4926-95dc-cab6137a056c.json on the site that had created the form. Sure enough, if I delete this .json file, I can't find the form in the backoffice anymore.
I heavily suspect that the forms are no longer stored in the database and that the json files I found are not just a cache. I took a look in the database and found these UF tables:
UFRecordDataBit
UFRecordDataDateTime
UFRecordDataInteger
UFRecordDataLongString
UFRecordDataString
UFRecordFields
UFRecords
UFUserFormSecurity
UFUserSecurity
I just wanted to get confirmation that the form exists as json in the App_Plugins directory and has no representation in the database. Only the records, info to support those records, and some security info lives in the DB. Am I right? If I'm missing something, and the json is just a cache, where do the forms live now, and how can I regenerate the json cache files?
I'm curious to know why the forms were moved from the database to the file system. It seems like that would just cause more issues, particularly for publishing and load balanced setups.
Can there please be configuration instead, (so you can set to save to the database or to json @ a storage location commonly used such as app_data or configurable). As there are issues when running deployments to more than one environment. Perhaps the option is to just set the extensive path to a virtual directory which can be isolated from site code deployments and located to a shared mapped directory.
Umbraco Forms exist as JSON and don't live in DB?
We just installed a new Umbraco 7.2.6 site to do some testing of various packages. We are doing development on local versions of the site that all share the same database.
When someone creates a new form in the Forms section, it doesn't show up on everyone else's machine. I was trying to figure out if it was some sort of cache, so I deleted everything in the
App_Data/folder exceptaccess.configandpackages/and then recycled the app pool. No luck.On a whim, I did some searching around in the file system and found
App_Plugins/UmbracoForms/Data/forms/e15b9c6e-196c-4926-95dc-cab6137a056c.jsonon the site that had created the form. Sure enough, if I delete this .json file, I can't find the form in the backoffice anymore.I heavily suspect that the forms are no longer stored in the database and that the json files I found are not just a cache. I took a look in the database and found these UF tables:
I just wanted to get confirmation that the form exists as json in the
App_Pluginsdirectory and has no representation in the database. Only the records, info to support those records, and some security info lives in the DB. Am I right? If I'm missing something, and the json is just a cache, where do the forms live now, and how can I regenerate the json cache files?Thanks
Hi Mark
Thats correct - everything in forms, except for permissions and records have been moved to the file system
/Per
I'm curious to know why the forms were moved from the database to the file system. It seems like that would just cause more issues, particularly for publishing and load balanced setups.
exactly - Per,why choose that approach? we cannot use the Umbraco forms in our load balanced set up on Azure
Can there please be configuration instead, (so you can set to save to the database or to json @ a storage location commonly used such as app_data or configurable). As there are issues when running deployments to more than one environment. Perhaps the option is to just set the extensive path to a virtual directory which can be isolated from site code deployments and located to a shared mapped directory.
is working on a reply...