Joined Subviews with Linked Datasources in SharePoint 2010

I recently completed a project that involved joining a list (Appendix A) and a document library (Appendix A documents). Each document, when added to the library, was associated with an item from the list. There were three document types and each item in Appendix A needed to have 3 matching documents in the library. The project administrators needed a quick way to scan for missing documents.

The obvious solution was to put a data view web part on a page with a linked datasource and a joined subview (displaying all the documents associated with each list item).

I was going for something like this:

A report showing items from the list and their associated documents

I figured it should be fairly easy, considering I already had a lookup column on the Appendix A Documents library, linking it to the list.

But, you know, this is SharePoint. It’s never quite THAT straightforward, right? Look what happens when you try to do a joined subview on your lookup column:

The look up column adds extra information - so no match!

The lookup column adds extra information – notable the ID of the item, followed by a semi-colon and a # sign.

Now, if you want to be an XSLT ninja and do some string manipulation, you can get around this issue the hard way. But, the easy way is to just go back to your original lookup column, and use the new SharePoint 2010 feature to “Add a column to show each of these additional fields.” Just make sure that whichever column you’re adding and joining is unique. I used the ID in this example, as that is always unique.

Include A Second Unique Column

Now, go back to your joined subview and select your additional column. Voila!

Correctly Linked Columns

Modifying the SharePoint 2010 Preview Pane View Style

Out of the box, SharePoint 2010 offers several styles that can be selected when creating a view of a list or library. One really useful style is the Preview Pane. If you have a list with a lot of columns, the Preview Pane style is great for creating a vertical view of the data, avoiding the dreaded horizontal scroll. If you’re not familiar with the Preview Pane, Microsoft has a quick screen cast that shows how to use it.

Unfortunately, out of the box, there’s no way to identify which column should be used in the pick list – that list of items on the left side of the preview pane. It defaults to the title column, and there’s no way in the web-based tools to modify that. So, what happens if for some reason you’re not using the title column in the intended manner? Well, you end up with something like this:

A Not Very Functional Preview Pane View

Not so great, right? If you Google around for a solution, you’ll find options such as using a workflow to update the title column with the data you want when an item is added or using a CAML editor tool. Hm…. No thanks.

Turns out that you can make it work with a little help from SharePoint Designer. Fire up SharePoint Designer 2010. Load your site. Navigate to your list. In the Views module, click the preview pane view that you created. (If you haven’t created one, watch that screen cast and create one first.)

Click the Preview Pane View to edit it

Now that you’re in edit mode for the Preview Pane style, do any of the typical tweaks you might do on any view – change the sort order, the paging, add or remove columns. Do everything you might want to do using the Ribbon options before we get to this next part. It makes life easier.

Now for the fun stuff.

Find either the title or the words “(no title)” in the left column. Highlight either the title in a row of data or the “(no title)” words. Right click, and select “Edit Formula.”

Highlight the words to replace and select "Edit Formula"

A pop-up window will open where you can select another column of data, enter static text, or use any number of formulas to generate the text you want to use. I concatenated two columns.

Using a formula to concatenate columns

If you have some rows of data with titles and some without, you’ll need to repeat this process for both types of columns.

So, what’s happening behind the scenes is that a new XSLT template is being added to code view. It’s called the “LinkTitleValue.LinkTitle” template, and it determines what data is being used for the link to the item. The template looks like this:
<xsl:template name="LinkTitleValue.LinkTitle" ddwrt:dvt_mode="body" ddwrt:ghost="" xmlns:ddwrt2="urn:frontpage:internal"> <xsl:param name="thisNode" select="."/> <xsl:param name="ShowAccessibleIcon" select="0"/> <xsl:variable name="titlevalue" select="$thisNode/@Title"/> <xsl:choose> <xsl:when test="$titlevalue=''"> <xsl:value-of select="concat($thisNode/@Chapter_x0020_Name, ' - ', $thisNode/@EIN)"/> </xsl:when> <xsl:otherwise> <xsl:choose> <xsl:when test="$HasTitleField"> <xsl:value-of select="concat($thisNode/@Chapter_x0020_Name, ' - ', $thisNode/@EIN)" /> </xsl:when> <xsl:otherwise> <xsl:value-of select="$titlevalue" /> </xsl:otherwise> </xsl:choose> </xsl:otherwise> </xsl:choose> <xsl:choose> <xsl:when test="$ShowAccessibleIcon"> <img src="/_layouts/images/blank.gif" class="ms-hidden" border="0" width="1" height="1" alt="{$idPresEnabled}" /> </xsl:when> <xsl:otherwise></xsl:otherwise> </xsl:choose> </xsl:template>
Save your file and test it. Looks great, right?

