jason9j

I haven’t had the time to address this during the last couple of weeks. But I too need to get it sorted so I guess it’s ticket time. Makes sense to stick with ACF for this plugin.

So who fixes this now, SCF or ACF? Both? New version of ACF that is required to continue with the original probably hasn’t fixed it (an issue because only the latest version is provided for download), and I get the sense that SCF probably won’t fix this for a while with everything going on. So I’ll just leave ACF 6.5.3 on the sites… Quite ironic, given the security talk. I’ll look to report a bug over at ACF website.

I just changed to 6.3.5 and everything works now. I’m no expert but it seems to be a bug with shortcode enabling/registration in 6.3.6. I’ll wait for the next version before I upgrade again.

+1

I’ve created a new site, modelled off an existing one with the same ACF settings, fields, plugins, etc. For some reason, ACF shortcodes will not work on the new site, which has had 6.3.6 from the very beginning (i.e. no rollback option for me to test 6.3.5). I’ve enabled ACF shortcodes in functions.php and tried every other sort of snippet relating to enabling shortcodes there is. Nothing works. Standard shortcodes work, ACF ones do not.

Hi Sybre – thank you for your comprehensive reply. I have sent you the details directly and really appreciate your assessment of what is happening. Many thanks.

Just an update – I was never able to figure out how to change the submission date format. Nothing I tried worked, and I couldn’t glean the answer from that documentation….

Thanks, much appreciated. It could have been a linux-specific issue, though the browsers are standard, common browsers.

Definitely issues caused by the specific fixes listed in the 2.5 changelog (heading spacing, heading colors, z-index, etc). I rolled back to the previous version of Spectra and the issues are gone.

Yes, there seems to be a number of Spectra-added overrides recently relating to color, heading margins, z-indexes – looks to be a decent sized bug that has changed the look and readability of my sites entirely. The Spectra team is the very best – I am sure they will release a fix very soon. Would appreciate any updates.

Thanks for your reply. I’ve spent a few hours on this now and can’t seem to get it right. The submission date format in the redirect URL doesn’t change no matter what code I use. What follows below is an example, but I have tried many different variations of it. I have also used the own shortcode method, likewise trying many variations, but no shortcode ever became available for me to use, and typing it in directly didn’t change the format.

function change_submission_date_format($submission_data) {
  $submission_data['submission_date'] = date('YmdHis', strtotime($submission_data['submission_date']));
  return $submission_data;
}
add_filter('fluentform_submission_data_before_insert', 'change_submission_date_format', 10, 1);

I will save you from viewing all my coding attempts for both methods! Note that I am not really a coder, just trying to piece it together from the documentation, but all I need to do is specify date/time formats.

Can you please let me know what is wrong with this code?

Another issue is that for the general date picker inputs I have, for user friendliness the date format that the user works with needs to be different to the way that information parses in the redirect URL. For example, even though the URL itself needs the format 04/14/2023 to work, the datepicker needs to at least show it as 14/4/2023 (this is the way people read dates in my country), and even better would be Friday 14 April, 2023 to make it user friendly. Of course, the system needs to read a different format in the URL to display information.

Finally, if there are two date pickers, can the second one’s selection ‘start’ from the selection of the first one, to save potential scrolling through months/years again?

I am having this problem too – never had it before on many other websites. I am the administrator and cannot dismiss this notice. The x click does nothing…there must have been a change lately?

EDIT: I played around with some plugins, deactivated in certain order. Got it to dismiss, reactivated, etc.

• This reply was modified 1 year, 9 months ago by jason9j.

I know you must be busy, but how are we going with this issue? Any plans to fix this in the coming weeks, months, years…? I fear this resolution is as illusory as eWay’s Apple & Google Pay feature. This whole solution is falling far behind the rest. Hopefully there are some development ETAs by now…?

Thanks for your reply – I appreciate your honest evaluation and update.

But herein lies the problem with eWay putting their fate in the hands of a third party with other interests. eWay need to create and manage their own plugin so fixes can be a priority.

I have the exact same issue and it is causing big issues for us. This thread was closed over a month ago – was it fixed? I’m still getting the same error.

Thanks for your explanation.

One last thing I’d appreciate an understanding of:

What is the difference in benefit between using a 365 email account via ‘Other SMTP’ (i.e., smtp.office365.com, 587, TLS, username + password, etc), and doing it via the specific 365 Azure API method (which doesn’t work in this case)? The ‘Other SMTP’ is much simpler, works without any issues – so what is the benefit of the more complex 365/Azure integration, especially given that it is not recommended for bulk marketing email sending?

Thanks again.