Conversations broken for file attachmnets

mhawke · January 10, 2025, 12:14am

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?

EvanCooper · January 17, 2025, 12:22am

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

mhawke · January 17, 2025, 4:45am

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.

CoDa_ZRH · January 17, 2025, 8:38am

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.

mhawke · January 17, 2025, 12:27pm

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?

JohntheFish · January 17, 2025, 1:31pm

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

github.com/concretecms/concretecms

reCaptcha v3 fails to load assets or allow post submission in conversations

opened 12:24PM - 28 Jul 23 UTC

losttheplot

Type:Bug Bug Priority:Medium Affects:Visitors Product Areas:Conversations Bug:Level of Effort:Low

### Affected Version of Concrete CMS 9.x ### Description With a fresh i…nstall of the 9.2.1 codebase, and the site correctly configured for Google reCaptcha v.3, the form added to the 'Contact Us' page displays a reCaptcha badge and passes the submit validation. However, a conversation block added to any page does not display the reCaptcha badge (with the user logged out) and submission of a message triggers the error: "Incorrect image validation code. Please check the image and re-enter the letters or numbers as necessary." Two recent forum posts refer to the same issue without a resolution: https://forums.concretecms.org/t/v9-2-and-recaptcha-display-problem/5844 https://forums.concretecms.org/t/using-recaptcha-v3-with-c5-v9-1-3/5732 ### How to reproduce Download fresh 9.2.1 codebase and install the Atomik version onto an apache server running php 8.1. Configure the site for Google reCaptcha v.3. Confirm that on the 'Contact Us' page, the reCaptcha badge is visible floating at the page foot, confirming that reCapture is enabled. Now visit a blog page and add a conversation block to that page. Log out and note that the reCaptcha badge is not displaying. Try to submit a message and note the error: "Incorrect image validation code. Please check the image and re-enter the letters or numbers as necessary." ### Possible Solution _No response_ ### Additional Context # Concrete Cache Settings Block Cache - Off Overrides Cache - Off Full Page Caching - Off Full Page Cache Lifetime - Only when manually removed or the cache is cleared. # Server Software Apache # Server API fpm-fcgi # PHP Version 8.1.21 # PHP Extensions bcmath, calendar, cgi-fcgi, Core, ctype, curl, date, dom, exif, FFI, fileinfo, filter, ftp, gd, gettext, hash, iconv, igbinary, imagick, imap, intl, json, ldap, libxml, mbstring, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, Phar, posix, readline, redis, Reflection, session, shmop, SimpleXML, soap, sockets, sodium, SPL, standard, sysvmsg, sysvsem, sysvshm, tokenizer, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend OPcache, zip, zlib # PHP Settings max_execution_time - 90 max_file_uploads - 20 max_input_nesting_level - 64 max_input_time - 300 max_input_vars - 5000 max_multipart_body_parts - -1 memory_limit - 2G post_max_size - 32M upload_max_filesize - 32M zend.exception_string_param_max_len - 0 ldap.max_links - Unlimited mbstring.regex_retry_limit - 1000000 mbstring.regex_stack_limit - 100000 mysqli.max_links - Unlimited mysqli.max_persistent - Unlimited pcre.backtrack_limit - 1000000 pcre.recursion_limit - 100000 redis.pconnect.connection_limit - 0 session.cache_limiter - no value session.gc_maxlifetime - 7200 soap.wsdl_cache_limit - 5 unserialize_max_depth - 4096 opcache.jit_bisect_limit - 0 opcache.jit_max_exit_counters - 8192 opcache.jit_max_loop_unrolls - 8 opcache.jit_max_polymorphic_calls - 2 opcache.jit_max_recursive_calls - 2 opcache.jit_max_recursive_returns - 2 opcache.jit_max_root_traces - 1024 opcache.jit_max_side_traces - 128 opcache.max_accelerated_files - 10000 opcache.max_file_size - 0 opcache.max_wasted_percentage - 5 Redis is not being used due to multiple runtime issues.

mhawke · January 17, 2025, 2:55pm

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.

Myq · January 17, 2025, 6:48pm

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:

mhawke · January 17, 2025, 9:45pm

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.

Myq · January 17, 2025, 9:49pm

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:

mhawke · January 18, 2025, 12:13am

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.

Myq · January 20, 2025, 8:42pm

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!