Title Successfully Replaced

You have now successfully replaced your title with your preferred information and it’s linked to the item. It also has an ECB menu attached to the item.

What happens if we use the ECB menu to view or edit the item? Oops! The Javascript gets confused and it drops out the text we just spent our time putting in there!

Oops! Where'd our text go?

I haven’t dug into why this is happening, and I’m sure someone else will do that. (Leave a comment if you figure it out!) But, I do have a workaround. One more step. I find this step easier to do back in the browser. So, save and close SharePoint Designer. Fire up notepad and type the following:
<style type="text/css">

.s4-ctx {
display:none;
}

</style>

Save it as a text file and upload it to your site. Make note of the location. (Right click and “copy shortcut.”) (I used the “site assets” library.)

Navigate to your view. Select Site Actions -> Edit Page. Add a Content Editor Web Part and edit the web part to add a Content Link. Paste the shortcut and click “Ok.”

Link to your text file from the content editor webpart.

Save your file. Your “title” pane will now have the data you want, minus the ECB menu. Hovering over the item will load it in the preview pane. Clicking it will load the pop-up window for viewing or editing the content. One caveat, and Microsoft insists it’s a “feature – not a bug,” is that you’ve now lost your view menu in the breadcrumbs. (Glyn Clough provides more information about this issue. And Pentalogic has a free solution that fixes the issue on all pages, but may be a bit “nuclear,” as they put it.)

The View Menu disappears on view pages that have been edited.

The workaround for that is to edit the page in SharePoint Designer to add your custom css. However, this customizes the page. You’ll have to choose whether you’d rather deal with customized pages or an alteration of the the UI. If you want to customize the page and retain the breadcrumbs, remove the Content Editor Webpart and save your page. Fire up SharePoint Designer again. Navigate to your list. Right click on your Preview Pane view and select “Edit File in Advanced Mode.”

Edit File in Advanced Mode

Note: If you do not have the Edit File in Advanced Mode option, it is because your site collection or farm administrator has restricted the use of SharePoint Designer in your environment.

Once your view loads in advanced mode, switch to code view and search for “PlaceHolderAdditionalPageHead.” Add the CSS we had previously added via the Content Editor Webpart to that tag, like so:

Add CSS Via SharePoint Designer

Save your file. Voila – you now have customized title pane with no ECB menu and have retained the view selector breadcrumb.

The other major advantage of using this method versus the Content Editor Webpart is that the CSS will render in the head of the page, where it belongs. However, if you do choose to use this approach, make sure you are tracking what pages you are customizing so that when it comes time to upgrade you’ll know which files need to be double-checked.

12 Comments

by Deanna on November 1, 2011 • Permalink

Posted in SharePoint 2010

Tagged SharePoint 2010, SharePoint Designer

Posted by Deanna on November 1, 2011

http://deannaschneider.wordpress.com/2011/11/01/modifying-the-sharepoint-2010-preview-pane-view-style/

Calendar Overlay – a simple SharePoint 2010 OOTB Master Calendar

A master calender is a common request for team sites that have sub-sites. If you are running SharePoint 2010, there’s now a built-in way to do a roll-up master calendar using the calendar overlay feature.

The Steps

