Centralized Widget Repository

Topics: Business Logic Layer, Controls
Jul 27, 2010 at 2:22 AM

I was wondering if implementing a standarized blogengine widget repository for people to utilize is in the road map in the near future?  I know codeplex is what is used now for source control but it is very difficult for end users to find custom plugins that are available for their blogengine installation through the control panel or a centralized website or developers to add them to a list.  I would like to help build this feature into blogengine.

Does this sound like something feasible for BlogEngine.NET?

Jason

Coordinator
Jul 27, 2010 at 8:05 AM
Edited Jul 27, 2010 at 8:43 AM

There is a download page for Widgets and Extensions.  When we find out about widgets/extensions, we usually add them there -- but you can tell there's not much there now.  Within the BE control panel, it could link to those two pages.  Or if there is a centralized repository like you suggest, that repository could be referenced from within the BE control panel to either just let people know what's available, or to possibly download the widgets/extensions for them.  I think in either case, the challenging part is keeping a repository (or those 2 pages I referenced) updated with widgets and extensions people are creating.

For either approach, it does seem like a good idea to at least make this information available within the BE control panel.  That's probably one of the first places people look.

The information in the BE control panel could also offer people a way to submit their own widgets / extensions.  The only danger (which is a big danger) is if people submit malicious widgets/extensions ... like some of the problems places like Firefox have been dealing with recently with their add-ins.

I guess the first questions are, is the repository going to be simple pages like we currently have, or some other mechanism/database ... and how is the repository going to keep updated.

Jul 27, 2010 at 11:42 PM

My initial thoughts are that it definitely needs to be dynamic to reduce the management.

I had been looking at a SVNserver for plugin versioning and using websvn front end to integrate it for requesting a project folder and putting information about the widgets available on a site.  Here are the links for the websvn which has some great features out of the box.

http://www.websvn.info/

Free svn implementations are running on apache which is kind of interesting because this is a .net project and not php but I have no issue with cross-platform usage(AKA not a Microsoft zealot). It seems websvn provides rss feeds which would be really easy to integrate in the admin panel on blogengine for available widgets to download.

