One of the biggest nuances with master pages and page layouts in SharePoint is trying to delete them.  There are a lot of times when trying to delete a master page of page layout, you’ll get the following error:

So now what? You swear you’ve gone through and disconnected the file where it’s been used, and you’ve probably done it 5 or 6 times.  Chances are you missed one (or two) of those filed.  The easiest way to determine where the file is being used is to go to the Site Content & Structure page via Site Actions -> Manage Content and Structure. Once there, open the Master Page Gallery. You’ll notice the option for Show Related Resources. Select the file you’re trying to delete, and then select the related resources tab.  It will display a split view, the bottom half containing a list of all the pages/files using the select file throughout the site collection.

From here you can go to each individual page and disconnect the page layout.

I wanted to be able determine the subsite the masterpage was being viewed on and then reference a style sheet local to that subsite, generally that’s simple when your using a separate masterpage for each subsite….but I wasn’t.  The style sheet is located in at ‘/SiteAssets/styles/customStyles.css’ relative to each subsite, so placing that specific reference in the masterpage would unfortunately point to the site assets folder in the root site collection.  I didn’t want that.  So after some digging I found a pretty simple and slick solution using the $SPUrl syntax provided via the Microsoft.SharePoint.Publishing namespace.  The syntax to point to a subsite is as follows:

<link href=”<%$SPUrl:~site/SiteAssets/styles/customStyles.css%>” type=”text/css” rel=”stylesheet” runat=”server” />

The $SPUrl syntax allow for you to point to a location thats relative to the current location, so say my site collection is at www.uwsp.edu and the subsite I want to view is at www.uwsp.edu/admissions, when I pull up the root site( www.uwsp.edu) the masterpage will look for a custom style sheet at “www.uwsp.edu/SiteAssets/styles/customStyles.css” and when I pull up “www.uwsp.edu/admissions” the masterpage will look for a style sheet at ” www.uwsp.edu/admission/SiteAssets/styles/customStyles.css”.

It’s a really nifty solution, and allows for a lot of opportunities of customization.  This strategy can also be used for images, favicons, scripts, and other custom external links in a masterpage.  One thing to note, there is another $SPUrl tag as well ‘~sitecollection’.  Whereas ‘~site’ will point to the location of the current subsite, ‘~sitecollection’ will point to the root site collection a masterpage is located in.

But I’ve learned some pretty sweet things while I’ve been off the web, and I’m dedicated to posting these new discoveries.  It’ll probably only be about once a week or so until life quiets down a little bit more, but it’s a good start.     Sadly though, my work with WordPress has stopped for the time being so I don’t have much to say in that regard.  However, the same cannot be said for SharePoint.  I’ve got a few things I want to get posted up, especially now I know I’ve got one or two readers out there.

If all goes well, I should have a post up in about an hour or two.

Until then.

Last week I was given a project where the design of the website had been created in Photoshop and needed to be implemented into SharePoint.  The site design required vertical navigation.  For those who are regular SharePoint users, you know the Quick Launch can be used as a “make-shift” vertical navigation, but it can be very convoluted, difficult to manage, and a monumental task to style with CSS.  I didn’t want to deal with the consequences of the Quick Launch since all lists/libraries and etc. would be added to the navigation list upon creation.  So I dug  into the menu CSS and discovered a solution to create vertical global navigation.

My final working result, with some added colors and styles looks like this:



For the purpose of this tutorial I’m going to assume that you have some experience customizing the global navigation.

A couple quick notes before I walk through the steps.  The design I’m working with for this site utilizes custom div elements inside the master page, if you are not comfortable working inside the master pages then I recommend not attempting this.   Secondly, I’ve already placed custom wrapping div containers inside my master page to adjust the page layout.  Creating the vertical navigation will still be possible if you haven’t created any custom div elements, it will just take a little extra work on your part (it’s worth it though).  My master page construction places all the content, as well as the navigation, inside of “MSO_ContentDiv”.   If your navigation is still in the default location, you should still be ok; you’ll just have to do a little div manipulation to get it working.

So for this tutorial, I’ll assume you have some experience with SharePoint master pages and that you’ve worked with custom div elements.

So on to the navigation!

