Extension configuration in sub blog

Topics: Business Logic Layer
Jan 24, 2013 at 6:46 PM
Edited Jan 24, 2013 at 7:07 PM

I noticed that extensions can only be configured on the master blog and not sub blogs.  Is this the intended functionality? 

The extensions.chtml also checks for the primary blog before displaying the configuration tabs.

I do see that each sub blog stores individual extension data in \datastore\extensions

This function only pulls from the master blog and not from the data in the sub blogs

<%= BlogEngine.Core.Web.Extensions.ExtensionManager.GetSettings("vTechApplicationSetting").GetSingleValue("PrimaryPhoneNumber")%>

Can anyone shed some light on this, as this is extremely limiting for configuration of sub blogs.

Coordinator
Jan 24, 2013 at 7:28 PM

It is intended. Extension works on application level, if you make a change on your blog it will effect all other blogs, so only "root" admin can install/configure extensions. In sub-blog, you can only turn it on/off. Extensions folder in datastore was probably copied when main blog was used as a pattern to create sub-blog, but it won't really be used.

Jan 24, 2013 at 7:32 PM

Thank you for your quick response;

The issue that I'm running into in one example is the is the AddThisDotNetv5 extension where you can show or hide various social media buttons, this decision is made the sub blog level based on the need of the blog ... in this instance I have to accept a global configuration.

Is this a complex modification, and will it go against future plans of this functionality?

Coordinator
Jan 24, 2013 at 8:46 PM

It may not be complex but not a quick change either. This functionality totally makes sense, we just need to work through it. I guess we would need a way for root admin to decide it extension can be configured in the child blog and then child blog be able to display and save settings in the blog's datastore.

Jan 24, 2013 at 8:57 PM

Something to consider for the next release? It would make extensions extremely powerful in a multi Blog deployment.

Thanks

Jack Kubik

Vanadium Interactive

http://vanadiumtech.com

6 Venture #110

Irvine, CA 92618

(800) 480-5659 x110 direct

Description: Description: Description: Vanadium Interactive

a marketing agency

From: rtur [email removed]
Sent: Thursday, January 24, 2013 12:53 PM
To: Jack Kubik
Subject: Re: Extension configuration in sub blog [blogengine:430768]

From: rtur

It may not be complex but not a quick change either. This functionality totally makes sense, we just need to work through it. I guess we would need a way for root admin to decide it extension can be configured in the child blog and then child blog be able to display and save settings in the blog's datastore.

Jan 31, 2013 at 8:26 PM
I just came across another configuration limitation with Sub Blogs. Is there a reason the custom code settings are locked on the sub blogs? This prevents adding tracking scripts if you are using multiple domains.
Jan 31, 2013 at 8:51 PM
vanadiumtech wrote:
I just came across another configuration limitation with Sub Blogs. Is there a reason the custom code settings are locked on the sub blogs? This prevents adding tracking scripts if you are using multiple domains.
It seems that the boxes are disabled in the headtrack.aspx.cs via if (!Blog.CurrentInstance.IsPrimary) { txtTrackingScript.Enabled = false; }, I commented it out and the code seems to save in the appropriate settings file and pull from the correct settings file in the sub blog when rendering the pages ...

Not sure what the reason behind disabling these fields is.
Nov 20, 2013 at 5:18 PM
Hey rtur;

Did you guys resolve this issue with ver 2.8, because it seems to partial work. The issue I'm seeing now is that anything you save on the extension through the admin console only updates the root version of the xml for that extension, not the xml on the sub blog. I checked the default extensions like BBCode.xml and it seems to be doing the same thing.

thanks
Nov 20, 2013 at 5:52 PM
Narrowing it down;

The issue in most core extensions is that when you save settings in sub blogs they are updating the root blog xml rather then going into the subblogs xml.

Would love to hear back from someone weather this is an issue within the extension code or a problem with the core dll's and how they handle subblogs.
Nov 20, 2013 at 6:32 PM
Found the culprit, but now I'm wondering if this was part of older code or something that had a reason with the current implementation of sub-blogs
       private static string StorageLocation(ExtensionType extensionType)
        {
            string result;
            switch (extensionType)
            {
                case ExtensionType.Extension:
                
                    /*
                     * jk - 2013-11-20
                     * This was casusing the setting to be stored in the root xml rather then with the sub-blog xml
                     
                    Blog blog = Blog.Blogs.FirstOrDefault(b => b.IsPrimary);
                    result = Path.Combine(blog.StorageLocation, "datastore", "extensions");
                    */
                    result = Path.Combine(Blog.CurrentInstance.StorageLocation, "datastore", "extensions");

                    break;
                case ExtensionType.Widget:
                    result = Path.Combine(Blog.CurrentInstance.StorageLocation, "datastore", "widgets");
                    break;
                case ExtensionType.Theme:
                    result = Path.Combine(Blog.CurrentInstance.StorageLocation, "datastore", "themes");
                    break;
                default:
                    throw new NotSupportedException(string.Format("Unknown extension type: {0}", extensionType));
            }

            string mappedResult = HostingEnvironment.MapPath(result);
            if (string.IsNullOrEmpty(mappedResult) && result.StartsWith(BlogConfig.DefaultStorageLocation))
            {
                // this can only happen in Mono. We'll try again with AppDomain but it will only work if BlogConfig.StorageLocation == "~/App_Data/" (which is the default value)

                string appDataPhysical = AppDomain.CurrentDomain.GetData("DataDirectory").ToString();
                mappedResult = Path.Combine(appDataPhysical, result.Substring(BlogConfig.DefaultStorageLocation.Length));

            }

            if (string.IsNullOrEmpty(mappedResult))
            {
                throw new InvalidOperationException(string.Format("Could not map folder {0} for extension type {1}", result, extensionType));
            }

            return mappedResult;
        }