11

We have started using an Enterprise wiki inside our department, but a huge number of users started complaining about the process to insert images inside the wiki pages, specifically if there are a lot of images that should be added.

Because currently user have to follow this process:-

  1. Save the image locally.
  2. Go to the Wiki page's "Insert" tab , click on add Picture, browse for the image, and upload it :

enter image description here

  1. Then they will be prompted with the "Update document properties dialog".

Is there a way to just copy images from local computer and paste it inside the Wiki page's Rich text editor, similar to how you can copy / paste text?

Improve this question
4
  • 1
    You're lucky if you already have the images as files and not on the Clipboard like screenshots. This is rather a common requirement that contradicts the Enterprise design but favors ease of use. I feel your pain, but don't have a solution - SharePoint components and data are designed for reuse and reconfiguration. They wouldn't even try to choose default location for 'pasted' images as there could be several equal libraries available on the site for different purposes. Enterprise content should not only be easily authored, but also given due amount of thought, review, protection, etc.
    – Alexey Krasheninnikov
    Oct 9, 2014 at 13:46
  • Images can be sensitive, too. Imagine how easy it would be to paste screenshots with SSN, passwords, account names, salary info, etc.
    – Alexey Krasheninnikov
    Oct 9, 2014 at 13:48
  • 1
    Thanks for the explanation. The reasoning behind it is valid in a enterprise context. However in a (small) project context where the object is to share information in a more informal manner requirement might differ. Re-usability is less important, ease of use is more. Maybe SharePoint offers an alternative, not based on a Enterprise Wiki? If so, it would be very much appreciated if you could advise me. Thanks.
    – user42350
    May 14, 2015 at 8:46
  • Hi John, I'm having the same problem and do find the process of uploading images quite cumbersome. Which solution did you find in the meantime?
    – mBBe
    Jul 16, 2015 at 11:04

6 Answers 6

Reset to default
4

There is a reason for this process. When you use an Enterprise content editor such as the Wiki portion of SharePoint (or Article pages for publishing sites) it is supposed to become a repository of all the items, text and multimedia and thus making it reusable.

By placing it and coding it in an asset library (or image library) you are de facto making it re-usable. Pasting it into the page will not do the same job.

The system has been designed to create virtuous circles of storing data and make date resurface in the form of a wiki page, search results, results from content queries and search.

Improve this answer
6
  • 8
    But if we compare these feature which you mentioned , and the ease of use, we will go with the ease of use approach. and at the end to be honest ,,, pictures in general do not have business value without being displayed inside wiki pages,,, so i do not care where/how the pictures are stored. and re-using pictures could be useful in theory ,, but in real application no one are going to search if specific image is already there , they will just copy the picture from any where and paste it inside the wiki page....
    – John John
    Oct 9, 2014 at 12:09
  • 3
    And at the end copy/paste images can still follow the defautl approach used in SP.For example if SharePoint can automatically extract the images that have been Pasted and handle them the same way as if they were added manually using the "Insert" tab...
    – John John
    Oct 9, 2014 at 12:10
  • 1
    Even if you insert a picture in a blog post (which is only a rich text field and not something as complex as an Enterprise wiki page) you will be asked to store it in a document library so evidently it is not possible for SharePoint to 'extract' the image. I seem to recall however that the step of Update document properties dialog comes up only because the document library (or asset library or picture library) as an Image content type as default. If you remove the Image content type and store the image as generic document you can skip one step.
    – susan
    Oct 9, 2014 at 13:34
  • but the problem with storing the images directly inside the document library is that all the images (for all the wiki pages) will be stored inside the same folder ,, and a lot of conflicts will happen (when users add images with the same name, and they specify to override current image). while if you save the images inside the image library SharePoint will automatically creates a new folder under the image library for each wiki pages and store all its related images (where the folder will have the wiki page name),, so in this way no conflicts will happen..
    – John John
    Oct 9, 2014 at 16:49
  • 3
    There is no reason the sharepoint people can't let you paste images, and then transparently add those images to the document repository in the background--without you having to do any additional work.
    – Kimball Robinson
    Sep 9, 2015 at 19:04
5

I hear all the reasons why SharePoint doesn't support this, but this feature is currently the difference between our users using the SharePoint wiki and not using it. It is a shame too, because it has lots of benefits, but there are no benefits if no one uses it.

In Office 365, both the OneNote and Outlook web applications now support pasting images in the web browser, and users expect that functionality throughout Office online.

Maybe it could be a feature that can be disabled for environments where reuse of images is important, but it sounds like it would greatly benefit a large number of users in environments where that is not as critical.

Until Microsoft fixes it, we have found that OneNote online is the simplest way of providing this feature. It lets users create a wiki-ish set of pages to share knowledge, and it includes the ability to paste images into the online version without uploading and inserting them.

Improve this answer
1

Thanks John, for plugging my product :)

OneNote online is indeed cool for a "wiki in a file" concept and I have taken to using that for my on-line documentation because it is so easy to work with.

