When you upload MS Office documents to SharePoint document libraries their document titles are used in SharePoint to set the default Title column of list item of the uploaded document.
This does not work for PDF files, but it’s easy to reproduce the functionality.
The project is published under LGPL license because iTextSharp v4.1.6 requires that. – The latest version of iTextSharp (5.3.4) is published under AGPL. Codeplex does not provide AGPL licencing. So I had to use the last version of iTextSharp published under LGPL.
Description:
1. On (Web-) feature activation an feature event receiver iterates through each document library in the web that is not hidden.
2. For each of them the feature event receiver registers a list item event receiver that fires on “ItemAdded” events.
3. Furthermore an list item receiver is installed for the web to fire on “ListAdded” events to register the list item event receiver mentioned before on newly created lists.
4. During upload of files to document libraries the list item event receiver look for files ending with “.pdf” (case insensitive).
5. If there is such an file it opens the file using iTextSharp library and reads its “Title” information.
6. This information is set for the default “Title” column of the SharePoint list item.
7. The change is commited by “SystemUpdate” on the SPListItem object.
8. If an error occures inside the event handler there is no action. The user will never see an error in the module. If it is not possible to extract the title of the PDF document the module will not set the title column of the list item.
Usage:
To use the feature just deploy the SharePoint Solution Package (WSP-file) to your SharePoint farm. It’s not a “sandboxed solution”! After that you need to activate the feature in each web where you need it. If you need to activate it on each new web you could use “feature stapling” to activate it by default. If you need this please write me an comment.
Demo in SharePoint 2010:
1. Create a Word document with a title and save it as PDF:
2. Check the document title by using Adobe Reader or Adobe Acrobat or any other PDF reader
3. First try to upload the DOCX and it’s PDF into a document library without the new feature activated on the web:
As you can see: The “Title” of the DOCX is used for the Title column of the SharePoint list item. For the PDF file the Title column is empty.
4. Now activate the feature:
5. After that delete the files uploaded before in the document library. Than upload both files again:
Now both “Title” columns are set!
6. My last test is to create a new Asset libary in the web. Than I upload both files and check the PDF’s properties:
The Title column is set as expected!!
Demo in SharePoint 2013:
I’ve added a second project just for SP2013. Here is a single screenshot…
Last Thursday I wrote about “Exporting SharePoint 2013 Design Packages with PowerShell”. Today I’d like to show you the import function. This functions can be used to handle with SharePoint 2013 Design Packages with PowerShell, e.g. in deployment scenarios. Therefore it should by very useful. (I hope so 😉 ) FEEDBACK WELCOME!!!
The first sample shows you how to import one design package to a dedicated site. By using the “Apply” parameter the design package will be applied to the site immediately.
The second sample shows you hot to import two different packages to two different site collections. In the sample I use a hashtable for input parameters. They are assigned to the function parameters by “property name binding”. See “http://technet.microsoft.com/en-us/library/hh847743.aspx”: Section “ValueFromPipelineByPropertyName”:
[…]
For example, if the function has a ComputerName parameter, and the
piped object has a ComputerName property, the value of the ComputerName
property is assigned to the ComputerName parameter of the function.
The following example declares a ComputerName parameter that is
mandatory and accepts input from the ComputerName property of the
object that is passed to the function through the pipeline.
[…]
Some more details about that. Skip it if you are not interested…
<begin/>
This “property name binding” does not work with hashtables. Therefore I created a helper function “New-ObjectFromHashtable” that creates a PowerShell object (“PSObject”). This function is generic. (It’s also included in the script files.)
On the one hand with “new-object System.Management.Automation.PSObject” you can create a new “empty” PowerShell object that can be used in your script as every other object, e.g. a SharePoint object like an instance of class SPSite. With cmdlet “Add-Member” you can add new members to the object. – On the other hand you have a hashtable with named values. You can access the collection of names = keys and with each key you can access the value. – Let’s combine it: You can iterate through the keys collection and create a new member in an empty PSObject instance.
functionNew-ObjectFromHashtable {
#written by Ingo Karstein (https://blog.kenaro.com)# v1.0#Use this function to convert a hashtable to a PowerShell object ("PSObject"), e.g. for using hashtables for property name binding in# PowerShell pipelines
[CmdletBinding()]
param(
[parameter(Mandatory=$true, Position=1, ValueFromPipeline=$true)]
[Hashtable]
$Hashtable
)
begin {
$results= @()
}
process {
$r=new-objectSystem.Management.Automation.PSObject$Hashtable.Keys | % {
$key=$_$value=$Hashtable[$key]
$r | Add-Member-MemberTypeNoteProperty-Name$key-Value$value-Force
}
$results+=$r
}
end {
$results
}
}
The resulting object can be passed to each “property name binding” enabled cmdlet. – The PowerShell engine tries to match input object property names and cmdlet parameter names. If there is a match the input object property value gets assigned to the cmdlets input parameter.
The cmdlet can also convert a list of hashtables to a list of objects. That is used in the “Import-SPDesignPackage” script.
<end/>
Parameters
Parameter Name
Parameter Set Name
Mandatory?
Position
Description
SiteUrl
Default
Yes
0
Site Url for import
Site
Site
Yes
0
SPSite object for import
ImportFileName
DefaultSite
Yes
1
Filename and path of the design package for import
Apply
DefaultSite
Yes
2
$true = Apply the design package after import$false = Only install the design package for later activation
PackageName
DefaultSite
No
3
Package name. If not specified it uses the file name without extension. The package name will be used for naming the imported file in the solution gallery of the site collection
MajorVersion
DefaultSite
No
–
Version number of the design package. If not specified it uses “1” for the major version.
MinorVersion
DefaultSite
No
–
Version number of the design package. If not specified it uses “0” for the minor version.
The function returns an object for each processed (or not processed) site collection:
Object Property
Description
SiteUrl
Url of the processed site
Success
$true = Import and “Apply” (if specified) was successful
InputFileFound
$true = File found$false = File not found
InputFileExtensionValid
$true = Input file has extension “.wsp”$false = Input file hat not extension “.wsp”
SiteFound
$true = The specified site was found
SolutionFileName
The name of the solution is auto generated from package name or file name and major and minor version number. This is the name of the package in the site collections solution gallery.
PackageAlreadyExsits
$true = the solution does already exist in the solution gallery.
Some additions
The import process requires the package to be stored inside the site collection before the the last input step. Therefore the function creates a folder named “tmp_importspdesignpackage_15494B80-89A0-44FF-BA6C-208CB6A053D0” in the site collections root web root folder. In this folder the package gets uploaded. From the location the package is imported. The folder will be deleted after successful or not failed import.
Last night I search for “export import sharepoint 2013 design packages powershell”. No luck there. – So I created two functions for this purpose. It works nicely 🙂
The functions only use public methods of the SharePoint (Server) Object Model. No reflection, et cetera. The most important class in this context is “Microsoft.SharePoint.Publishing.DesignPackage”. It has two methods: Export and Install. This I used to create to PowerShell functions: Export-SPDesignPackage and Import-SPDesignPackage. Both are able to work in PowerShell pipeline context. This gives you the possibility to export a bunch of Design Packages from several sites using PowerShell.
You can use the scripts as PowerShell modules or by copying the content to your own PowerShell script files. But please be careful: By now it’s only tested in my dev environment!!
The scripts use the SharePoint Server Object Model. So they have to be executed on a SharePoint farm server! You also need an priviledged account that has rights to export (or import) SharePoint Design Packages.
The first sample uses two SPSite objects as (pipeline) input and tells the function to export the design packages to temp files with auto generated names. For the download of the packages from the sites you can specify “download credentials”.
The second sample exports the same two SPSites. The export file name is specified. By using “UseExportFileNumbering” a number is inserted into the file name like this: “c:\temp\package-1.wsp”. So both export packages have different file names.
The third sample exports two sites with individual export settings for each site. This is possible by “parameter binding by property name” where PowerShell binds the input object’s property to the function / cmdlet input parameters by name matching. But this does not work with hashtables. Therefore I created a helper function “New-ObjectFromHashtable” that creates a PowerShell object (“PSObject”). This function is generic. (It’s also included in the script files.)
The fourth sample exports just one site.
Parameters
The function has the following parameters. All can be bound by “parameter binding by property name”!
Parameter Name
Parameter Set Name
Mandatory?
Position
Description
SiteUrl
Default
Yes
0
Url of Site Collection as System.String
Site
Site
Yes
0
SPSite-object
ExportFileName
Default
Site
No
1
Name for the exported file in the file system. The folder must exist!
Cannot be used together with “ExportFolder” and “UseTempFileForExportWithExtension”!
ExportFolder
Default
Site
No
1
Name of the folder for the exported design packages. The file name will be created through the SharePoint Server Object Model.
Cannot be used together with “ExportFileName” and “UseTempFileForExportWithExtension”!
UseTempFileForExportWithExtension
Default
Site
No
1
When specified the function will create a file name automatically by using "System.IO.Path.GetTempFileName()”. But it adds the extension you specify here. You should use “.wsp” by default.
PackageName
Default
Site
No
2
Name of the export package. This is not a file name but an internal name that is used inside the design package. This is optional. The Object Model can handle it for you.
If you use SPSite objects as input you can specify whether the function should dispose it or not. Default: TRUE = “Please dispose it for me”!
DownloadCredentials
Default
Site
No
–
You can specify credentials for the download of the generated package. The package is stored in the the solution gallery of the site collection. It’s downloaded by the function by using System.Net.WebClient with “DefaultNetworkCredentials” if no credentials are specified.
OverwriteExistingFiles
Default
Site
No
–
If specified it overwrites the export file if it exists. If not specified it skips the export. But in the case nevertheless the design package will be created .
UseExportFileNumbering
Default
Site
No
–
If you use “ExportFileName” you can specify this parameter to insert numbers into the given file name as described above.
The function returns an object for each processed (or not processed) site collection:
This objects can be used in pipelines or … as you like.
Object Property
Description
Site Url
Url of the processed site
Success
TRUE = Export successful, export file created.
SiteFound
The site collection was found
ExportError
$null = OK
System.Exception = Error occurred
PackageFileName
Name of the Package created by the Object Model
PackageName
Name of the Package created by you OR the Object Model
PackageMajorVersion
…created by Object Model during export
PackageMinorVersion
…created by Object Model during export
ExportFileOverridden
If “TRUE” the export file did exist but was overridden during export. If “OverwriteExistingFiles” parameter was NOT specified this property will always be FALSE.
DownloadError
$null = OK
System.Exception = Error during download
Some Additions
The design package will be stored in the solution gallery of the site collection that can be found here: <site-collection-url>/_catalogs/solutions. It’s the same location as for the sandboxed solutions. It interesting: sandboxed solutions are deprecated but in this case they use at least the same storage for a new functionality.
After the package is created you can download it from the solution gallery. No big deal.
You can use the script file “SPLogging.ps1” as PowerShell module. In the following sample the SPLogging.ps1 file is stored in the same location as “SPLoggingDemo.ps1”. Or you copy the content of “SPLogging.ps1” to your own file.
