Extension talk:EmbedPDF

= Degrading Gracefully - Mac OS X and inline PDFs =

Hi, this extension works pretty well, it's nice and simple, and does the job as expected. I have however made a small change to the code to help it degrade gracefully, for example:

Where I work currently has a mixed environment of Mac OS X and Windows. Firefox on OS X does not display inline PDFs, basically adobe haven't made a plugin, so it will show a 'this page has missing plugins' and searching will fail because there is no official one.

Sam Gross has made a Intel-only |a firefox addon quicklook plugin that allows firefox to view them actually in browser, so that scratches my itch.

but as it is currently, if any inline-pdf viewer is not found, it simply displays white space, which tells the user nothing if they were not expecting a pdf to be displayed inline on page and even if they were it does not help them in the slightest and provides no solution.

The same would go for a windows computer with adobe not installed.

I've modified the HTML output, just on line 26, i sourced this solution |from here.

That at least gives the user a bit more info. What does the developer think? I think that this(or something similar) should be integrated. feel free to use that. :)

To provide a more complete solution for users here I wrote a quick and dirty php file hosted elsewhere that serves my needs locally, that does some quick checks to see if they're using firefox, if they're on an intel or ppc mac (we only have 1), or if they're running something else.

if they're on an intel mac it'll redirect them to the plugin, ppc it'll tell them they're out of luck and anything else it'll tell them to install adobe reader.

But, for most MediaWiki projects, I wouldn't think it's appropriate to be directing to third party plugins for support or anything els, so telling them what the problem is and an alternative is enough :).

here's the quick and dirty php hack redirect if anybody finds it useful. it's literally the first code I've posted to the Internet, it works for me, sanity check it for your needs.

If anyone else than me finds this useful, dropping me a note on my userpage would be nice :).

Posty

update: i just had a look at some of the other issues on this page, you'll see that others are having the issue, and had no idea of the fix.

mine is similar to the solution down the bottom, except mine has some explanatory text, and a link to the file.

The icon for a pdf is interesting, but not supported by default in mediawiki, there's no pdf icon, but my text and link works.

= Docs from localhost = Hy there! I don't really have experience with this kind of extensions and I was wondering if you could help me. I am using your code and unfortunatelly it does not work when I want to embed docs which are on the local host. Do u have any idea why :(

Answer
Sorry--I just can't get you exactly...

What is the wiki code you're using? Is it something like " http://localhost/my/path/to.pdf "? Does any error occur? Is your Web server okay with PDFs (what does it show if you open "http://localhost/my/path/to.pdf" in a Web browser)?

--Dmitry Shurupov 16:20, 21 February 2009 (UTC)

As written, the regex insists upon a period character (&lsquo;.&rsquo;) in the domain name (like &lsquo;mydomain.com&rsquo;). Fix this by inserting a question mark after the period character: in EmbedPDF.php, change

to

Scorwin 15:31, 10 November 2009 (UTC)

= URI error (semantic forms extension) = Thanx for this extension, it works great here. However I got one issue that maybe easily can be solved. I like to use this extension together with the semantic form extension. In a form the user can upload a pdf-file which will be printed on the outputpage. I like to embed the pdf and not only the filename. I got it working with images but can't get it to work with EmbedPDF. The variable is called so  should have to do the trick. But I got the 'Error: bad URI in !' message after saving the page. I guess it means it doesn't recognize the '{'. Is there a way I can make an exception in the extension that it does read the whole text between and as a filename?

-Jos, 19-2-2009

Answer
Allowing "" in is rather simple--you just have to add few lines into the "embedPDFHandler" function. It will look like this:

However, it will make a trick if the "" string will be transformed to the URI by semantic forms extension. I don't know how it works--so, I'm not sure if it is okay.

If the problem still exists, please, let me know--I'll give the semantic form extension a try...

--Dmitry Shurupov 16:19, 21 February 2009 (UTC)

Still same error
Thanx for the answer. I added the lines though I still got the same error. I'm not quite an expert in php so forgive me if there might an 'easy' solution to my problem.

I guess I got images working because images in wiki got a special syntax: instead of the -tag. Perhaps there is a way to hack the code so that something like Pdf: can be made instead of ... ? --Jos, 26 February 2009

= Installed, no errors, just not displaying the PDF in Firefox =

I've installed EmbedPDF.php in the extensions directory. I added the requireonce line.

I created a new page, with one line:

http://www.mydomain.org/wiki/images/e/e0/Hr1.pdf (I've removed the domain name)

and the page is there, but the pdf isn't embeded in Firefox 3.06. It's Embeded in I.E. 7.x just fine.

Answer
Please, read the "Usage" section.

You have to add the lines like this for URLs:

