Jump to:

7935 Posts in 1536 Topics by 943 members

DataObjectManager Module

SilverStripe Forums » DataObjectManager Module » Bug Reports

Discuss the DataObjectManager module, and the related ImageGallery module.

Moderators: martimiz, UncleCheese, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Go to End
Author Topic: 47797 Views
  • Mat Weir
    Avatar
    Community Member
    33 Posts

    Re: Bug Reports Link to this post

    Hey UncleCheese, I asked you about this a few weeks ago and I'm still having trouble with it.

    In FileDataObjectManager.php line 623:

    $file->OwnerID = Member::currentUserID();


    The file's OwnerID isn't being set.

    After looking at Member::currentUserID I found that the session isn't working, $_SESSION is returning an empty array. But if I access the controller director $_SESSION has its normal data in it.

    I'm not familiar with how swfupload works, but I'm suspecting that perhaps the flash application that uploads the file has its own session (or no session?).

    What do you think?

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Bug Reports Link to this post

    It's a known issue with SWFUpload that whatever session you happen to have active won't follow along unless you send in the session id as a variable and set the session yourself manually. I have no idea how messy this would be to setup in SilverStripe if it's possible at all since you have to do this before SilverStripe starts the session.

    Is there a reason for why you have to do this in the method that handles the swfupload though? Basically you have two chances to hit that file, once when it's actually uploaded by swfupload and you don't have session access and a second time when the form saves through $data['uploaded_files'] if you're using the field in a regular form. Right now I'm assuming you're using it outside of the CMS, inside the CMS I'm not sure when the best time is, onBeforeWrite() perhaps? Maybe you can grab it through $_REQUEST['uploaded_files'] then.

    Let me know if any of that helps. I use the method with $data['uploaded_files'] when I use SWFUploadField in my regular forms outside the CMS and it works great for me, never tried it in the CMS.

  • MarijnKampf
    Avatar
    Community Member
    164 Posts

    Re: Bug Reports Link to this post

    The module is installed in dataobject_manager, however, the DOM CSS code isn't being included in the source file. I tried including it in the init() member of the class Expert extends DataObjectDecorator, but this was ignored too.

    Is there a way to include additional CSS in the Security tab?

  • Mat Weir
    Avatar
    Community Member
    33 Posts

    Re: Bug Reports Link to this post

    Hi Smurkas,

    Thanks, I didn't know it was a known issue.

    I'm not doing anything out of the ordinary here in regards to DataObjectManager and I'm guessing that this has perhaps always been a bug in DataObjectManager.

    I've tried doing it onBeforeWrite(), but as it is still swfupload that has created the request, onBeforeWrite also suffers from the lack of session.

    I can't think of any way to get DataObjectManager to properly save the OwnerID other than to pass the session variable into swfupload like you've said, but I'm not sure how to do that.

    UncleCheese, do you agree that this is a bug in DOM?

    Cheers

  • Mat Weir
    Avatar
    Community Member
    33 Posts

    Re: Bug Reports Link to this post

    If swfupload can upload files without a session, does that mean it's not authenticated in DataObjectManager?

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Bug Reports Link to this post

    I'm not sure how it's done in the CMS but SWFUploadField has it's own controller called SWFUploadControls which handles the actual file upload. When this method runs there isn't a session in the request or rather a new one because of the Flash issue. I understood it as it's during this request cycle that you're trying to act.

    I was thinking that you should act after this has happened. I'm guessing that the file is attached to some other object or page and when the related object is saved then that's when you act. I'm hoping here (although not sure if this is how it actually works) that you'll be able to access the request data to get at $_REQUEST['uploaded_files'] to find out which files that actually were added and then do something with them.

    If this is what you're doing then you do indeed have a real issue on your hands which might be really really hard to solve. I'll do a test case and post back here with my results.

  • MarcusDalgren
    Avatar
    Community Member
    288 Posts

    Re: Bug Reports Link to this post

    Ok I've had a look at it in the CMS (debugging in the CMS is such a chore) and it appears that you are correct. When SWFUpload is used in the CMS and you press upload then it actually saves the related object as well during the same request cycle. When I've used SWFUpload in the frontend it's not how it works, SWFUpload saves first and reports back the id:s of the files and then when the user clicks save the related object is saved (or at least that's how I do it). This means I get two separate request cycles and don't run into this issue.

    This doesn't help you of course and I'm not sure if or how your problem can be solved. If you send along the session id as a custom variable in SWFUpload, maybe you can store the current session id, kill the session, start the session with the session id from the custom SWFUpload variable, do your stuff, kill the session again and then restart the session again with the original id for that request cycle just in case it contains anything important. Use session_write_close() to stop and save the session instead of destroying it.

  • Mad_Clog
    Avatar
    Community Member
    78 Posts

    Re: Bug Reports Link to this post

    Sortable DataObjects are sortable even without create, edit and delete rights within ManyManyDOM.
    Also when manually setting the record to read-only ($MMDOM->isReadOnly = true), the check-boxes behind each record get disabled but you're still able to re-order the DataObjects

    SS: 2.4.0
    DOM: Trunk revision 400

    47797 Views
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.