The first step is to place the navigation into a wrapping div to allow for easy modifications to the layout. You’ll need to find the default div that holds the navigation.  Look for a div of the following:

<div class=”s4-lp s4-toplinks”>

div #mainNav, .menu-horizontal, .menu-horizontal li.static, .menu-horizontal a.static, .menu-horizontal span.static{

width: 220px !important;

}

div#mainNav{

background:inherit; /* Set main navigation wrapper to inherit background color of parent div */

float: left;

margin: auto;

height: auto !important;               /* override default menu height */

vertical-align:middle;

}

.menu ul.dynamic {

margin: -25px 0 0 220px;

}

This new section houses a fair number of projects that I’ve been working on.  Currently, I have a list of 5.  Each of them are a little different in terms of techniques and practices used for them; but each are equally valuable to my experience.

I’m hoping to start posting a few times a week over the course of the semester, if time allows.

So until next time,

happy coding!

For my semester project I chose WordPress as my CMS of choice.  The primary decision for this was to create a way to showcase my knowledge and experience in WordPress.  Since there is a high potential that I will be doing a lot of WordPress development in the coming months I came to the conclusion that my personal site should exemplify such abilities.  As a “sub-category” of a WordPress project I decided I would create a custom WordPress theme, mainly because I want to have “my design” as the appearance of my WordPress site.  I’ve gotten quite partial to the original design I had on my website before winterim, and I wanted to implement that design into a WordPress site.  Since I couldn’t find a theme remotely close to the design I wanted, I was resorted to building my own.

As I expected, creating a custom theme is/was a very monumental task.  There are a lot of little pieces that need to fit together properly in order for the theme to function within the site.  As such, this played into the overall structure of my files.  There were of course a certain number of files that needed to be included in the theme structure in order for it function properly.  But, there are a series of files that aren’t necessary for a functioning theme.  However, I decided that I would create all functionality for my theme and include all the necessary files.

I decided to go with this choice mainly because “developers suck at designing”. Meaning, most FREE themes are created by developers and as such have a tendency to be boxy and not appealing.  Whereas on the other hand, themes created by designers don’t necessarily function all that well.  I’d like to think that I can consider myself both a developer and a designer. Now I’m not saying I’m a great designer, but I do understand and appreciate design so I keep it in mind when I’m developing.  I think this helped a lot in my overall theme construction.

The main aspect of this theme that I take pride in is the implementation of CSS3.  It was an interesting experience trying to get CSS3 to work properly with everything I wanted, mainly for browser reasons.  Originally I was going to lack support for Internet Explorer, however I decided against it.  Making that decision proved interesting.  My finished design is primarily CSS3 (which I’ll explain shortly) and CSS3 is not natively supported in IE.  As such, I had to spend a large amount of time researching hack implementations for IE.  In the end I found a solution called “PIE”, which stands for progressive internet explorer.  Essentially, PIE makes IE compatible with CSS3 by using an htc script file.  I’m not entirely sure how it works, I just know it does, and it does it very well.  So if you were to look at my design in an IE browser it would look relatively the same, some features of CSS3 don’t work with this hack (element rotation) so there are a few aspects that are off.  However, I was willing to make this compromise.

A second major decision I made in the design/construction of this theme was the ability for dynamic appearance changing.  With a WordPress theme there is the ability to create an admin menu for site administrators to interact with.  This admin menu creates a space for site administrators to make changes to certain areas of the theme, anything from design to functionality.  I took a big interest in this capability and decided to implement it into my theme construction.  The ending result is the ability for site administrators to significantly change the appearance of the site design.  However, that significance is still limited.  I created the ability for admins to change the color scheme of the site, as well as the font associated with the site title and description.

The font changing uses the @font-face css control by creating custom font types.  I pre-populated the template with font files and gave the theme options page access to theme.  The ending result is the ability to change the appearance of the site title via the click of a button.  I did this for 2 main reasons.  The first, and possibly the most obvious, is that it’s incredibly easy for me and saved me TONS of time.  Since the font is controlled with font type rather than images I didn’t have to spend any time creating banners in Photoshop.  The 2^nd is pretty similar to the first.  The site administrators can change the site title appearance with the click of a button; which means they don’t have to stick to one custom design, they can have options, and options are a good thing.  Options equal dynamic content and dynamic content equals a reliable site; which yields happy users.