And lines like this for PDFs uploaded to your MediaWiki:

= Suggestion = Thanks for this extension. It's only in Internet Explorer (tested on v. 8) I'm having difficulties viewing the embedded pdfs. But I still wanted to use this extension, since there aren't any other ones dealing with this problem. I've added a link to the object, so browsers that won't show the embedded pdf, come up with a link instead. Now Opera, Firefox and Chrome show the embedded pdfs properly, while Internet Explorer shows a link. This is an acceptable solution for me, and maybe this idea would work for others as well?

Add the following around line 25-27 in EmbedPDF.php:

It seems that the new feature compability view in Internet Explorer might have something to do with this problem. Any ideas, Dmitry? -- Marius, July 2009

Worked in mw 1.14.0, broke in mw 1.15.1 ?
I have been using this extension happily on a WAMP installation for an intranet with mediawiki 1.14.0. I have just tried to install it on a linux server running mediawiki 1.15.1, and mw complains about the header already being created. I suspect there is a simple fix, but I don't know it. Any help out there? TIA. Mickeyf 2009/11/18


 * It's working fine for me with 1.15.3, PHP 5.2.13, Firefox 3.6.3, and Adobe Reader 9.3.2 on CentOS. --164.54.212.14 15:47, 22 June 2010 (UTC)


 * I'm using 1.15.1 and I think, I had the same problem, but I can't really remember how I fixed it. Try leaving out the ending ?> - that's the only difference I found in my version. Sidcom 11:18, 23 June 2010 (UTC)


 * It was working for me earlier per my comment above, and now it stopped working all of a sudden. --164.54.212.14 16:47, 28 June 2010 (UTC)


 * Do you get the same error? Sidcom 16:56, 28 June 2010 (UTC)

EmbedPDF does not handle https URIs
EmbedPDF does not handle https URIs. If a wikipage contains code such: https://www.some.com/file.pdf Then it says: Error: bad URI in !

Broken image
After inserting the code: http://www.here.com/file.pdf The rendered wiki page displays a broken image. Versions:
 * MediaWiki 1.17alpha
 * InternetExplorer 8.0

Local network file share
Is it possible to adjust the code to except "file://" addresses or "\\[network share name]\" addresses instead of only "http://"? My PHP knowledge is quite limited and I was unsuccessful in all my attempts.

New features
Hi, i added some extra features to EmbedPDF extension. If you find them useful, please check the attached php file.

Features:
 * Image height/width

New Sintax: pdfname|width|height

Examples: Test.pdf|300|300

When pressed a popup message will show up and asks where to load the pdf file (current page or new one)
 * Interactive Button

Examples







Waow, I do love this new "version" but it doesn't work for me using FireFox or Internet Explorer with MediaWiki 1.16. I do have the button but nothing append when I click it. Any way to fix it ? From MoBO 11:54, 17 February 2011 (UTC) Hi, i use the new version with Mediawiki 1.16 and FireFox. You must e litle change in function makeHTMLforPDF. (Sorry for my bad englisch) Original: $filename = str_replace("\n", "", basename($path).PHP_EOL); Change: $filename = str_replace("\n", "", basename($path)); --Speedy McCat. Keiner ist unnütz, er kann immer noch als schlechtes Beispiel dienen. 13:40, 25 March 2011 (UTC)

Zoom to document width?
Is there a way to show the pdf zoomed to the document width, by default?

Broken in the version 1.18
This is the source of the error: $img = Image::newFromName( $input ); The class Image is excluded in the version 1.18. Solution: $img = wfFindFile(Title::makeTitle(NS_IMAGE, $input));

This works fine for me at http://wikiskola.se/index.php?title=L%C3%B6sningar701706, Hakeld 22:45, 28 January 2012 (UTC)

Nesting a magic word within EmbedPDF?
I noticed that the "URI error" thread addresses something similar, but the suggested code hasn't worked for me.

In particular, I'd like to be able to have embedpdf automatically work on any File:File.pdf page so that upon visiting File:File.pdf, the pdf file is automatically displayed as embedded.

I thought to try the following function on every page that exists for an uploaded file:

However, even when I adjust the regular expression in a similar way as you suggested by writing,

The magic word is not resolving so it returns , rather than File.pdf

Thanks in advance for any help,

The fast hack is to add these two lines:

In the beginning of the embedPDFHandler function.

--Dmitry Shurupov 17:22, 15 February 2012 (UTC)

= Question: =

is it possible that the Adobe pageview and toolbar is shown in the document automatically?

It works like that for me
Your browser's default pdf reader is what will be used

1.19 Compatibility
It doesn't seem to work well with 1.19.1 After adding it, it locks up the browser when entering edit mode...