Symphony.

One thing I like to add that people often forget: Mediathek never handled file uploads itself. It has always been a wrapper for another section that worked autonomous.

So the focus of this extension should always be how to handle another section and not how to handle file uploads. Creating a real great file upload field with progress bar, preview and meta information, hashed or unique file names is a totally different project. If such a field existed, Mediathek should be able to handle it – nothing more and nothing less.

Nevertheless, it would be great to unify the different file upload field concepts and merge them into one.

@Nils: If memory serves iframe is being depreciated as it’s really bad for accessibility. By moving away you’d be more future-proof.

However, that’s a really good point about Mediathek just pulling in information from other pages. I mean, you can kind of do that with jQuery load and tel it a specific element to grab by ID but that might not be the perfect solution.

As far as I can see frames are deprecated but iframes are not, see here.

The problem with loading content via AJAX is that you don’t load any information about the behaviour of these elements. So if the subsection contains a special field which uses heavy JavaScript interactions, how would you keep this field working after importing it with jQuery?

Just to clarify things: I’m not a fan of iframes and I really would love to find a solution without them. When I first started developing this extension my idea was to use JavaScript to load the needed content from the related section but it didn’t seem possible in a cross-browser way while keeping all the functionality of the other section intact. Handling an iframe is not easy either (iframe height and border, I’m looking at you) but it seems to be the simpler approach.

I got the impression that any javascript that was added to the header by an extension was present on every page by default, I’m guessing that’s wrong?

Would it be possible to detect the javascript files and also add them to the header?

I got the impression that any javascript that was added to the header by an extension was present on every page by default, I’m guessing that’s wrong?

They are only added to pages containing that specific field.

Would it be possible to detect the javascript files and also add them to the header?

That is certainly possible but you would have to add all needed events manually as the page already finished loading when you add the subsection via an asynchronous call. That would really bring you in trouble and that is the contrary of keeping things simple :)

Sneak Peek 3: Browsing and Searching

Ugh. All the alternatives I’m coming up with in my head would require a lot of dirty hacking…

OK, so iframe it is. At least it’s not being depreciated for now.

Ugh. All the alternatives I’m coming up with in my head would require a lot of dirty hacking…

Same here. If someone has a flash of genius: please keep us posted …

Possibly stupid question: How difficult would it be to hack into the Symphony mechanism that that tells you what files to include for an extension?

My thinking is that Mediathek (or soon to be “Subsection Manger”) could check to see which fields where going to be used and have Symphony embed them onto the page as normal, using them inside the “create new” pane. This way all the relevant pieces would be on the page anyway and you could submit and retrieve data via AJAX.

I have never really played around with the Symphony core so I might have just asked you the equivalent of turning lead into gold.

Possibly stupid question: How difficult would it be to hack into the Symphony mechanism that that tells you what files to include for an extension?

I’m not sure about that - but I imagine it shouldn’t be that hard. If you like to play with the code, you can find the current state of things on GitHub.

Another problem I see: if you manage to import all section fields and the related JavaScript files via AJAX, how would you apply the needed JavaScript events without interfering with the other fields of the parent section?

Are you talking about the Mediathek interface or about data sources?

I’m talking about the interface itself. the DS returns the correct images, but it would be nice to show all the associated images in the article itself.

Hm, that’s strange. Does this only happen after you added a new item or do you always see only one item? In the latter case: Is it always the last added or is it a random one? Any steps to reproduce this behaviour?

Only happens after adding a new item and then saving the article. then on the subsequent “saved” page, it shows the latest uploaded/associated image.

I just upgraded from 2.0.6 to 2.0.7 so i’m not sure if i missed a file or something in there. I did see in the bug tracker with the “string = null” issue that was throwing a js error and stopping mediathek from working in the section i have it in.

Is there anybody who can confirm this bug?
I currently don’t have a plain version 2.0.5 installed and I can’t reproduce this at the moment but I will test this issue as soon a possible.

OK, so iframe it is. At least it’s not being depreciated for now.

The way I see it, if there’s a reason for iframes to exist, this is precisely it.

Sneak Peek 4: Inline Editing

Cool, it seems that you are using the Unique Upload Field extension!

@Michael: Yes, it really makes life easier :)

Sneak Peek 5: Create Items