I’ve always been a fan of dynamic capabilities in a website, especially from an administrative standpoint.  It makes implementing solutions a lot easier and efficient.  In addition it’s a lot less complicated.  I’m very pleased with the way content management systems handle this aspect.  I haven’t worked a ton with Joomla! or Drupal, but as far as WordPress is concerned it’s handled very well.  As such it is really easy to implement custom functionality into the core installation.  This is a major aspect of a custom theme, and eventually is something I plan expanding more on with my theme as time allows.

I was really pleased with the capabilities of CSS3, since that was the major component of my design I spent a lot of time working with it.  To say the least, my theme doesn’t use images.  That statement has one exception though; the social media bar and the RSS icon use images because it’s the only way possible; the images are links, so they’re kind of necessary.  Because of the lack of images in the design I had to rely heavily on the powers off CSS3, and those powers suited me well.  Even with the frustrations of IE it was a very pleasant experience and all of my future website projects will be affected by it.

If anything, I think that is one of the most satisfying results of this project.  I feel that having discovered new techniques in design and development is one of the best things that can come out of a class such as this, even if those techniques aren’t directly related.  The two things I can take out of this are the design powers of CSS3 and the benefit to creating dynamic content.  Granted, both of those “lessons” have their place in a site design.  They won’t always be possible, but they are nonetheless there when needed.

There are quite a few things that I still want to do with my design, but time just didn’t allow for me to complete them.  I one was to browse through the various posts they’ll notice that there are some sections of content that look kind of “blah”.  There is a lot of styling that takes place to get everything to work just right, and I didn’t have time to work out some of it.  I would also like to build in some more custom functionality on the administrator side; mainly for site appearance and theme features.  Each of have specific elements and procedures that I need to incorporate into them, so it will take more time.  I would also like to convert the theme to HTML5, I have no idea what that will all entail, but I’ve very intrigued to find out.

I eventually want to launch the theme on this site (since it’s my site and all), but I want to first work out the kinks with the design that are still there.  However, if you would like to take a look at what I’m considering a “finished product” for the assignment you can visit this link: www.wiknights.com/wordpress.  This is a 2nd domain that I own and primarily use for hosting development content.  I imported default WordPress test content and posts, so feel free to browse through the posts and get a feel for the overall layout and design.

If you decide to take a look at the design I would really appreciate any feedback that you would be willing to give.  I’m always looking to make improvements on my work and feedback is the best way to do it.  My goal is to eventually release the theme for public download, but for all intensive purposes it’s still currently in beta.

So thanks for reading, and stay tuned for next time!

@font-face{
    font-family: Offset;
    src: url( 'Offset.otf');
}

Basically, it defines a new font family to use in css and gives a relative location to the font file.  You’ll notice that the example I provided is in the ‘otf’ format.  OTF refers to a font that is created as an “OpenType” Font.  There are 4 font types, defined as “TTF”, “EOT”, “OTF”, and “SVG”; and unfortunately not every browser supports all 4.  The rundown of browser support is as follows:

• Internet Explorer only supports EOT
• Mozilla browsers support OTF and TTF
• Safari and Opera support OTF, TTF and SVG
• Chrome supports TTF and SVG.
• Mobile browsers require SVG

So as you can most likely tell, this can get incredibly confusing; and confusing in the world of web development is never fun.  Thankfully there are some brilliant developers out there who have found quick and easy solutions to this, which I will show momentarily; but first let’s take a look at how to get these custom fonts to work cross browser.

The bulletproof way for cross browser consistency is to define multiple source files to the font type.  Each browser will pass over each line of the @font-face tag until if finds a format it can read.  So let’s take a look at it:

@font-face {
font-family: 'Offset';</div>
       src: url('fonts/offset/offset.eot');</div>
       src: local('☺'),</div>
            url('fonts/offset/offset.woff') format('woff'),</div>
            url('fonts/offset/offset.ttf') format('truetype'),</div>
            url('fonts/offset/offset.svg') format('svg');</div>
<div id="_mcePaste">            font-weight: normal;</div>
<div id="_mcePaste">            font-style: normal;</div>
}

