By rtwingfield on

I have installed the IMCE module. The "advertising" description sounded great . . .until after installation, I've learned that it will not recognize objects uploaded via FTP. I have Googled and browsed several years of complaints regarding this design flaw, and I just don't understand why it is/was designed to require that objects be uploaded via something referred to as "file field"? I use a CoffeeCup Direct FTP application that simply works with whatever is in a target directory, whether it was uploaded by the ap. or created in place with an editor such as vi. Also, the ZenPhoto system doesn't care how photos are imported to their system -- if they're there, then you can view them.

Is there a newer version of this application module, or perhaps a work-around to fix this problem?

Seems to me that this should just be a simple directory object content viewer and manipulator, as in add, update, copy, move, and delete. In other words, just the functions of any file maintenance program.

I think I have read something about the objects uploaded via the "file field" scenario are recorded in a database table? This just sounds like too much "Microsoft registry" sillyness: "If you don't register it, then I'm not going to let you see or use it."

Why not just read the NTFS MFT (on a windoze system) or assemble the object list from the Unix inode data?

The IMCE system looks like a good idea. I like the way it dove-tails in with the WYSIWYG editor, but this "gott'a be registered" thing is a show-stopper for me.

Comments

Jaypan’s picture

Jaypan commented

The 'gotta be registered' thing is extremely useful, as it allows Drupal to manage files on a system, allowing them to be public or private, and reused multiple times. It's there for a reason, even if that reason is not apparent to you.

Files uploaded through a file field will tie into this system. However, using the File API, files can be added to the system without using a file field. It takes time and work to do so though.

As with everything Drupal related, you have a few options:

1) Use contributed modules, and adapt your system to work with the modules you want, or
2) Develop your own module that extends/alters an existing module, or
3) Create a new module to do what you want.

I understand that you are disappointed, but remember, the maintainers of the module have built it for free, and offer it for free, so complaining about their free work isn't very respectful to the time and effort they have put in simply for the good of the community.

rtwingfield’s picture

rtwingfield commented

The 'gotta be registered' thing is extremely useful

. . .I suppose that some control over private or public permissions could be useful for some circumstances, but it would also be useful to simply have an option to turn that edit off; in other words, no check with the permissions database police.

Regarding

reused multiple times

what does this imply? Can images not be reused as often as desired?

using the File API