Jul 28, 2010 at 3:25 PM
If you know PHP, it might be good to peruse the WordPress codebase and see how they've implemented it; not that their way is the best way, or even a way that you'd want to go, but it is a working implementation of your idea. I do know that they use a specified format in the README file that's used to determine versions, credit authors, etc. In recent versions, they allow you to actually install and upgrade from within the application; however, they do this using a reverse-FTP technique that I've not found particularly useful, as I don't have an FTP service running on my servers. Using .NET technology, it seems like it would be possible to pull it (from the wanting webserver) as a package, then install it. The downside is that you've got to allow that process write permissions on an executable code; this means that any compromise on your webserver has the ability to place code that can further compromise it. In practice, WP hasn't had a big problem with that; however, I agree with Ben. Maybe some of this could be assuaged with big disclaimers that certain extensions have not been verified; but then, verification takes people to really dig into the code and spot vulnerabilities. There's also the issue of compatibility with different versions. Version x of the plugin may work with version 1.6.1 of BE, but may not work in version 1.7. The responsibility for fixing this lies with the extension developer, but most users would just see that "the upgrade broke my blog." The BE implementation would need to (if it doesn't already) execute the extensions in a way that it can detect and disable extensions that stop working, so that a misbehaving extension doesn't show the "oops" page. I've worked with WP for over 4 years and PHP for over 5; I'd be happy to help you in any way I can. I'm currently working on a WordPress BlogML Export process that will allow users to migrate from WP to BE easily; once it's done, I have at least three blogs that I'll be using it on. :)
Jul 29, 2010 at 1:51 AM

The other thing that I was thinking like Ben to make it easier is to create a basic table that has like Widget Name, Description, URL to site, icon, tags, contact information to have it listed on an extension page that you can search and see most recent additions etc... through the BE control panel. This way people are responsible for where they want to host their plugin and it would link to their download site. This would be significantly easier and not much development.  With a disclaimer that there is no responsibility if widgets don't work or crash your blog site.

I am going to do a quick and dirty mock up see if it would be workable to use an implementation of BE to manage the user accounts, roles for editing permissions, to have a nice repository blog.  Hopefully by the end of the weekend at least something a little rough for some feedback.

Coordinator
Jul 30, 2010 at 2:43 PM

Jason, it sounds like this could work.  Look forward to seeing anything you have the time to put together.

Jul 30, 2010 at 7:27 PM
Edited Oct 24, 2011 at 9:37 PM

I am also looking forward for this.  Sounds like a great idea Jason.   I would like to help if you need it.  I could test them out if needed.


Java Blog

Aug 4, 2010 at 3:51 AM

Okay, I have been working on this and have a decent starting point on the widget system. Here are the additions I have added.

  1. Added the ability to sign up for a user account. It ensures that the username and email are not currently used in the system.
  2. Added an additional role named (Widget Developer). This gives permissions only to add entries, edit their own entries and update their profiles.
  3. Only allow a system administrator to add Widget Categories and disable comments.

Here is the link to a demo site I setup. http://racheljason.com/1/demo/ . You can request an account on the Login page there is a New Account button.

Here are some things that needs to be done still that I can think of right now.

  1. Add either a recaptcha or email confirmation system when signing up to stop automated systems creating accounts.
  2. Customize the home page to not look like a normal blog site.
  3. Create an widget admin tab to be able to search the widget site either by rss feed or another method and make it easier for bloggers to find and add widgets to their blog.
  4. Add a profile page for people to see information about the developer. I think this might already be in the code but I don’t know how to access it.

Feedback is appreciated.

Ben, if you have an idea on whether to host the custom on a new codeplex site or create it as a branch of the current project I would like your feedback.  It would be nice to utilize a issue/feature system to implement this component.

 

 

Coordinator
Aug 5, 2010 at 7:28 AM

I created an account at your site.  I'm guessing I got put into the new Widget Developer role.  Right now I just have the Add Entry and Profile tabs.

So it looks like your plan is to add a new tab -- "Widget Admin" that widget developers could access.  The main process of being able to find existing widgets and submit your own widget would be done on this tab?  If so, that seems logical.

One option would be to create your own CodePlex project for this.  Later on, we could bring the code into BE.  But with the new Mercurial source code control system BE is now using at CodePlex, probably the better option would be to create your own Fork on the Source Code tab.  You can then make all the changes within your own fork.  Once it's complete, or in a usable state, you can submit a "Pull Request" which allows any of the BE team members to take the code from your fork and merge it into the main BE code repository.  Rtur has a good writeup on this process, which explains the basics.

Aug 7, 2010 at 1:38 AM

When a new account is created I have it put into the widget developer role.

I was planning on when someone creates a new post (adds entry) that would be like adding a widget to the repository under their account.

Blog administrators would be able to see a Widget admin panel on their blog that would feed from the widget repository rss feeds to search for and find widgets to use on their blog.  It will also link to some details on how to add a wdget to the repository. 

I created a fork but the source code that it brings down to my computer is different.  I will play around with it and will more than likely go that route once I figure it out.  I also bumped your account you created up to an administrator so you can see everything.  Hopefully this weekend I can work on this more.

Jason

Coordinator
Aug 9, 2010 at 2:42 PM

Sounds good, thanks for the status update.

I haven't tried created a Fork myself.  Maybe the code in your Fork is the latest source code check-in that can be found on the Source Code tab above.  Or it could be from the last stable release -- 1.6.1.  You might want to check the BE version if you're not sure.  The BE version is shown in the footer on the Standard theme, and is also shown in the control panel.

Aug 25, 2010 at 6:19 AM
Edited Aug 25, 2010 at 3:50 PM

Do you know if there is an RSS feed that will show like the top 10 categories with posts?  I am trying to get into the code and see how the rss feeds are created but it is taking awhile and thought someone might know.  I would like to pull the data in dynamically from RSS feeds for the plugins page.  I am able to pull in the xml for the main rss I can see but need to create a few more and was hoping it was fairly easy.  I will upload my changes to the fork once I figure this out.

Edited:  Do you think it would be better to implement this with a webservice?  I am looking through the api and it would make it really easy to make this data available.

Jason

Aug 26, 2010 at 7:47 AM

Hey Ben,  I created a widget.asmx service in the api directory.  I updated the changes on the widgetrepository fork I am working with.  I have also uploaded the service to my blog if you want to see it work.  http://racheljason.com/1/blogs/api/repository.asmx

I have one question about this task.  Do you know where the instance of the blog for the widget store should be hosted?  I would prefer if it was a subdomain of your main site http://www.dotnetblogengine.net/ like http://plugins.dotnetblogengine.net or something like that.  I am really close to being able to have at least a good realease of the plugins page for the admin section on blog. 

Also if you know somone who is good at designing layouts of home pages it would be nice to be modified as well for the custom version of the blog to focus on finding the latest plugins and the most popular by rating etc...

Thanks.

Jason

Coordinator
Aug 26, 2010 at 12:31 PM

Hi Jason... I logged in and am looking to catch up.

My understanding (and please correct me if I'm wrong) is that each new Post will represent a new widget, extension, etc.  The type of item is represented by the Category.  I see 3 categories on your site -- (a) Extensions, (b) General and (c) Theme Widgets.

I added a new test post for a Theme Widget.  Repository.asmx will list all the categories -- in this case 3 of them.  The repository.asmx you linked to here looks like it contains the categories for your personal blog (movies, politics, etc).  That respository.asmx is under your /blogs/ site -- it doesn't contain the categories from your /demo/ site.  I'm guessing that ultimately the BlogCategories web service at repository.asmx is going to display the first set of categories (extensions, general, theme widgets, etc).

Is the plan that someone might actually go to the host site (e.g. dotnetblogengine.net) to see the items, and/or post a new item?

Or is the host site simply a repository that only exposes web services, and each person can view the items and/or post a new item via an interface built into their own BE blog in the control panel?  I'm guessing this is what you're shooting for -- it's the "plugins page" you mentioned.

Probably this can be hosted at dotnetblogengine.net in some form.  Either as a separate blog application, or it can possibly be integrated into the existing blog running there.  Something I'll give some thought to.

Thanks for the update.

Aug 26, 2010 at 8:14 PM

Hey Ben, 

Each new post would represent a plugin of some sort which would be categorized by categories and provide a link to where their plugin is hosted. 

Tags would be added by each plugin developer on their posts.

I believe it would be good for people to go to the host plugin site (e.g. dotnetblogengine.net) to learn about new plugins and search and find ones that are available.  It would also be helpful for people thinking about using blogengine as their blog app to be able to browse and see everything that would be available to them for plugins.  All of the links in the plugins admin panel would open a new window going to plugins area on blogengine site to get additional information on the plugin and or write comments and questions to the developer of the plugin.

I want to create a few web services including Categories, Top Rated plugins, Newest plugins, Tag Cloud and quantities, featured plugins and their ratings,Total plugins available:  all of this would be displayed on the Plugins admin panel. Any other suggesstions are welcome. 

I updated the demo site with the fork that I am working off of.  It just took awhile.  I deleted the user accounts that were created.  If you want you can create a new account and I will move you to admin so you can see the plugins tab on the admin panel I am talking about.  I only have 2 areas currently (not fully funtional yet).

http://racheljason.com/1/demo/

http://racheljason.com/1/demo/api/repository.asmx

Jason

Nov 18, 2010 at 2:56 PM

Hello Jason,

 

I would like to get involve with this too.

 

But, when I went to the website http://racheljason.com/1/demo/

I am getting this error: The page cannot be displayed because an internal server error has occurred.

 

Is this still an active project?

 

Thanks,

 

Brian Davis

 

 

Nov 18, 2010 at 5:39 PM

Ben had advised me that Microsoft was going to be helping provide some resources for a repository so I stopped building because I didn't want to build something that wasn't going to be used.  If this project does move forward in the future I will let you know. 

Ben,  do you have an update on how the progress of a repository for BlogEngine?

Coordinator
Nov 18, 2010 at 6:25 PM

I don't know all the details yet, but this existing site, blogenginetheme.com is going to be promoted as the go-to location for BE themes.  I think there are plans to re-do part of the site as well.  The site has themes, but also widgets and extensions too.

In the control panel, next to the Theme dropdown list, we have a "Download" link (which might have been there from before, cannot remember).  That link currently goes to this page, which has a link to blogenginetheme.com (among other links for how to create a theme, etc)  We should probably make the blogenginetheme.com link on that page more prominent.

So it's not an automated method of installing the themes, like we were discussing.  But the fact that there will be this "official" site that has as many themes as possible is a good thing.

Also, last I heard, there are some people working on adapting a bunch of new themes for BE.  Having more of them will definitely be nice.