You’ll notice in the code we added there is a src: local. This line looks a little strange, but I’ll explain why.   This is a small css hack that ignores locally-installed fonts with the same name.  It essentially tells the browser to use a fictional font name that won’t be present on your machine so there is no mess from the wrong font being displayed.   Lastly, after the source files are declared we set font-weight and font-style so all browsers will default to the same values.  This allows for late declarations of Faux Bold or Italic later in the style sheet.  Keep in mind that web-kit browsers will ignore any style or weight commands without these last 2 lines.

Also, one additional consideration is that there is no guarantee these custom fonts will display properly in each browser.  So before making the final decision to take this approach make sure you test the appearance of each font.

At this point you’re probably asking where you can get all these font types.  I struggled for a while trying to find a solution to this, and finally stumbled on  http://www.font2web.com/.  It’s a handy little site that allows you to upload any ttf or otf font file and it will convert it to each font type you need AND create the styles you need for that particular font; in the format described above.  It takes roughly 10 seconds for the whole process (assuming you have high speed internet).  However, make sure before you convert your font files that you check the associated copyrights.  In order to legally convert the font files they need to allow for web publishing in their copyright.  If such conditions don’t exist, don’t consider following these steps.

So in a nutshell, @font-face can be incredibly useful for  a site design as long as all aspects of it are incorporated.  Make sure your design works well with custom fonts, confirm you have all possible font type formats, and be sure to double check that the fonts you want to use are released under such a copyright.  DO NOT use fonts that don’t allow for public, commercial, or web publishing or file conversion and redistribution.

So until next time, happy developing!

A few weeks ago my updated work on the project was released in version 0.1.6.  With this update site owners are now able to manage a basic inventory of items or products and publish them to their posts and/or pages.  In addition to these updates I’ve also created a quick start guide to using FoxyPress.  It is still a little convoluted and cluttered, but its a first draft and only covers the basic.  With the next release update ( 0.1.7 ) I plan to created more in depth documentation, but until then I have the current version.

A pdf of the guide can be found here: FoxyPress Quick Start Guide – PDF

I ended up discussing the process of back-end customization for SharePoint.  Meaning, the customization of Master Pages and page templates.  In addition I also discussed the differences between manual creations and automations of site collections.  In doing so I walked through the basics of setting up a site collection manually and the steps it took to apply features and settings as we needed them to be.  With this I explained the time that’s involved, roughly 2-3 hours depending on the site.  Once I went through this I created a site collection using my PowerShell script that I just finished writing last week.   This allowed me to show a finished site after about 3 minutes.  That 2 hour to 3 minute difference is huge, and it was pretty cool showing it.

So in retrospect, I was very happy with the outcome of the presentation.  I think it even got a couple people “excited” about SharePoint, or at least intrigued.  I’m glad to know I understand it well enough to give such a presentation.  It helps to be confident. =]

For the last 5 or 6 months I’ve been working on automating certain aspects of configuration and set-up for SharePoint 2010 using PowerShell.  The biggest challenge I’ve had with this is the necessity to learn PowerShell throughout the process.  Sometime back in December of 2010 my boss asked me to start looking into PowerShell and determine the capabilities it had to automate different things within SharePoint.  Needless to say, after about 200 hour of coding I’ve managed to create 4 PowerShell scripts that save a combined total of about 3 hours of work per site collection, which for us is a pretty spectacular time saver, considering we have 200+ site collections.

So, partly as a resource to myself I’m going to document each of these scripts into a short series.  I’ve developed them in such a way that they can easily be taken apart and used for someone’s specific needs, and I hope they can be of some use  I’m not sure how many posts the entire series will be, I’m hoping for around 5 or so.  The tentative plan is as follows:

1. Introduction
2. Preparing Active Directory for use
3. Creating and configuring a Site Collection
4. Changing features and document libraries in bulk ( multiple site collections )
5. Migrating a Site or Subsite
6. Conclusion

I have no guarantee the subsequent posts will be in that order or contain that specific content, it’s just more of a guideline.  So thanks for reading, and check back in the near future for the first bit of SharePoint 2010 automation.