Serendipity Forums

Hallo,
I use serendipity_event_entryproperties version: 1.36 to insert a custom field into my template.
If I create/edit a post, I was able to choose an element form the media-database. As a result the path to this element was written into the custom field.

Since update to Serenditpity 2.x (2.0.2 at the moment) I am not able to choose a pdf from media-database any more. Images are still working.

Any help is appreciated!

Hi!

The media database popup/selector was changed quite a bit for the 2.0 release, so I suppose the previously "abstract" way of inserting/returning links from the popup might have unintentionally broken this feature.

Maybe onli can help here, I believe he has better overview over those restructurings than me right now?

Regards,
Garvin

konus wrote:Since update to Serenditpity 2.x (2.0.2 at the moment) I am not able to choose a pdf from media-database any more.

I can not reproduce that, although my 2.x installation was a fresh install, not an update, and it's using the latest git master branch.

Selecting PDFs from the media DB in a custom field seems to work just fine, although I don't have a theme at hand that actually uses custom fields. But I can select a test PDF and the path to it is saved correctly in the custom field.

Did you try a different PDF? Maybe there's something fishy about the one you're using.

YL

Could also be an imagemagick vs. gdlib issue; how is the PDF inserted into your serendipity_images database, how are its fields set?

It seems that is a BUG!

Upload a pdf file to MediaLibrary (S9y 2.0.2).
Selecting the pdf file in an entry via the ML layer works OK.
Selecting the pdf file via entryproperties CustomField1 ML layer does not drop the file link into the CustomField1 text field.

I assume we need some "parent.self.opener.serendipity.serendipity_imageSelector_addToElement()" voodoo magic here. I does not throw a JS error - it just hesitates to drop on click.

Timbalu wrote:Selecting the pdf file via entryproperties CustomField1 ML layer does not drop the file link into the CustomField1 text field.

In my installation of 2.0.2, it does (as mentioned above).

YL

Hmm, strange. Mine does not.
And it is not related to using a WYSIWYG-Editor or not. Same for allowing popup or not.
It seems it wants to take step 2 like for images but does not reach that step and not fall through right to the textarea.

(btw same on master - and it seems to be a Windows OS problem (here), since my server installations work well too.)
Hmm, we will need to investigate this...

Edit: And it is not related to pdf objects only. Same happens with zip objects too.

I assume it must be somehow related to window.opener / window.parent / window.top and the parent.self.opener vs window.parent "problem". There seems to be a tiny difference using "parent.self"(?) on WinOS...

Timbalu wrote:(btw same on master - and it seems to be a Windows OS problem (here), since my server installations work well too.)

Huh? Are you saying it depends on whether the blog is hosted on a Windows or *nix server?! Windows or *nix client in conjunction with JS I could see, but this … maybe I'm misunderstanding?

YL

yellowled wrote: on a Windows or *nix server?

Well, Yes. That is what I experienced, locally and remote.

The funny thing on this is, that it does not happen with blogentry forms. So there may be that this block https://github.com/s9y/Serendipity/blob ... s.tpl#L286 or something is missing with entryproperties. That is why I guessed it to be near the "self" vs "parent" issue.

That would mean that something OS-specific on the server changes the generated Javascript in a tiny way. I think that is highly improbable.

self vs parent is a possible cause, but then it should depend on the browser of the user.

I think we were just happy that it seemed to work in some situations...

I now think I got it ...

Its a real bug, since it basically has nothing to do with Win/*nix OS environments.

I just got dizzy about this faulty behaviour of PDF files preview, which works well on *nix Imagemagick install packages, since they include ghostscript to read the PDF for the serendipityThumb building. On Win you don't have this (at least I don't). So there an uploaded object is an object! (And in this special case it creates a thumb name, even if not having a real thumb preview file of the content, since that fails to proceed successfully.) On imageMagick/Linux environments it is a real Image, which works well for the entryproperties customFields fallthrough. This caused the different behaviour.

If you run a test with a zip file object, you will remotely have the same bad experience for entryproperties customFields as on my local (Win) setup.
In old Serendipity installations, we had an extra ML item link underneath the mime icon link for these cases, which pointed to the correct step 1 location. (In my edit above, I forgot to test this remotely with a zip object too.)

I will push a proposel in a while, when I have managed to fix some inconsistencies I found on the way.

What we need is to build the {$link} for objects separately in media_items and choose a more precise fallback (missing the parent.self.opener checks for filename_only=true) in media_choose.

Sincerely,
S. Ian Holmes

That's got to be one of the weirdest bugs in s9y ever.

YL

I am nearby ready to commit that thing. But, are you able to confirm, that zip files drop into customFields currently does not work?

Just to set this right: The mentioned thumb name speciality (in parenthesis) is not the cause of it all, it just made debugging and thinking more complicated.)

To the OP or anybody in need for this to work properly.
Please use this workaround until we release 2.1.

By hand copy a http link path without the protocol to that file from the body field for example,
eg "/path/uploads/test.pdf"
and drop it into your custom field. That should help out a while.
Make sure you don't accidently point to the thumb image instead, which probably is what YL had.

It is not advised to take the changed files in master branch to your 2.0.x install, since they have other changes which might conflict if not updating the whole package.