At the site on which you want to display the master calendar, either create a calendar list or use the existing team site calendar.
On the Calendar tab in the ribbon, click Calendars Overlay.
Calendar Overlay Button on the Ribbon
Click the New Calendar link to add a new calendar.
Click the New Calendar Link
In the next screen, you will need to provide information about the calendar you are adding (name, description, etc.) plus the URL of the site that houses the calendar. *(Note that the URL should be to the site, not to the calendar itself. SharePoint will find all the possible lists and views once you click the Resolve button after entering the URL address.) If the site has multiple calendar lists or views, you will need to select the one you wish to overlay from the drop down boxes. Check the box next to Always Show. Click OK.
Enter Calendar Information
Repeat Steps 3-4 for each calendar you wish to add.
When all the calendars are added, click “Ok.”
Now all the calendars will show on the main calendar.
Combined Calendar View

The Caveats

You knew there were some, right?

You can only include 10 calendars.
You only have 8 colors to choose from.
You can include calendars that are above the site of the “master calendar” and that are siblings to the master calendar, and even that aren’t in the same site collection (Yay!). But, if the person visiting the site doesn’t have permissions to view the other calendar, you’ll get this error:
Permissions Error

Oops. So, be careful with permissions on your overlays.
If you connect to Outlook on the main calendar, it will not include the overlaid calendars.
If you add a web part of the master calendar to a page, it will not include the overlaid items.
You can overlay lists that are not of the calendar type, as long as they have a calendar view. (This isn’t really a caveat – just a good thing to note.)

You can also overlay Exchange calendars. Sharad Kumar has a good blog post on how to aggregate Exchange Appointments into a Calendar View.

2 Comments

by Deanna on September 28, 2011 • Permalink

Posted in SharePoint 2010

Tagged SharePoint, SP2010

Posted by Deanna on September 28, 2011

http://deannaschneider.wordpress.com/2011/09/28/calendar-overlay-a-simple-sharepoint-2010-ootb-master-calendar/

XSLT XML Dump

Ever wanted to dump the raw XML from a webpart? It’s easy. Just change the XSLT to the following for nicely formatted XML.

<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”>
<xsl:output method=”xml” indent=”yes” />
<xsl:template match=”/”>
<xmp>
<xsl:copy-of select=”*”/>
</xmp>
</xsl:template>
</xsl:stylesheet>

You can save this as an style sheet in your styles library and apply it to any web parts that allow that to get a dump of the raw xml.

Displaying the Document Icon in a CrossList SharePoint 2010 DFWP

Once again, I’m finding that the DataForm Web Part (DFWP) acts slightly differently when you’re using it as a roll-up. And, once again, I’m finding great info out there on Marc Anderson’s blog about what I want to do. But, once again, it needs a slight tweak to work with a roll up.

So, if you want to include the document icon in a DFWP when you’re using it in CrossList mode with recursion through sub-sites, instead of this:
<img src="/_layouts/images/{ddwrt:MapToIcon('', ddwrt:GetFileExtension(string(@FileLeafRef)))}" alt="Type" />

You’ll need this:
<img src="/_layouts/images/{ddwrt:MapToIcon('', string(@DocIcon))}" alt="Type" />

DocIcon will need to be included in your FieldRef section of your SelectCommand:
<FieldRef Name="DocIcon"/>

5 Comments

by Deanna on May 18, 2011 • Permalink

Posted in SharePoint 2010

Posted by Deanna on May 18, 2011

http://deannaschneider.wordpress.com/2011/05/18/displaying-the-document-icon-in-a-crosslist-sharepoint-2010-dfwp/

Linking to Documents with a Roll-up DataForm Web Part

Say you want to make a roll-up webpart of all the word documents in a bunch of subsites on SharePoint 2010. Well, you could use the Content Query Web Part and modify the XSLT to filter out everything but word documents. Or, you could fire up SharePoint Designer and pull out the handy-dandy DataForm Web Part. There’s really nothing new going on here that hasn’t been covered in other blogs. A great resource for getting your head wrapped around the crosslist dataform webpart is Marc Anderson’s blog. The thing that confuzzled me, though, is that when you switch the datasource from a single list, to a recursive crosslist, your data is returned with a number, followed by a semi-colon, followed by the pound sign, followed by the actual data that you want. Argh. Not good, and more Google-spelunking led me to Laura Rogers (@wonderLaura) who pointed me in the right direction on this issue. She’s linking to list items, whereas I’m linking to documents themselves. If you want to link to the documents themselves, it’s a fairly minor change though. Just change this:

