Search

Try this https://github.com/jonmifsud/filemanager/commit/dfda0d0ebac0a1cbdb81769ad97c9312026b9952 I had managed to fix it for 2.3.1 though haven't tried on 2.3.3 yet.

Have to clarify this: please report bugs related to 2.3.2 to github and I'll do my best to help.

@gunglien wow, that's a nice find. The FB::log should be long gone though… strange thing :)

[Edit]

holy cow, my code is a timebomb… :)

Hi, does status "deprecated" mean that filemanager is dead ? I use it in quite alot of projects with symphony. It is also favored by other people and customers. Is there something similar or do you have plans for another extension like this ???

Thanks for answer.

@iwyg, there are more FB::log around the code however only that one gets triggered, however was not sure what it was standing for so didn't bother removing/asking as I didn't know it was deprecated.

@wyrm no it wouldn't mean that it's dead, just the person who was currently maintaining it does not have the time to continue doing so. As long as people are using it someone will do the required updates.

When I'll update my local install I'll check what works and what doesn't and submit a pull request.

OK. Thanks. I will try to use it on some site I am preparing. There will be symphony 2.3.3 and i will see and let you know about it.

does anyone know why the filemanager would 500 after it's gotten the relevant information to know which field maps to which folder? This seems like a server setting, but I don't remember how i fixed it last time.

Symphony 2.3.3 Filemanager 1.0.9

The only error I'm seeing is this JS one:

Uncaught TypeError: Cannot read property 'replace' of undefined 

Which point to this the message reference for html: message.replace(Symphony.Language.get('at') + ' ', ''),:

item = $('<p />', {
    html: message.replace(Symphony.Language.get('at') + ' ', ''),
    'class': type
}).addClass('notice active').symphonyTimeAgo();

from /symphony/assets/js/symphony.notify.js

Also, I tried making the folder permission completely open but that didn't even do anything.

sure you have the latest commit installed? https://github.com/iwyg/filemanager/commit/aa02863c3e8f63f6a2e2c08f9b1a7704db68af4b

It's not tagged with 1.0.9, however should update flawlessly via git. Remember I do not actively maintain this repository anymore.

@iwyg - that didn't solve the problem. I'm getting this error when it's hitting this endpoint:

/symphony/extension/filemanager/listing/?field_id=###

any clues on where to check? I'm getting a valid json response back (ran it against jsonlint.com) but am still getting a 500 (internal server error) message. I'm really baffled as to what happened b/c I haven't updated this symphony version nor the filemanager at least in a long time, if ever.

Hitting the settings endpoint before the listing endpoint works completely fine.

Well, if you're getting a 500 response, you should be able to read the response body from the network tab in devtools. Might get you a better clue what's going on.

this is the response body:

    {
    "show_column": "no",
    "id": "299",
    "label": "Image",
    "element_name": "image",
    "type": "filemanager",
    "parent_section": "52",
    "required": "no",
    "sortorder": "5",
    "location": "sidebar",
    "field_id": "299",
    "destination": "/workspace/images/recipes",
    "exclude_dirs": null,
    "ignore_files": null,
    "limit_files": "1",
    "allow_file_delete": true,
    "allow_file_search": false,
    "allow_sort_selected": false,
    "select_uploaded_files": "0",
    "unique_file_name": "1",
    "allow_file_move": false,
    "allow_dir_delete": false,
    "allow_dir_move": false,
    "allow_dir_create": false,
    "allow_dir_upload_files": true,
    "allowed_types": "(application\/pdf|image\/jpeg|image\/png|text\/.*)",
    "display_mode": "preview",
    "max_upload_size": 5242880,
    "exclude": [
        "/workspace/data-sources",
        "/workspace/events",
        "/workspace/pages",
        "/workspace/translations"
    ],
    "HTTP_STATUS_ERROR": {
        "message": "Cannot access {$file}",
        "context": {
            "file": "recipes"
        }
    }
}

I couldn't really decipher much of what it was trying to tell me. Not really sure where this is pointing to exactly. Perhaps, context.file: recipes is really pointing to /workspace/images/recipes which would then fill out {$file}? If so, does that mean that it simply can't open the directory and access its files? I've put unlimited access to these folders (777) on my local and it's still getting this error. Obviously I can't do that on my production server, but even if i give it 775 permissions, it's the same thing.

This had been working fine for a while, so I'm not sure how this would have gotten screwed up otherwise.

Check permissions on the jit image recipes files.

"HTTP_STATUS_ERROR": {
    "message": "Cannot access {$file}",
        "context": {
            "file": "recipes"
        }
 }

i ended up deleting that recipes file and upped the permissions for the jit image folder as well as all my images folders that are trying to be accessed, but my prod site still didn't do anything. My local site worked fine. Also, my prod site is giving me the default 500 error page that is installed on the server and no useful error messaging for me to further debug.

is there some sort of limit on how many files it can handle listing out or something? I'm really at loss at this point.

This site is on dreamhost and it seems to give a default 500 error page, does anyone know how I could get the ajax error response instead?

bah this is so annoying b/c this has been working for months and now I really don't know what happened.

To make things even more confusing, i have a staging site on the same server and it's working completely fine, even without the recipes file permission change.

Could spaces, ampersands, and percentage signs in a file name cause any issue?

i tracked down the problem.

In filemanager/lib/class.directorytools.php#getMimeType - it tries to execute a shell command with the backticks:

    if ($mime = @`file --mime-type $file`) {
        return preg_replace("/^.*:s?/","",$mime);
    }

It seems that this is extremely slow on dreamhost (could possibly be the shared hosting as well) and so it just ends up timing out with large number of files. But this doesn't make any sense since I had a staging site running the exact same code and i think against the exact same file set, just different domains.

I guess my question is then, what is the purpose of getting the mimetype for these files and outputting them as apart of the json response? Does that get used anywhere after getting the json response back? Does it get used anywhere when uploading a file?

By not calling the mime type method, it seems to be working fine as far as i could tell.

Are you running like php 5.2? finfo_open is standard since 5.3, so the shell fallback should never be executed

no, it's 5.3.x.

I'd contact your host and report this issue.

Hi iwyg, thanks for this great extension.

Note: with Symphony 2.5 some js where moved to a sub folder, so the extension need a small change to work properly :

Modify the file: extensions/filemanager/assets/js/filemanager.init.js

Replace: orderable:"../../../../symphony/assets/js/symphony.orderable"

With: orderable:"../../../../symphony/assets/js/src/symphony.orderable"

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details