Its great that Media now respects the File directory setting and saves widget uploaded files to the folder set there. However, when it comes to embedding images using the CKEditor plugin, most users will also upload new files using it. The bad news there is that they will end up in the root of the files directory, not what File directory is set to for the content type.

Spoke with Dave Reid on IRC about this and he told me that for this to work, the WYSIWYG module needs to be able to support this, which it currently does not.

Right now the workaround for this is:

  1. Add and image field to the CT
  2. Upload the images to embed to it first
  3. Then use the library in the plugin to find and embed them

Problem with this is that it creates a complex workflow for content editors. For a site with tons of images, it will also make it hard to quickly locate the newly uploaded ones.

I believe its important that we can come up with a solution that is easy to work with. Adding support to the WYSIWYG module might not be the best route judging from what Dave said:

the main problem then is that we'd need to add our crap-ton of file settings to every possible field that works with wysiwyg

One solutions I can think of is to add an Insert media button that works like the http://drupal.org/project/insert module (would be great to have anyways).

The work being done on being able to edit the data/fields for a file is also something that makes this more attractive.

My suggestions is to focus on that, and once we have that working rock solid, we can have a new stab at the editor plugin.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aaron’s picture

WYSIWYG doesn't work with fields. Why not make a global setting for the WYSIWYG file directory?

aaron’s picture

I see what you're saying now. You want the WYSIWYG in, say, the body to somehow grab the settings for, say, field_image (as opposed to, say, field_media). Or, the WYSIWYG in field_description to grab the settings for field_headline_image...

tsvenson’s picture

Well, my #1 wish is that the WYSIWYG plugin would be able to be aware of the File directory path (including respect any tokes used in it) so that files uploaded with it are stored where I want them. Now any file uploaded using the plugin will end up in the root files folder.

Files added using the Media widget does respect File directory and stores them correct.

aaron’s picture

Status: Active » Needs review
FileSize
2.97 KB

Related to this is that media added from a URL will always end up in the root as well, regardless of context. This patch adds a global setting for that. Not optimal, but it gets the ball rolling.

szantog’s picture

I've started a sandbox work, this should work with wysiwyg: http://drupal.org/sandbox/szantog/1142018 Feel free to test it! Every feedbacks are welcome.

tsvenson’s picture

Status: Needs review » Needs work

Applied the #5 patch, flushed caches, typed in a directory name on the admin/config/media/browser page. However no such folder is created and files uploaded using the WYSIWYG plugin ends up in the root files folder.

gmclelland’s picture

presleyd’s picture

FE paths does not currently work with files uploaded via the Wysiwyg plugin upon upload. If you edit the file entity later, the file is moved to the token based path designated via FR paths however.

gmclelland’s picture

@presleyd - Did you open an issue yet for the FE paths module?

presleyd’s picture

I did not, given that the wysiwyg media plugin seemed to have other path issues and FE paths worked fine with standard fields I guessed the error was on the side of the plugin.

ñull’s picture

trying to prevent duplicates I would like to report here that dragging a media image to the WYSIWYG window will create wrong URLs. The IMG src URL has a missing leading slash. In a node you would get node/sites/default etc. which is of course wrong. The same is valid for the link. An off-topic issue is that the link returns a blank page.

presleyd’s picture

@ñull That does not sound like the same issue.

If someone else feels that this is a fe_path problem I'll happily create a ticket there. Seems like the wysiwyg plugin doesn't fire some hook that other media uploads do if anyone else wants to help look into this.

michaelfavia’s picture

Status: Needs work » Needs review
FileSize
2.33 KB

This patch adds a global configuration for the desired directory for uploaded media in wysiwyg.

It also reorganizes all wysiwyg options into a fieldset.

gmclelland’s picture

@michaelfavia, - does the patch support tokens?

michaelfavia’s picture

no but it can be easily added if you'd like.

gmclelland’s picture

Yes please, that way we could organize the files by date folders to keep them from filling up a single directory.

Dave Reid’s picture