{concat('/',substring-after(@FileDirRef,'#'),'/Dispform.aspx?ID=',@ID)}

to this:
{concat('/',substring-after(@FileDirRef,';#'),'/',@LinkFilename)}

(Note, be sure to add the LinkFilename to your selected fields.)

Voila – the name of the document linked to the document itself, no matter which subsite it’s found in.

2 Comments

by Deanna on May 16, 2011 • Permalink

Posted in SharePoint 2010

Tagged DFWP, DVWP, SharePoint2010, SPD

Posted by Deanna on May 16, 2011

http://deannaschneider.wordpress.com/2011/05/16/linking-to-documents-with-a-roll-up-dataform-we-part/

WordPress Plugin Updates for WP 3.1

The following plugins have been updated (finally – sorry) for WP 3.1.1:

Blog Topics

Management menu moved to network admin
Aggregation terminology changed to “share/don’t share”
New sites default to not sharing
Notification added to site admin dashboard if site is not being shared
Sharing settings & notification settings moved to site admin -> privacy page
Bug fixed in setting the featured topic on network admin config page

New Blog Defaults

Admin page moved to Network -> Settings
Increased required version to WP 3.0 (people running prior versions will need to get older versions of this plugin out of the repository)

WPMU Default User Role

Moved admin menu to Network -> Users

WPMU Plugin Stats

Moved admin menu to Network -> Plugins

WPMU Theme Info

Moved admin menu to Network -> Themes

I think that the other plugins all work as expected in 3.1. If not, let me know.

5 Comments

by Deanna on April 19, 2011 • Permalink

Posted in Wordpress MU Plugins/Widgets

Posted by Deanna on April 19, 2011

http://deannaschneider.wordpress.com/2011/04/19/wordpress-plugin-updates-for-wp-3-1/

SharePoint 2010: Enabling Managed Metadata features

SharePoint 2010 comes with some wonderful managed metadata features. A quick Google search returns oodles of information about planning your managed metadata, adding managed metadata columns to lists and libraries, and using metadata navigation. What most of them fail to point out is that there are features that need to be enabled in order to use the managed metadata columns and the metadata navigation. Those features aren’t exposed in the UI in an out of the box configuration.

After much spelunking and blog reading and traipsing through the SharePoint root directory, I finally figured out how to enable these two features. Using the SharePoint 2010 Management Shell (PowerShell), you simple run the following commands:

Enable-SPFeature -id "73EF14B1-13A9-416b-A9B5-ECECA2B0604C" -Url <Site-URL> Enable-SPFeature -id "7201D6A4-A5D3-49A1-8C19-19C4BAC6E668" -Url <Site-URL>

The first one is the feature that allows the use of managed metadata columns for libraries and lists. The second one is the one that adds the metadata navigation options (and filter keys). Technically, the second feature isn’t listed as hidden and so it should show up in the UI. But, in my development install, it did not.

As a side note, when you read about features that aren’t showing in your UI, and you want to track them down, head on over to your SharePoint feature directory, which is typically:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES

Find the subfolder for the feature you are interested in, and find the Feature.xml file within. Open it with a text reader, copy the ID for the feature, and plug it into the commands above. Run it and you’ll be able to install any of the hidden features.

Hopefully this will save someone else a major search hassle.

6 Comments

by Deanna on June 4, 2010 • Permalink

Posted in SharePoint 2010

Posted by Deanna on June 4, 2010

http://deannaschneider.wordpress.com/2010/06/04/sharepoint-2010-enabling-managed-metadata-features/

Blog Topics Plugin – Take Two

Quite some time ago, I launched the first version of the Blog Topics Plugin. I hadn’t updated it since way back in September of 2008. Originally, it was relying on URLs with query parameters for all the portal aspects of the plugin. For instance, if you wanted to link to a page of blogs from one topic, you’d have a URL like, “index.php?topic=1.” It worked, but was less than elegant. So, for our own work, we modified the plugin to use permalinks, and added some additional features. The publicly released version was treated like the forgotten stepchild. Lots of people have downloaded it and I think lots of people have used it. It continued to work, but it got no love.