. . .Again, I'm going to comment that CMS is often touted as a tool for non-programmers . . .non-technical users (but we all know that's not true); regardless, (although I have close to forty years of experience as an applications programmer/analyst, DBA, IBM AS/400 and Unix, et al.) I simply want to be a "user", and not have to drill down into the open-source code (although I could/can, but I just don't want to have to take the time). You are on point -- the developers have contributed a lot of "free" time, and I do appreciate that. I just simply want to be a reasonably knowledgeable user and not have to write code.

Finally, as for

isn't very respectful

isn't bitching about

Drupal forums suck?

on your signature the same to the forum author(s), too? Actually, I subscribe to several forums, such as the , and yes, it is much better, but I'm not complaining about the Drupal forum, as least not on my constant signature ;-)

And finally back to one of my questions regarding a work-around your comment

using the File API, files can be added to the system without using a file field. It takes time and work to do so though.

. . .I'll take a look, but it sounds like a lot of coding that I didn't want to have to do. Will the CKEditor with IMCE then be able to "see" FTP'd files?

You know, I'm thinking that the IMCE code probably has some edit check that says something like:

   If object not found in database table
      then skip it.

Why not just comment this out, or provide an option to bypass the edit?

Thanks,
RW

Jaypan’s picture

Jaypan commented

isn't bitching about

Drupal forums suck?
on your signature the same to the forum author(s), too?

I'm one of the forum authors, in that I have directly contributed code on this forum that you are using right now.

Other than myself there are no forum authors, as the forums have not received any updates in years other than the ones I've created, with the exception of some features that were made for other parts of the site and happened to also show up on the forums.

If you want to know why I would have such a signature you can read this thread here: https://www.drupal.org/node/2536122

rtwingfield’s picture

rtwingfield commented

I've actually defended Drupal as a CMS choice partly because of the large "community" that contributes opinions and advice to users, so I wouldn't say that the forum "sucks" (but then since you are one of the authors, I suppose that you have the right to ask such a question). I do like the design of the FreeBSD Forum (xenForo), and I have hosted several adaptations the Simple Machines Forum.

No . . .I'm not going on record as saying the forum sucks. :-)

Jaypan’s picture

Jaypan commented

Well to be fair, I'm the only one who has actually gone on record with that comment. Everyone else is just agreeing that the forums are outdated and need improvements.

Stefan Lehmann’s picture

Stefan Lehmann commented

until after installation, I've learned that it will not recognize objects uploaded via FTP.

Uhm .. I'm sure, that you can select files which have been uploaded via FTP in IMCE (just tested it). It's only the search which requires that files have to have a corresponding database entry as far as I know, which makes kind of sense in my opinion.

Is your webserver mabe not able to access these files?

I like cookies!

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

Using IMCE (let's be precise) 8.x.1.1 on a Drupal 8.1 system, I can access hundreds of files in dozens of directories I have uploaded by FTP. The only restriction is that they have to be in the public file area. That area is defined in settings.php, I believe. IMCE works great for me and is necessary to overcome the many limitations of dealing with image files in the current in-core version of Ckeditor. I don't see any search option but then again I don't need that.

rtwingfield’s picture

rtwingfield commented

I am responding (with thanks) to the previous two responders, Stefan Lehmann and fkelly.

Is your webserver mabe not able to access these files?

. . .should not a problem. I have a directory created just inside the relative root directory of ./drupal7. It's mode is 775, in other words, drwxrwxr-x.

The only restriction is that they have to be in the public file area. That area is defined in settings.php, I believe.

. . .Perhaps I'm not clearly understanding what Drupal perceives as a "public" file. I'm a Unix systems programmer, and we look at file permissions as per modes corresponding to owner, group, and other-public (a non-windoze concept). In other words, mode 775 (octal or 111111101 binary) means owner has read-write-execute permission. Group also has read-write-execute permission, while other-public only have read-execute permission. (Apologies if you already understand this.)

So, apparently "public" is described or identified to Drupal as a condition set in a database table . . .somewhere? The path to a "public" directory/file has to be (as suggested) specified in ./settings.php? My thought is to place this public accessible "holding" directory outside of the Drupal sub-directory file hierarchy . . .just inside /www/drupal7/. Actually, I would prefer to have it completely outside the Drupal7 hierarchy, for example, /www/public.tmp/ and protected from Drupal upgrades, etc. There public contributors could pre-stage via FTP, objects such as a formatted PDF article, from which trusted authorized Drupal users could select objects for inclusion in Drupal articles, etc. In other words, I'm asking IMCE to "look outside the box" to find objects to include in Drupal content. This scenario is similar to sending a letter to the city editor of your local newspaper -- odds on . . .it's probably not going to be published.

Regardless, where would one identify this path? I've looked in /www/drupal7/sites/default/ and found default/settings.php and settings.php. I have run diff against both files and found only the following differences (the mods to the latter was defined to configure the MySQL server):

# diff    default.settings.php     settings.php > diff.out
215c215,229
< $databases = array();
---
> $databases = array (
>   'default' =>
>   array (
>     'default' =>
>     array (
>       'database' => 'ar001',
>       'username' => 'xxxx',
>       'password' => 'xxxxxx',
>       'host' => 'localhost',
>       'port' => '',
>       'driver' => 'mysql',
>       'prefix' => '',
>     ),
>   ),
> );
247c261
< $drupal_hash_salt = '';
---
> $drupal_hash_salt = 'lpGvy4pxxxx~~etc.~~xxxxx';

If not as I've describe, then where/what is the "Drupal public file" area? . . .and where and how to define the $PATH to the same if not in ./*settings.php?

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

In my settings file, which is in "sites/default/files" at line 502 I have the line:

# $settings['file_public_path'] = 'sites/default/files';

This defines the public file path to Drupal. There may be ways to override this, but I've found that Drupal wants you to work its way so I gave up struggling with it. On my drupal8 site I had initially placed some photo gallery files in a directory right under my "root" so for example: /drupal8/jboxgalleries where my root is drupal8. Then I found out IMCE couldn't see these since they weren't in "public". I tried messing with settings.php but IMCE still couldn't see these files (thousands of jpg's that I wanted to be able to reuse anywhere on the site). I gave up and just moved jboxgalleries under 'sites/default/files'. Works like a charm with IMCE.

Sites/default/files should be protected from upgrades, at least if you do the updates according to the process listed on drupal.org. I used FTP to get the files there too. Incidentally, you can use IMCE to upload files to a specified directory too. FTP is just better if you have a bunch of files to do ... as you no doubt know.

rtwingfield’s picture

rtwingfield commented

. . .just need a little clarification re:

In my settings file, which is in "sites/default/files" at line 502 I have the line:

What exactly is the "settings" file name you are referring to? I don't have a config file with > 502 lines of code ???

Essentially, where you mentioned your /drupal8/jboxgalleries, I've basically tried the same thing with my ./drupal7/ar001 directory. So in a work-around similar to your physically moving your jboxgalleries directory to sites/default/files/galleries, I simply created a symbolic link # ln -s /www/drupal7/ar001 /www/drupal7/sites/default/files/ar001

From a Unix command line, I can see the files, but IMCE still doesn't see them. I've followed Home » Administration » Configuration » Media » IMCE, designated other directories, but still "no joy"; the IMCE complains that "Directory xxx (whatever) is not accessible. Unable to get a working directory for the file browser." Is there something "ornery" in Drupal that will not follow symbolic links?

(I wish I could post a screen shot image . . .but I'm just a sixty-seven year old NUBE.)

Stefan Lehmann’s picture

Stefan Lehmann commented

If you put it into the settings.php file it will be hardcoded and can't be changed over the UI anymore. That doesn't necessarily have to be a bad thing you just have to be aware of the advantages / disadvantages of each method.

The easiest way is to do it over the admin UI. This is the path: admin/config/media/file-system

I don't really get why you would like your website to be able to access anything outside of the web application's directory, as as far as I know you normally want to try to limit the access of the webserver as much as possbile, as it's always to be treated as a possible source of mischief. But well I'm not a UNIX pro .. :-)

+ if you're using .git as your CVS and you're using eg. the sites/default/files/* folders as your public & private files these folders will automatically be excluded from .git tracking.

At the end it's normally worth to stick to best practices in the Drupal sphere.

I like cookies!

rtwingfield’s picture

rtwingfield commented

I don't really get why you would like your website to be able to access anything outside of the web application's directory

. . .that's a fair and on-point question. Well . . .many objects such as photos, text files, etc., may be utilized by other applications outside of the Drupal application scope. For example, the specialized Zenphoto CMS, or the Samba file server.

Also, this server installation probably will become a multi-domain server for all of the ten Arkansas CAP Squadrons, in addition to the Arkansas Wing CAP. If you're curious, current development can be found at Arkansas Wing CAP

I mentioned that Unix (BTW, I consider all unixes, whether Linux, RedHat, SunMicro, HP, AIX (IBM), BSD (personally I use FreeBSD . . .started years ago with AT&T SVR3), and others) . . .all incorporate a rather sophisticated permissions system that grants read-write-execute permissions at three different levels, i.e., owner, group and other-public (this is a non concept to windoze). Regardless, you can lock-down access to file system by configuration of the times-three combinations of user-group-other/read-write-execute permissions. So, Drupal's permission systems may be somewhat "overkill" on a Unix server, but then again, better to be over protected than exposed. (Also, I'll concede that this is an over simplification of the power of Drupal, too.)

Regarding your comment,

+ if you're using .git as your CVS and you're using eg. the sites/default/files/* folders as your public & private files these folders will automatically be excluded from .git tracking.

. . .actually, I use FreeBSD ports and Package system rather that going to a GIT Hub. There are almost twenty-six thousand applications, i.e., ports, there, including Drupal, already "ported" and tested with make files. Never-the-less, I'm not sure what you implied by

these folders will automatically be excluded from .git tracking

May sound strange, but on a need-to-know basis, I just haven't needed to download from a GIT Hub; I just use the FreeBSD Ports and Packages repository (have since early 2000's).

Finally, regarding this:

The easiest way is to do it over the admin UI. This is the path: admin/config/media/file-system

. . .I actually already have specified sites/default/files/ in the Public file system path, but nothing appears in the CKEditor/IMCE UI. ????

Oh, and BTW, I like Keebler Pecan Sandies ;-)

Stefan Lehmann’s picture

Stefan Lehmann commented

. . .actually, I use FreeBSD ports and Package system rather that going to a GIT Hub. There are almost twenty-six thousand applications, i.e., ports, there, including Drupal, already "ported" and tested with make files. Never-the-less, I'm not sure what you implied by

yeah .. nah .. I meant git as a way to save your current state of development. The modules you downloaded and the theme changes you made. It's commonly used to track code changes and also as a way of moving the current or different states of your website onto different servers like development / production servers etc.

I like cookies!

Jaypan’s picture

Jaypan commented

Github is a website that utilizes GIT technology. You don't download from github, you create a local respository, then you can maintain it on github as a centralized location if you want. I personally don't use github, I maintain my own centralized repositories on my own server.

The FreeBSD packages you are talking about are different. They are for getting the initial version of Drupal, but they will not maintain the changes you make (the modules and themes and any customizations you add) for your specific Drupal instance.

It's worth the time to learn GIT. It allows for branching code, so that you can work on multiple branches all at once without conflicting, merging in your changes when ready. It allows for reverting to any previous version of your code with a single command as well, so if you make changes to your system and find they break something, you can instantly revert. And GIT tracks all your files, so if you get hacked, you can instantly see which files have been changes, and revert them (and/or delete untracked files that hackers added) with a couple of keystrokes.

On top of this Drupal.org and all the modules and themes on it are heavily integrated with GIT. So if you are going to be using Drupal, it well serves you to also be using GIT.

rtwingfield’s picture

rtwingfield commented

I have to admit that github is a relatively new "realm" for me. I used to regularly use the CVS system for updates and maintenance. As I previously mentioned, on an need-to-know basis, I haven't needed to know . . .but probably need to. Your recommendation,

It's worth the time to learn GIT.

noted. FYI, I have re-engineered and implemented legacy source code control system such as

I was called back for a sixty-day project to design and implement a complex extension of the UNIX SCCS (source code control system).

(from my seriously out of date resume') . . .Additionally a somewhat similar checkout and lock-object for IBM's AS/400 system. . . .so much has changed.

BTW, for Stefan Lehmann, I have changed planes (Quantas . . .great carrier!) in Auckland twice . . .to and from Queensland and New South Wales. Actually flew 172 Cessnas for two weeks touring Australia. Have friends that have flown New Z.

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

Stefan says:
"If you put it into the settings.php file it will be hardcoded and can't be changed over the UI anymore. That doesn't necessarily have to be a bad thing you just have to be aware of the advantages / disadvantages of each method.

The easiest way is to do it over the admin UI. This is the path: admin/config/media/file-system"

I think things are slightly different between Drupal 7 and 8. I'm pretty sure that Drupal 8 defaults to setting the public file system path to /sites/default/files. When I checked out my settings.php file earlier I noticed that I had that line commented out yet Drupal still was using sites/default/files.

Drupal has its own way of doing things. I'm not sure at all that setting symbolic links as a work around will work. It's entirely possible that somewhere deep in the IMCE code it checks the settings.php or in some other way checks out what the public path is and uses that. I do know that when I was fighting with Drupal to put my public path somewhere else IMCE was not picking up the files I wanted to access and that when I gave in and just put my files "under" sites/default/files then IMCE could find them and let me use them.

I don't see any reason why other applications on your site should not be able to access files in sites/default/files either. They are all in the public_html directory after all.

On the other stuff, git etc. I'm older than any of you. I did some development work on a different CMS a decade ago where we used a SVN. Drupal development and GIT are a whole different cup of tea that I don't choose to sip on. I just want to run my personal web site using production ready code when the Drupal developers release it.

rtwingfield’s picture

rtwingfield commented

When I checked out my settings.php file earlier I noticed that I had that line commented out

. . .yes, I noticed that, too.

I'm not sure at all that setting symbolic links as a work around will work.

. . .I'm going to try an experiment without using a sim-link.

I don't see any reason why other applications on your site should not be able to access files in sites/default/files either.

. . .valid point, but as I previously mentioned, I would prefer to have a general purpose "in-box" for all objects that may be shared with Drupal, as well with other applications.

I just want to run my personal web site using production ready code when the Drupal developers release it.

. . .exactly my sentiments, too. I just want it to work ;-)

As soon as I complete the test without the sim-link, I'll report back.
. . .this is just going from bad to worse. Still working on it.

rtwingfield’s picture

rtwingfield commented

I've had dubious success with the IMCE module installation and functionality. One thing that puzzles me is this path to where the image is actually stored.

Why the following: ./sites/default/files/sites/default/files/default_images/DSC_0057.JPG

Seems unnecessarily redundant that ./sites/default/files points to yet another ~/sites/default/files/ on it's way to ~/default_images

At one point yesterday, I stumbled onto a configuration that enabled IMCE to actually display files in ./sites/default/files/ and additionally the sub-directory of ~/ar001 etc. on down. Later, I don't know what I did, but IMCE lost that ability.

. . .tried to include a .png image from my PC here. Didn't work. How do you do this?
Only local images are allowed.

Stefan Lehmann’s picture

Stefan Lehmann commented

Maybe you changed the global file directory and that confused IMCE? No clue.

The default_images path makes kind of sense, as in Drupal most images get post-processed anyway to be displayed in a scaled size to minimize the payload of a rendered page. So hiding the original images, which in most Drupal websites get never really displayed .. makes kind of sense I suppose.

I like cookies!

rtwingfield’s picture

rtwingfield commented

The previously specified "DIRECTORY PATH" in Home » Administration » Configuration » Media » IMCE was deleted . . .don't know how or why, but I replaced with sites/default/files and more or less, all is well.

Still need an explanation of that previously mentioned pretzel-logic path.

Also, . . .been reading /www/drupal7/sites/all/modules/imce/README.txt. Not much help . . .written by someone (the programmer) who already understands the system.

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

The previously specified "DIRECTORY PATH" in Home » Administration » Configuration » Media » IMCE was deleted . . .don't know how or why, but I replaced with sites/default/files and more or less, all is well.

Still need an explanation of that previously mentioned pretzel-logic path.

I'm pretty sure the "pretzel-logic" is the result of a number of modules and programs within Drupal using the public directory in their own way. Beneath my "public" directory (/sites/default/files), I have 16 top level directories. Many of them go quite a number of levels deep before they get down to the actual image files. For instance, /files/styles/thumbnail/inline-images/riverbank.jpg. And other types of files are stored in public too, an entire directory of js (javascript) files for instance.

Part of the issue (I think) is that Drupal allows you to specify styles for image type files. I'm pretty sure this only has an affect when you are defining a content type and include a field that is set to field type of image. You can then specify a style for that image ("thumbnail") in the path above and when you upload to that field the file will get sized appropriately and place in that directory. Which is cool in a way: the browser won't have to resize it. But, if you are messing around with a body field and using ckeditor to add an image to it, there is no way to specify a style or size to it ... at least without going to source view and hacking the codes a bit (I'm talking Drupal 8 here). Adding the image via IMCE as opposed to the ckeditor image button does allow you to size it, I think. There is a proposed patch to ckeditor code and an experimental type module to allow a style to be wrapped around the image, but when if and how it will hit the core code in Drupal 8 is anyone's guess.

At any rate, without going too far off topic, it seems like IMCE at least lets you step around the various parts of the pretzel and reuse your files and that's a good first step.

Finally, just to reiterate the "pretzel" part, I was exploring my public paths just now in cpanel file manager. I have one like this:

public_html/drupal8/sites/default/files/styles/large/public/core/modules/image

and beneath that /image Drupal created a sample.png file. This is nuts, but when it will be rationalized is anyone's guess.

Jaypan’s picture

Jaypan commented

This is nuts, but when it will be rationalized is anyone's guess.

There's nothing to rationalize. Image styles all makes sense when you understand why they are done the way they are.

rtwingfield’s picture

rtwingfield commented

. . .then why do I find the following redundant directories?

./sites/default/files/sites/default/files/

/usr/local/www/drupal7/sites/default
drwxr-xr-x  14 www   www     1.0K Apr 29 14:43 files

The permissions for both instances of ~/files are exactly the same, i.e., 755
. . .so what's the point?

/usr/local/www/drupal7/sites/default/files/sites/default
drwxr-xr-x  4 www  www   512B Apr 29 14:33 files
Stefan Lehmann’s picture

Stefan Lehmann commented

. . .then why do I find the following redundant directories?

That's definitely not correct behavior. Something's messed up in your configuration. Normally you should have exactly 1 public files folder.

I like cookies!

rtwingfield’s picture

rtwingfield commented

I haven't totally ignored this discussion, but I've been distracted with the issue thread (started by me) at Put a note on the blocks admin UI explaining that setting block visibility by role does not automatically grant permissions to a given block

Back on this topic:

RE: Stefan Lehmann,

That's definitely not correct behavior. Something's messed up in your configuration. Normally you should have exactly 1 public files folder.

. . .this really concerns me -- I assure you, that I did not create the directories. I have no idea. I would NEVER create a path like that!

I have to ask, what problems may be expected? How would you clean this up?

RE: Jaypan,

Yeah I don't use Drupal 8 yet and won't for at least another 6 months

I understand and appreciate this scenario. I also wait for new releases of OS'es (e.g., FreeBSD) to mature before buying the ticket for the latest bus. Exactly why I started my Drupal experience with v7.

I have to add, this whole CKEditor/IMCE module interface is proving to be a real pain. Until just this afternoon, the browse server function was working . . .at least as far as seeing images loaded into ./sites/default/files/sites/default/files/default_images/. I browsed my local PC workstation, uploaded an image file (a jpg) and the IMCE browser found the file, and I inserted it into a block content. So, I decided to FTP an image file to the same directory, just for a test . . .now the browser function is not working! I deleted the FTP'd file, and still not working.

This is just awful____ but then again, there is this redundant path of directories, /www/drupal7/sites/default/files/sites/default/files/default_images What generated the second set of sites/default/files/? . . .got to be some configuration setting . . .somewhere?

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

While I'm using Drupal 8 and you are on 7, there enough similarities that I'd have to think your problem stems from:
/www/drupal7/sites/default/files/sites/default/files/default_images

how that duplicate path got there is a guess. In my system at:
drupal8/admin/config/media/file-system
I see:
"Public file system path
sites/default/files
A local file system path where public files will be stored. This directory must exist and be writable by Drupal. This directory must be relative to the Drupal installation directory and be accessible over the web. This must be changed in settings.php"

and in settings.php I have an uncommented line:
$settings['file_public_path'] = 'sites/default/files';

This setting determines what you see in /admin/config/media/file-system (or whatever the Drupal7 equivalent is.

On my system IMCE sees thousands of FTP'd files with no problem.

Slightly off topic but based on your previous comments you might want to look at:
http://janezurevc.name/media-entity-reaches-8-x-1-0

It (together with reading some of the links in it) indicates that the core Drupal wizards recognize the limits of requiring your media files to be in a public directory several levels deep in your Drupal site and are working on solutions. I don't think its quite ready from prime time in Drupal 8 but some version may be available for 7.

rtwingfield’s picture

rtwingfield commented

I'm going to take a look at my config files, your suggestions, etc., and look for something that jumps off the shelf. This is just crazy. IMCE was displaying the file-found hierarchy. I FTP (third party CoffeeCup Direct FTP) a file to the directory of files visible to IMCE and now the IMCE browse function is no longer available. I simply delete the file using the Unix CLI # rm file.jpg command. Still no more IMCE browse function . . .just solid gone.

By the way, I've learned that a symbolic link to a physical file (for example) /www/ar001 from ./sites/default/files/ar001 works with regard to /www/Drupal7 seeing the files in the external directory, i.e., not under /www/Drupal7, but IMCE would not follow the sym-link to individual file objects; however, it would display the directory structure. This is so Microsoft-esk. Regarding the sim-linked directory and objects, Drupal7 will serve content objects (.pdf, .jpg, etc.) from that physical directory. Why not visible to IMCE___???

rtwingfield’s picture

rtwingfield commented

RE: (from fkelly)

in settings.php I have an uncommented line:
$settings['file_public_path'] = 'sites/default/files';

. . .unfortunately I find no such argument specified in my version (v7) of ./sites/default/settings.php;

however, drilling down through the following admin/configuration hierarchy, I have
Home » Administration » Configuration » Media » File system » Public file system path » [sites/default/files]

To my knowledge, this is the only place where either I or the system has specified that directory path.

Does/did the system (v7) assume that string value as an implied default and then take the value as entered and compound the parameter as sites/default/files/sites/default/files ? At this point, I don't remember if that argument-parameter value was auto-generated, of if I typed it in the field.

Stefan Lehmann’s picture

Stefan Lehmann commented

/sites/default/files/sites/default/files/

That path is clearly messed up. The standard public files folder is:

/sites/default/files

I really can't tell you why your paths are so messed up without having a look into the website, but I assume, that you're defining "sites/default/files" in two places, although it only has to be set in this screen here:

admin/config/media/file-system

If you entered the same path somewhere else it's probably wrong.

I like cookies!

rtwingfield’s picture

rtwingfield commented

Continuing from this post, if the reason for the redundant path can be determined and corrected, then how could the hierarchy be cleaned up? Can it be as simple as wholesale copying everything from the lower 4-6 directories to the 1-3 directories and then deleting 4-6

...1.....2.......3         4.....5.......6 
[./sites/default/files/]  [sites/default/files]
Stefan Lehmann’s picture

Stefan Lehmann commented

Backup and try? :-)

I like cookies!

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

I was curious about the difference between the settings between Drupal 7 and 8, so I googled "settings.php and public file path" and got this:
https://www.drupal.org/upgrade/file_public_path
Which explains part of the discussion we've been having here. Under Drupal 7 you set the path in admin/media, under Drupal 8 it is set in settings. So you'd need to go into your admin screens to set your path in Drupal 7. I'd back things up from 4.....5....6 as you call it and make a copy into 1....2....3 and see if you can get rid of the redundant path. Probably just delete the extra path and see if that fixes it. Again, it's just me, but if that doesn't work I'd probably phpmyadmin around in the data base and see if there are any mysql records with the extra part of the path. Oh, the Drupal purists would hang me for that but so what.

edit ... I spelunked around in the database in Drupal8 and don't see anything. There are several config records for IMCE though. Which made me wonder, if backing up and an admin/media reset doesn't do what you need maybe uninstall IMCE and reinstall a fresh version. ?

rtwingfield’s picture

rtwingfield commented

Sometimes, I get the impression that we're supposed to know all of this by osmosis.

From fkelly:

I'd probably phpmyadmin around in the data base . . .the Drupal purists would hang me for that

. . .yeah, here's a quarter . . .call someone who cares.

From Stefan Lehmann:

Backup and try? :-)

My attitude's always been, "When in doubt . . .do something___".

Well, OTTF.

fkelly12054@gmail.com’s picture

fkelly12054@gmail.com commented

with a path like:
public_html/drupal8/sites/default/files/styles/large/public/core/modules/image

for an image style Drupal may be rational for a developer (after all it's an image style and the image module is in /core/modules/image) but it leads to confusion for users and site admins. Having images stored in directories corresponding to their style is a rational idea and having them all be in a public area on the site is helpful too.

But overall image handling as part of content is deficient in Drupal. In the new Drupal 8 with integrated ckeditor you can't even associate an image style with an image within the "body" of an article. I may be mistaken but I believe that the media module for Drupal 7 was intended to plug the gaps in this but reading the issue queues it seems like it's a long way off for Drupal 8.

Probably as users and site admins we should not even have to be concerned with the file paths. Images should be treated as assets and there should be a file browser that lets us upload new images and see any images we've already stored. IMCE does this to some extent but it still has to traverse the crazy quilt of file paths built into the public path of Drupal

Stefan Lehmann’s picture

Stefan Lehmann commented

Drupal 8 is still pretty new and functionality gaps might still be there for a wee while. Until then I'd recommend to either use D7 or swallow the bitter pill, that not everything might be possible by just installing a module, as not all modules have made the version jump yet.

I like cookies!

Jaypan’s picture

Jaypan commented

Yeah I don't use Drupal 8 yet and won't for at least another 6 months, probably more likely a year.

And yes there is something messed up in your configuration with those file paths

As for the image styles, you shouldn't be uploading files to the styles folder. They are automatically generated from the original image.

rtwingfield’s picture

rtwingfield commented

I don't understand this forum -- I wanted to respond to a couple of response posts___
(see here)

rtwingfield’s picture

rtwingfield commented

Probably as users and site admins we should not even have to be concerned with the file paths. Images should be treated as assets and there should be a file browser that lets us upload new images and see any images we've already stored.