Last modified by sbrickey on 11/19/2013 10:59 AM
Back in Kooboo v3, one of the types of fields that could be added to a content type was a MultiFile field... It's effectively the same as a File in that it's just a place to store binary data, except that the MultiFile allowed you to store groups of like files. I (generally) love the MultiFile field, and use it regularly... in fact, I have an 'Images' field that is MultiFile, which I use to store any images that will be included in the post. The reason I prefer the MultiFile, is that the files are actually stored with the specific post. Storing the contents in this manor makes management of the post and related files much simpler.
Kooboo decided to deprecate MultiFile in v4 (by default), recommending that separate lists be used in their stead. But the functionality is only minimally removed, and can be restored by adding back one simple file. Koobooo has in fact made the file available, to assist those that are upgrading from v3.
Path of the file: ~/CMS_Data/ContentType_Templates/Controls/MultiFiles.cshtml
Contents of the file:
The file was supposed to be included in the 4.02 release, but I haven't noticed it myself... easier to just add the file real quick.
Last modified by sbrickey on 6/5/2013 10:41 AM
My website doesn't recieve many structural changes. Generally speaking, I'm content with most of what I've got.
Recently though, I realized that I could improve the usability of my blog administration. (so the changes I'll cover will never be seen by anyone else)
One of the things that really motivated me to choose Kooboo as my new blog platform (formerly SharePoint) is its support for on the fly content editing. Generally speaking though, this applies more to existing content than the new content (the new versions of Kooboo have made improvements in this area).
When I'd designed the blog (content structure, URLs and page layouts, etc)... I knew that I'd want to be able to add content on-the-fly as I'd done with my previous blog platform, without needing to go through the Kooboo admin menu (which requires several navigational clicks, and sometimes had formatting issues).
So the initial Kooboo design includes admin links that let me add content straight from the page (assuming I'm logged in). But the Blog page does not show future posts.
Generally speaking, this led me to two approaches.
- First, I set up an admin page that let me view unpublished and future posts. I could add my future post, and edit it from here. But I didn't like the extra click, so unless there was reason to use a future post (like a desire to avoid several posts on the same day), I didn't use this very often.
- Secondly, and my preference, was to just create the post and date it for immediate release. Since I am a big fan of "save often", I'd often create it with no content (usually just a filler like "pending")... then I would just load the page and edit the content. Depending on timing, it would be easy to watch as I write the entire post just by refreshing the page (hopefully the WayBack machine never picked up on this :)).
I realized that my usage pattern was predicated on creating a post and editing it with as few clicks as possible. Click to create the post, click into the post, edit the content. The only reason I wasn't using future posting (and also revealing the entire writing process, as well as revealing incomplete information) was because future posts were only accessible via a second page (click). And the only reason they were on the other page was because they shouldn't be public.
But page contents are dynamic. And Kooboo gives me a great development experience. Surely something can be done.
I ended up copying the blog listing view (analogous to a web part) into a "future blog posts" view... wrapped the entire thing in a security check (which I'd already created for other uses)... and adjusted the CSS so the future posts were somewhat transparent (makes it look like it's got a translucent sheet over it). Then I add it to the blog page above the published posts.
So now, I can create the posts... they show up on the same blog page that I created it from (just a quick postback to refresh the page with the new content)... click into the post (future posts are available to anyone... I never felt a need to "secure" them... the URL is simply unknown until it hits the publish date)... then edit the post.
Once done, I can go back to the blog page, and see the future posts just as they'll be shown when they are eventually published (in fact, they reuse most of the CSS classes)
Last modified by sbrickey on 2/5/2012 9:10 AM
So I just finished spending about 3 hours moving content from my "following" page into a structured list. I did this primarily because I wanted to make an RSS Aggregator.
Initially, the page was simply content... I could edit it, move things around (change order), or do generally whatever I wanted, and usually pretty quickly (cut/paste, etc).
But I'm aware that most blogs (not mine... i'll probably get around at some point) provide RSS links, and it'd be nice if I could aggregate them on my site, so I could see what's new all from one place. SharePoint Server has a web part ("RSS Aggregator") to do the same thing, I wanted it here in Kooboo.
So I set about. The work consisted of the following tasks...
1. Create a content type and list for the blogs I want to include. Includes a category (individual or team blogs), sort order (within each category), description, link to the blog, and link to the RSS feed.
2. Recreate the basic list of blogs (aka the blogroll). This was real quick since it was pretty much copy/paste from my tag cloud. Adjust the CSS a little.
3. Create a view ("RSS Reader") which takes the URL of an RSS Feed and path to an XSL file. Transform, and output to the page. Turned out to be a lot easier than I'd expected, thanks to the overloads of the XslCompiledTransform.
4. Create a view ("RSS Aggregator") which takes the RSS feed links from the blogroll list, and pipes the data to the RSS Reader.
5. Create the XSL file for the RSS Schema. Thankfully, google found me a good starting point, and Wikipedia has a good sample (well formatted, etc).
After that, just fix the CSS a little to keep readability good.
Now, I say 3 simple steps... that's because I don't count the first two... I should've started them as a list to begin with, but I wasn't sure how they were going to end up. I just wanted to keep track of the blogs that mattered to me.
I was disappointed that I was bumping into file lock issues a little more often than I'd like (which slowed down my ability to make changes as fast as I'd like)... I assume it's something to do with the code (since I ran into the same error trying to use FTP instead of the Kooboo management interface), though I'm not sure why... hopefully the feature request I subimtted for Kooboo will help that.
So all said and done, a small amount of time resulting in effective and reusable code. Well worth it :)
Last modified by sbrickey on 1/22/2012 5:05 AM
One of the reasons for choosing Kooboo was its (default) use of XML files to store content. While I understand the benefits of an RDBMS backend, for the size of my website I prefered a simple storage option. As such, I focused my migration effort on generating an XML data file using Kooboo's schema. I chose this because I wanted to use PowerShell for the migration (lightweight, available on any workstation I'd be using, etc), and the support for XML files within .Net is pretty good.
Last modified by sbrickey on 1/1/2012 6:29 PM
So this post will focus on how I customized Kooboo for my liking.
- Out of the box, Kooboo's SampleSite includes some Articles... I am not writing this as a paper, so I can toss it all.
- Next, I need to add my own content types... blog post, code block, etc.
- I also found that Content Folders in Kooboo can be nested, and each nesting can redefine the content type. This means my content folders can match the UI hierarchy (yay).
Layouts (aka masterpages)
By default, Kooboo includes a two-column layout. With little-to-no effort, I can copy/paste and adjust this into a one-column layout. I may at some point add some extra two-column (right side vs left) or three-column layouts, but I'm content at the moment with just these two options.
At this point, the layouts have a bit of redundancy that I want to clean up.
- First up, the sign-in/out... too much code here... I want a simple one-liner that I can include anywhere, and handles the logic of whether I'm logged in or not, what it shows, etc... I also ended up splitting out the logic code (am I signed in or not, what gets shown, etc) from the Login form (username/password), though this is less significant.
- Second, the search box. Same as the sign-in/out, I want the search to be a simple one-liner.
- Now that the header's components are simple one-liners, I can refactor the entire header... this includes the site's name and logo, search box, menu, etc... by default, the sign-in is also at the top.
- Similarly, let's address the footer, including copyright, engine link (since I want to promote Kooboo), and sign-in button.
So in the layouts, I've already described some of the views. I choose to use folders/namespaces to logically group some of the views. Here are the views so far:
- Login.Status - Log in / sign out buttons, logic to distinguish between them
- Login.Form - When logging in, this is the form which is displayed
- Common.Search - the input box, button, and URL code
- Common.Header - Site logo, name, top nav menu, and added later: the breadcrumb trail
- Common.Footer - copyright, link to Kooboo, and login status
The old site has an iframe with a link to Artimis (which shows local traffic conditions)... so I'll create a view for that as well.
I spent a bit of time figuring out what I wanted as far as navigation goes... For a while, I was strongly considering a Windows Explorer-like menu (which combined the look and feel of a breadcrumb trail, with a list of peer and child nodes), since I thought it would provide quick navigation to deeply linked content. I finally decided (at least for now) that a breadcrumb trail is sufficient, and I will provide the nodes on pages, and try to minimize on the depth. But this also means I need a breadcrumb trail. I also found that I need a bit of custom logic to ensure that the trail showed links or labels appropriately, given that I use pages and URL routing differently on some of the pages.
Finally, I have views for content... things like a single blog post, a list of the recent blog posts, tag cloud, and archives.
Finally, the data... I'm still using the basic XML data provider, so I just need to write an XML file for the content.
I used a PowerShell script, which queried SharePoint using the Client Object Model, then created an XDocument to generate the output.
Since the titles have illegal URL characters, the URL routing uses the UserKey... I started with a simple function to replace illegal characters with underscores, but found that I wanted a little more control... I'll post the whole script soon enough.
I'll post actual code snippets soon enough.
Last modified by sbrickey on 2/1/2012 11:46 AM
So you may have seen signs... i've been (very slowly) moving and consolidating websites to this new URL and site engine.
After about a month looking and testing, I've decided and settled on Kooboo as my site engine. My first websites were plain HTML and Classic ASP (some even had an access DB... ooh, ahh). For the past few years though I've been using SharePoint Services/Foundation, and it's been good.
So what changed?
I'm looking at external hosting, since I'm a little tired of the maintenance involved with my 2 Virtual Servers, File Server, a dozen VMs, and custom firewall rules. I've liked the idea of hosting myself because I always kept backup copies, but the web hosting sites these days provide a lot of nice options as well.
But let me tell you, SharePoint hosting is expensive (for a personal site).
My web hosting (via Arvixe) is less than $10/mo... no bandwidth concerns, no disk space concerns.
SharePoint would've cost me at least $30/mo... for maybe 5gb of disk space. I looked into a bunch of options, including cloud servers... but since SharePoint wants at LEAST 4gb of memory, VM hosting gets expensive too. Throw in some VPN routing (I was hoping to configure a WAN between two VM hosts and here, split my AD tree, etc) and the costs went up even higher... suddenly, the cost of running things at home was looking good again.
Further, with my home install, I am a SharePoint farm admin... full access to central admin, install anything i want, admin. With hosted options (Office 365 or others), I'm a site collection admin. At best I can play around in the sandbox API.
So I looked around at some other CMS options.
So there you have it.
I plan to write more, including the (PowerShell) scripts I used to migrate the content, and the code I use in my data views... but for now, at least the blog is no longer in post limbo.