Not anymore. I’ve now completed a long overdue overhaul of the plugin. Now, all the portal aspects can be switched on and off in the widgets. And, I’ve provided some sample theme code to show how to use the permalinks (which are written into the theme, not the plugin).

So, let’s run through how the plugin works now.

Where to put the files

The plugin comes with a bunch of files. So, let’s break down where they go.

wp-content/mu-plugins
This is where the main part of the plugin should be installed. You need to install the cets_blogtopics.php and the cets_blog_topics folder (and the files within) in the mu-plugins directory. The cets_blogtopics.php file should be in the root of the mu-plugins directory or the plugin will not run.
wp-content/plugins
All of the widgets should be installed in the plugins directory and only enabled on the blogs on which you want to use them. None of these are required widgets, and you should only install the ones you wish to actually use. (See below for an explanation of each of these.) The following are widget files:
- cets_bt_featured_topic_with_posts_widget.php
- cets_bt_related_blogs_widget.php
- cets_bt_related_posts_widget.php
- cets_bt_topicname_widget.php
- cets_bt_topics_with_posts_widget.php
wp-content/themes
All of the code in the cets_blog_topics_sampletheme directory is, as the name suggests, sample theme code. To test it and play with it, install it in the wp-content/themes directory. You will need to enable it via Site Admin -> Themes, and then you will have to activate it on a selected test blog. You should install this AFTER installing the plugin and widgets. The theme utilizes the cets_bt_topics_with_posts widget and the cets_bt_featured_topics_with posts widget.

Now What?

Now you have the files where they belong, now what?

For a fresh install, the plugin will create a couple of tables in the database. The names will most likely be wp_blogs_cets_topic and wp_blogs_cets_topic_relationship. (The first part may be different if you’ve customized your database prefix in your WPMU install.) In previous versions, the table names used plural syntax. Plural syntax of table names is just one of my many pet peeves about the database design in WPMU (don’t get me started on that). There are a few new fields as well – description, slug, thumbnail, banner, and featured are all new in the topic table. (Thumbnail and banner aren’t actually in use yet.) If you already had the plugin installed, the upgrade script will attempt to alter the tables for you automatically.

By default, you must have at least one topic. The plugin installs with the default topic of “uncategorized.” If you’d like it to install with multiple topics, you can alter the code of the cets_blogtopics.php file on line 120 to add additional items to the array of default topics. Don’t worry – there’s a visual way to add and edit topics once the plugin is installed as well.

The Site Admin Features

Most of the site admin features of the plugin are found under Site Admin -> Blog Topics Management. The screen has three parts:

The first section is where site admins can add and edit topics, slugs, and descriptions. Slugs are what will be used for the portal permalinks. So, make sure that they contain no spaces, are short, and are human readable. The slugs are also used in the sample theme to create menu options. Think carefully about your slugs. The description is also used in the sample theme code, as well as in the blog topic name widget. Here’s what the administration screen looks like for this part:

Administrative View of Adding and Editing Blog Topics

The second part of the administrative interface allows you to set a featured topic. Again, the featured topic is utilized in the sample theme code and in the featured topic widget. A featured topic is not required to run the plugin, but is required for the featured topic widget.

Administrative View of Setting a Featured Topic or Uninstalling

The final part of the site admin interface is the uninstall feature. Clicking the uninstall link will remove the database and clean up the site options associated with the plugin. Manual deletion of files is still required.

There’s one other place where site admins can manage things. On Site Admin -> Blogs -> Edit, you can set the blog topic on a specific blog, and choose whether or not a blog is included in the aggregation bits (the widget & portal pieces). You’ll find these options in the Misc Blog Actions section of the blog editing page, and they look like so:

Blog Editing Features for Site Admins

Blog Admin Options

That pretty much covers what the site admins can do to administer the plugin itself. What about the blog admins? When a user first creates a new blog, she will find a new option on the sign up page, just under the Privacy section:

