Conversations broken for file attachmnets

My first attempt at using the Conversation Block. When attaching a file to the post, I get these weird, big checkmark and X below the file name which I don’t quite understand but then when I Submit the post, the attachment doesn’t show up. The Logs report ‘undefined variable $paragraphPadding’ in line 104 of \concrete\elements\conversation\message.php.
I fixed it by adding " ?? ’ ’ " to the code.

What are those big icons supposed to be for? They have titles/labels of “Check” and “Error” when hovering over them. Why are they there?

1 Like

Hi @mhawke - can you plug in some screenshots? Does seem weird. Are you doing any overriding?

This was broken out of the box. And it does it on a raw local install of 9.3.7 and I just updated that one to 9.3.9 and it still does it. These big icons display after I add an attachment but before submitting.

I can confirm that conversation block is somehow broken.
It was running fine before v 9.3.7

@mhawke

  • did you add .pdf extension in the block dialog?
  • if Bedrock is NOT used in your theme, you might need to uncomment the CONVERSATIONS feature in pagetheme, otherwise Bedrock defaults are applied.

Also still no solution on saving the image into another folder than the first level folder of filemanager.

I’m using Atomic. But this happens in Elemental and the newest Stucco theme that’s been ported to v9. Neither of those two make any mention of Conversations in their page_theme.php file. I have added .pdf to some of the blocks as I’m experimenting but these icons appear straight out of the box. I’m not clear. Is PDF causing a problem or is it a solution to the problem?

What you’re suggesting is that I abandon my futile attempts to make any progress on a core feature cuz it’s crippled and will lead to nothing but more frustration?

This may be an unrelated problem. Conversations will break for any Captcha other than default.

I’m not using Captcha since my use is for logged in users only but I think I’ll bow out of using it. I’ve spent way too much time pulling my hair out on what should be a fairly simple thing.

Those are supposed to indicate whether the drop zone file attachment was successful or not (adding a file fires an AJAX request to /index.php/ccm/frontend/conversations/add_file), but clearly the formatting on them has broken.

The other error in the logs ($paragraphPadding) seems to be specific to some setting or filetype you used, so we’ll need more information on that one. Using 9.3.8, I added the block and then posted a comment with an attached .png and it uploaded without issue (other than the lack of formatting on the icons).

Can you provide more details about your setup?

I’ve created this issue to track progress on a resolution.

A possible interim workaround might be to add the following line to the Header Tracking Codes section of your site to bring in some CSS which looks like it might help:

<link rel="stylesheet" href="https://unpkg.com/dropzone@5/dist/min/dropzone.min.css" type="text/css" />

Then you’ll get something that looks like this:

Yes, that fixed it to my liking. I wish I could add more than one attachment per post but ‘baby steps’.

I tried adding

use Concrete\Core\File\Upload\Dropzone

to the core-conversation’s controller hoping that would pull in the dropzone.css but alas, no.

multiple attachments work for me, but if they are larger than the set maximum, it looks like they are silently rejected. Try checking these settings:

Yeah, I was triggering the multi-upload process wrong. I was clicking on the ‘Attach files’ button a second time to instigate the upload process rather than clicking in the “Drop files here to upload” box. Once you upload one attachment, the prompt to “Drop files here to upload” doesn’t show anymore so it’s not intuitive. Choosing multiple files all at once works but that kind of thing is not a certainty with lots of upload schemes (and didn’t work before Dropzone was added) so I never tried that way. Failing silently = bad.

1 Like

yeah, I agree with that sentiment. Hopefully failing silently will be addressed with the correct CSS and JS fixing the root issue. That little CSS hack above might not even be the right version, it’s just something I was able to whip up quickly. I’m surprised it worked as well as it did, to be honest!