Sometimes however a wiki is a better option and so I reckon they are not dead just yet. The inadequacies of SharePoint wikis have vexed me for a long time, especially this image import issue which just makes them unusable if you have the job of converting legacy content say based in Word.

I have posted a couple of blog article on (or related to) the subject:

I have also built some technical solutions (Word to Wiki) that I hope address the shortfall in capability.

The Farm solution version of Word to Wiki has been Kaboodle Software's biggest selling product for the past 2 years with customers all over the world. We are just in the process of releasing the on-line version(s) to the App Store.

As you point out, Word to Wiki (Lite) is free and does the basics of converting a Word document to a wiki page but is limited in features (it only works with a standard wiki library and not an enterprise wiki and the source and target libraries must be in the same web site for example).

What it does is strip out any embedded content from a source Word document (images, smart art, embedded objects etc.) and saves them as graphic files in SharePoint image library. Each document's embedded content is saved to a uniquely named folder and so there is no chance of name conflicts. It then stitches back the html with links to these graphics.

The Pro version is just a couple of weeks away from the App store and adds the following features:

  • Balk asynchronous processing (up to 100 documents at a time)
  • Support for enterprise wikis (any publishing library in fact)
  • Cross site/site collection publishing
  • Metadata mapping
  • Sub-element publishing i.e. you can select just part of the word document for publishing (say a section) as a wiki page rather than the whole thing.

We are thinking of licensing it on a subscription basis with a maximum charge of $100/month per organisation (less, if you need it for a small project team).

Both app store versions will work with O365 and on-prem.

Delighted to receive any constructive feedback on the app store releases.

Improve this answer
1

Upload Word doc, then copy paste to Wiki

Upload a Word doc to a document library, then use the in-browser Word editing app to copy and paste to a wiki page. The wiki page will show all the images. The drawback is that if the Word doc is deleted (or renamed?) the images will break.

In an additional test the target image failed (because crossed site boundary?). I didn't dig further because the image urls are horrible anyway (>1500 characters):

  • https://app-sp.example.org/we/GetImage.ashx?WOPIsrc=https://main-sp.example.org/collab/site/_vti_bin/wopi.ashx/files/b4a4621f494c49bbb1d43146a0cc4fe2&access_token=eyJ0eX...snip...31ea2&Word=1

Post to Blog from Word or Onenote, then copy

Essentially the same as uploading a doc. Post to the SP blog, then copy from the blog to the wiki or site page. It's kind of clean, images are saved to the blog and stay there when re-used:

  • {blog_site}/Lists/Posts/Attachments/36/clip_image001_thumb_0F6F6A41.jpg

So for use in a Collab site this would mean deep nesting. Perhaps not a real problem:

  • {collab}/{blog_site}/Lists/Posts/Attachments/36/clip_image001_thumb_0F6F6A41.jpg

I think this is safer long term than copying from Word-in-browser, simply because in my experience documents are more likely to be moved or renamed than blog posts. Adjust for your local circumstances.

...

Either of these are good to get started and when you're importing from another knowledge base source. The method is less suitable if you're going to use the Wiki as Wiki - documents that evolve over time with many edits - as it would be just silly to have a new blog post for every edit-with-images. For that we need a true "save-image-pasted-from-clipboard".

Improve this answer
0

We use OneNote (which supports concurrent editors, offline, copy and paste, deeplinks, mobile apps ... the feature list goes on and on) for collaboration.

Enterprise Wiki is a one-off publishing step for us, and we have a fairly competent SharePoint Content Owner (or rather, the owner has a competent lackey) that publishes the images from OneNote into an Enterprise Wiki Library.

Colin Gardner from Kaboodle in Australia has a full trust product that converts Word to Wiki. He has also recently released an Office 365 version that has a Lite version with a PRO version to come later. Have a look at the video - I've seen his presentation in person and it's very good. App pulls out all the pictures and formatting from a Word document and updates it into the Wiki. The free version does the basics but I don't know if it'll work on-premises.
http://www.kaboodlekonnect.com/renditions/word-to-wiki-online

KWiz also has a clipboard manager for SharePoint that will allow you to paste from clipboard directly into an Image Library.
http://www.kwizcom.com/sharepoint-add-ons/SharePoint-clipboard-manager/overview/

Improve this answer
0

The spin in the accepted answer made me dizzy. "virtuous circles of storing data" ... wow.

Developers seem to be more committed to explaining why users shouldn't want something than they are to providing the features requested by a multitude of users.

And this is contrary to the spirit of a wiki: "I suppose you are using the Wiki for a sort of Knowledge Base or Enterprise Content source. In this case, pages are not randomly built, but carefully planned and architect, therefore there shouldn't be this sort of errors (users using same names for different screenshots)."

A wiki is for storing random facts as a need to record them arises ... off-the-cuff and quickly -- this is antithetical to "carefully planned and architect."

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.