User View of Sign Up Option

It defaults to selecting the first item in the list, which is in alphabetical order. We’ve noticed that some people don’t really pay much attention here, and will just sign up with the default option, no matter what it is. Fortunately, there’s an easy way for blog admins to change the selected topic. In Settings -> Blog Topic, blog admins can change the topic of their blog and decide whether or not their blog should be included in the aggregation bits of the plugin.

Blog Admin View of Setting Blog Topic

The Widgets

Okay, so we have the plugin installed, and we’ve categorized our blogs. Now what? What do we DO with that information. Here come the widgets. There are five of them. Some are incredibly simple – and could be used on any blog in the network. Others are really meant to be a part of your root blog, acting as portal pieces. Let’s start with the simplest one first.

Blog Topics Name

The blog topics name widget (cets_bt_topicname_widget.php) displays the name and, optionally, the description of the topic. Like most of the widgets, it can also create a link to a portal page. In this case, if you follow the code in the sample theme, the portal page would display a list of all the other blogs that fall under the same topic. Here’s how it looks from the backend:

Back end view of blog topics name widget.

And, here’s how it displays data on the front end. If you elect to include the portal link, the topic name becomes the link:
Front end view of topic name widget.

Pretty simple, right? Yah, we don’t actually use this one, either. But, it was written, so I thought someone might want it.

Related Blogs Widget

The related blogs widget is a bit more interesting. It lists the top N blogs that are categorized under the same topic. This one doesn’t have any portal parts, so it’s very safe to use, even if you’re not implementing any of the portal pieces. The list will simply link to each of the blogs directly. Here’s how it looks on the back end:

Back end view of the related blogs widget

And here’s how it looks from the front end. (This example doesn’t list many blogs, since I was pulling these screen shots from my development environment. Clearly, you’d have a longer bulleted list in a production environment.)

Front end view of related blogs widget

Featured Topic With Posts Widget

The last two widgets are the workhorse widgets for the sample theme code. The first, the featured topic with posts widget, is fairly similar to the related posts widget, except for that instead of pulling the posts from the same topic as the current blog, it pulls the posts from whichever topic the site admin has set as featured. Again, you can determine how many posts to include and whether or not to include the portal links. Here’s what it looks like from the back end:

Back end view of featured topic with posts widget

And, here’s what it looks like on the front end:

Topics with Posts Widget

Finally, the last widget allows you to pull all the topics and a selected number of posts from each topic. Use this one carefully – it’s fairly resource intensive. We’ve done some experimenting with different ways to cache this puppy. But, haven’t figured out what the best approach is yet. You can also exclude certain topics. We use this widget in conjunction with the featured topic widget to show the featured topic’s posts in a separate area. And, as always, the portal links are optional. Here’s how it looks on the back end:

Back end view of topics with posts widget

And, here’s how it looks from the front end. That image in there? That’s part of the sample theme code. We’ll talk about that in a minute.

Front end view of topics with posts widget

The Sample Theme

Whew – are you still with me? One last section – the sample theme. First I have to ask you a favor. Don’t just install this sample theme and run with it, okay? I tried to dumb it down enough so as to not be too tempting. It’s pretty bare bones. It’s really meant as a guide – a way to help you understand how to make all this portal stuff work. Okay, that said, how does it work? Where’s the magic?

Most of the magic is in the rewrites.php file. Here’s where you’ll find the code to tell wordpress to take any URL that includes topic= or sitelist= and turn into a URL that looks like this:
topic/mytopic/
or this:
sites/mytopic/

And, furthormore, this code lets wordpress know to send those URLS to topic.php and sites.php, respectively. We get this code to run by including it in the functions.php file of the theme. The code for that is way down at the bottom of the rewrites.php file and looks like this:
//include the rewrites include_once dirname(__FILE__) . '/rewrites.php';

Of course, you also need the topic.php and the sites.php files as well. These are the files that display all the recent posts from a topic or all the sites from a topic. I’ve tried to add commenting in each of these files so you know what’s going on there. Note that, as written, these files also make a custom feed link. If you want to use that, you’ll need to also use the topicfeed.php file.

