DustinYoder → created an issue.
DustinYoder → created an issue.
I am willing to work on this if someone can point me in the direction I would need to go to try to make the current page refresh. I'm not sure where to start looking for this. I'm guessing that might be more of a views bug or something. I am still on Drupal 8.9 and a fairly old version of the views module so this might just be a feature request to stop auto refresh on pages > 1.
DustinYoder → created an issue.
I actually found that unsetting the user input for this field works better.
unset($user_input['field_entity']);
This was fixing any issues I was having due to the user input not being formatted correctly. This would just cause the default_value to be used. Would be interested if this works for others.
I am discovering that file fields on inline entity form will not update correctly using this method. I am using a dropdown to select an entity and that causes the IEF to reload via ajax. Then in the form_alter I am updating the #default_value and userInput for IEF field to populate the IEF with that new entity. This works for most fields, but the file fields on the IEF form are going blank. I've tracked it down to the fact that somewhere along the way the user input for the IEF is processed a little bit to make so that there is a '#files' attribute on the file field form, but this must happen before the form_alter, so when I replace the user input with the plain old (array) $entity, in the form alter, then that extra processing is not happening again on file fields in the IEF. Due to that, there is actual input, but it is formatted wrong and so fails to find '#files' thinks it is then empty.
This is the best I could try to figure for how this is going wrong. I'm wondering if I could 'build' the entity form in my form alter or somehow do something to the (array) $entity array before I assign that as userInput to the form_state? I really wish I could sort this out without just hacking the filewidget class to look for this situation and work around it. Any ideas would be great. I guess probably the official answer is that IEF doesn't support this type of replacing the target entity during form_alter ajax, but it probably should work in that direction.
The file upload form element has #limit_validation_errors set to prevent any validation on any other fields on the form. This way you can upload files without getting errors from other fields. This has a side effect of preventing other field values from being in the form_state->getValues().
Print that out on the form alter during a file upload. It will only contain the file field value, I believe. So all your calls to $form_state->getValue() will just be returning null and treated as false. This will cause your form_alter to block access to the file upload field itself. Thus causing nothing to be returned in the ajax result, so the field just gets replaced with nothing instead of the populated file field.
I had this same issue and am still trying to work out what to do to fix this. I think maybe you could check the form_state->getUserInput() to get the current values or something like that. Let me know what the correct solution should be here. How can know if the form alter should be using getValue() or the getUserInput. Maybe just check if value exists before trying to use it. Not sure how this works with checkboxes.
Just thought I'd post because I have this issue and it is quite cryptic to sort out what is happening.
Maybe this exif handling could just be put in core as well? It is never correct behavior to ignore and strip these tags. Especially when this is common when uploading images from iphones.
DustinYoder → created an issue.
So here is a zip file of the completely rewritten module. GaryDev has helped test and do some instructions updating. I am simply putting the code out here in hopes that someone will make a new branch with this. It is not technically Square Connect at this point so maybe just a new module? I just spent a lot of time on this and can't put too much more into it. But it is a shame if it isn't made available.
This module uses the new oauth2 api. The api library changes each month for square, so we might have to update more code in the module. I think we have it set to allow anything after the version I used to build it. But reach out if there issues installing and getting it to work.
GaryDev has now successfully installed and is using my updated Square module for D7. It seems like we have better install docs now and this might actually be usable for others if anyone is interested. It uses the new SDK for Square and did require an complete rewrite of the module.
My version of this module does now seem to be working in my instance fairly well. I fixed several bugs with discounts and tax rounding etc, etc. I'm sure there are more possible bugs, but we are processing something like 5 or more successful transactions each day, so I would consider helping others test this on their site. Probably need to monitor it for a little and just make sure things are working. But I would possibly be willing to help with that for some kind of fee.
I am using it currently but still have two known bugs I'm working on today. I think it is a little rough, but it keeps getting better. Square now requires using discounts rather than negative line items so I had to fix that. I am having some issue currently with the JS on the order payment add form, but am hopeful to fix that today. Some kind of 'await' issue with the multiple 'attach' behaviors that fire. I have only tested with my exact setup so far, however, so probably unstable. But I can see why this hasn't been done already. Almost the entire module needed to be modified in some way. I will try to post when I have it running for a bit with no issues on my customer's site.
I have taken a week and completely re-wrote the Drupal 7 module. It is working with the Square PHP SDK version: "27.0.0.20230517".
It uses the Web SDK at https://web.squarecdn.com/v1/square.js for embedding the form and creating the token. I currently have this working on sandbox with cardonfile and commerce_recurring. It is still rough, but I'm wondering if this would still be considered 'Square Connect' and should I contribute to this module, or where would this go? I have refund, and card delete working. I did not complete void, and I don't think this Square api supports editing an existing card on file.
I would love help finishing and polishing this module and could use help knowing where to put this code because I'm not currently using Git and would possibly contribute it but can't afford to spend too much more time on this. Unless someone wants to help sponsor development to get this completed.
This ended up being quite a rewrite, there is so much that needed to be changed, but my test site is fairly complex, so I think it is probably 80% complete at this point since I needed the cardonfile functionality.
Thanks for the advice.
Have you had any progress on this integration for Square payments? I might also need this, but don't really have time to build it at the moment. We might also be able to help pay for something if we find someone to do it fairly quickly. Thanks.
I guess there is still no way to use Square payments in D7? Just checking if there is any progress on this.