It actually supports tokens right now for uploads, just you don't see a UI for it and it only supports global tokens, which includes [current-date:*].

gmclelland’s picture

Thanks for the clarification.

gmclelland’s picture

#13: wysiwyg_global_upload_dir.patch queued for re-testing.

gmclelland’s picture

#13: wysiwyg_global_upload_dir.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, wysiwyg_global_upload_dir.patch, failed testing.

gmclelland’s picture

#13 Needs a reroll for the latest dev.

torpy’s picture

Status: Needs work » Needs review
FileSize
1.42 KB

Rerolled #13 for latest dev.

gmclelland’s picture

Jackinloadup’s picture

It would be nice if there was a folder selector like files uploaded with media_browser_plus. Fields could select a folder to upload to or just set a path like you can do now.

ParisLiakos’s picture

szantog’s picture

@gmclelland File Entity Paths now supports the media - wysiwyg.

gmclelland’s picture

@szantog - Thanks for the update.

Here is a reroll of #23 against the latest dev release. I haven't tested yet to see if it works, but it does apply cleanly.

ParisLiakos’s picture

Status: Needs review » Needs work

I tested and works indeed.. I commited it but i think it would be good if we add the token tree with the gloabl tokens below it? (and actually test it)
what do you think

gmclelland’s picture

Here is the first stab at it. It shows the form with the tokens in a collapsed fieldset, but I still need to perform a token_replace (see http://api.drupal.org/api/drupal/includes!token.inc/function/token_repla...) in a submit handler.

I'm not sure how to do the second part though. Maybe someone could help guide me?

ParisLiakos’s picture

I think we need only global tokens.
Sth like this

'#token_types' => array('global'),

And i think token_replace is not needed, like Dave said, this is already supported

gmclelland’s picture

Made the changes you requested. This is still untested. Feel free to comment if this works for you.

ParisLiakos’s picture

Just a couple of coding standard fixes needed;)

+++ b/includes/media.admin.incundefined
@@ -323,6 +323,19 @@ function media_admin_config_browser($form, &$form_state) {
+  if(module_exists("token")) {

Use single quotes, no need for double;) Also leave a space after if, before parenthesis

+++ b/includes/media.admin.incundefined
@@ -323,6 +323,19 @@ function media_admin_config_browser($form, &$form_state) {
+      '#theme' => 'token_tree');

finish this line with a comma, and close the array in the line below

Dave Reid’s picture

Please use just the following:

    $form['wysiwyg']['tokens'] = array(
      '#theme' => 'token_tree',
      '#dialog' => TRUE,
    );
gmclelland’s picture

Here the changes.

gmclelland’s picture

Here is the changes Dave Reid requested.

ParisLiakos’s picture

Status: Needs work » Needs review
FileSize
1.02 KB

This just adds This field supports tokens. in the file directory path description, to emulate field settings;)

gmclelland’s picture

@szantog - Do you think committing something like this will effect your module http://drupal.org/project/fe_paths in a bad way?

I haven't checked the issue queue yet, but I'm thinking we will need another configuration like this. For instance files added at file/add get placed in the root files directory.

I also haven't got http://drupal.org/project/filefield_paths to work on file fields with the media selector widget so maybe I need to try out http://drupal.org/project/fe_paths?

Devin Carlson’s picture

ParisLiakos’s picture

Status: Needs review » Fixed

ok, time to commit this
http://drupalcode.org/project/media.git/commit/b350d22

Let fe_paths do the rest, just supply some basic configuration in media

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

nerdoc’s picture

Component: WYSIWYG integration » Code

Sorry to resurrect this thread. But IMHO this is still not solved / does at least not work on my site. Despite having "images" as the path set in the global CKEditor config settings (File directory for uploaded media), files embeddedly uploaded via CKEditor/Media are still stored in the private root directory. And hence can not be read by anonymous users, so they are not displayed to them. Uploading works, and I can see the file in the private:// dir. Uploading of files in media's file fields work perfectly, into subdirs. Only the exact issue here is still open!
Any hints?