The home page is really just a widgetized template that utilizes the Topics with Posts widget and the Featured Topic with Posts widget. The widgets are called in home.php using the nifty the_widget() function. But, they could also be set via the back end widget tools.

My cohort in crime, and designer/css guru, Kevin Graeme, has added some nifty css tricks to the sample theme. Remember that image in one of the widgets up above? Well, that’s just a little css trick based on the slug of the topic. If you check out style.css right about line 281, you’ll see a comment that tells you what to do if you want to implement that trick. You’ll need to create a style for each of your topics. Easy peasy.

Okay, I think that’s it. Hopefully, this will help you figure out how to use all this stuff.

Of course, you probably want to know where to get all this stuff, eh? It’s here: http://wordpress.org/extend/plugins/blog-topics/

Enjoy!

65 Comments

by Deanna on February 22, 2010 • Permalink

Posted in Uncategorized, Wordpress MU Plugins/Widgets

Tagged wpmu plugins

Posted by Deanna on February 22, 2010

http://deannaschneider.wordpress.com/2010/02/22/blog-topics-plugin-take-two/

The Great Plugin Update

I’ve been spending the last little while updating plugins for WP/WPMU 2.9.1.1. All the plugins can be found here:

http://wordpress.org/extend/plugins/profile/deannas

Most of these are minor updates – mostly just testing the plugins and making sure they work on 2.9.1.1. There are a few significant changes:

New Blog Defaults

There was a timezone bug in this one. I think that’s fixed now. I also added support for the new settings in 2.9, including the auto-embed URLs and embed sizes and added the xmlrpc options (which aren’t new, I’d just never put them in before).

Embed RSS & Embed Gmaps

Have you read this post about not, under any circumstances, calling wp-load in a plugin? Yah, well, um, guilty. I will say that the use of wp-load was something that I stole from someone else. But, I suppose that’s not a good excuse, is it. Anyway, I’ve updated these two plugins so that they no longer do that. In so doing, I found a bug with CSS loading in Embed RSS. That’s fixed as well. The UI has changed a bit. Instead of using the tinymce window loader, I’m now using a hidden div a’la Viper’s Video Quicktags. In fact, major props go out to him as much of the code is stolen right from that plugin. Yay open source, right? Anyway, here’s what it looks like now.

The new pop up window for the Embed RSS button.

WPMU Theme Info

I added the show/hide code like the Plugin Stats plugin. Other than that, no major changes here.

WPMU Default User Role

I added the blog id number for all blogs identified as “/” in the drop down list of blogs for the site administrator. This is primarily only useful for domain mapped blogs.

Blog Topics

This one is a total rewrite. Look for a separate blog post on this coming soon.

All the rest simply got tested and their readme files tweaked.

9 Comments

by Deanna on February 16, 2010 • Permalink

Posted in Wordpress MU Plugins/Widgets

Posted by Deanna on February 16, 2010

http://deannaschneider.wordpress.com/2010/02/16/the-great-plugin-update/

Blah-de-blah-blog

Joined Subviews with Linked Datasources in SharePoint 2010

Modifying the SharePoint 2010 Preview Pane View Style

Calendar Overlay – a simple SharePoint 2010 OOTB Master Calendar

The Steps

The Caveats

XSLT XML Dump

Displaying the Document Icon in a CrossList SharePoint 2010 DFWP

Linking to Documents with a Roll-up DataForm Web Part

WordPress Plugin Updates for WP 3.1

SharePoint 2010: Enabling Managed Metadata features

Blog Topics Plugin – Take Two

Where to put the files

Now What?

The Site Admin Features

Blog Admin Options

The Widgets

Blog Topics Name

Related Blogs Widget

Related Posts Widget

Featured Topic With Posts Widget

Topics with Posts Widget

The Sample Theme

The Great Plugin Update

New Blog Defaults

Embed RSS & Embed Gmaps

WPMU Theme Info

WPMU Default User Role

Blog Topics

Categories

Archives

Meta

Follow “Blah-de-blah-blog”