Alvaro Gois dos Santos

Hi,

Not sure if it’s the best (or right way) but I was able to do it (at least I think I did) thanks to the help of… ChatGPT.

The answer was not exactly right but it put me in the right track. It seems that GetPaid is already prepared to listen to URL parameters, so, all I had to do was code the Contact Form 7 redirect with the exact URL parameters names, compatible with GetPaid payment form fields.

I had to fire this script in the Contact Form 7 form page.

In this example, the JavaScript code is wrapped in a function that is attached to the wpcf7mailsent event using the addEventListener method. When the event is triggered, the function is executed and the user is redirected to the specific page with the URL parameter for the “fname” and “email” fields.

Note that, in the example, the querySelector method is used to select the “fname” and “email” fields in the form. This method uses a CSS selector to target the field, so we can modify the selector to match the field name or ID that we’re using in the CF7 form, and make it compatible with the GetPaid form fields.

Let me know if I’m doing it wrong.

Thanks!

PS: Sorry for using this thread with something that is not specific to GetPaid but rather Contact Form 7 related. But I guess it may come in handy for someone with similar issues.

Hi,

Not sure if this is the way to share the log. Let me know if it’s OK.

I do use Lazy Blocks to build custom blocks, and it was working fine until a few days ago.

I don’t believe I made any changes besides updates. (I was naive enough to trust that the staging site update was fine. I should know better.)

Thanks for your help.

So I have to look elsewhere. I do sometimes see an odd admin notification about JavaScript not being active, which is false. I wonder what’s blocking the whole post from updating?

Gutenberg seems yet too capricious.

Thanks.

Yes, definitely doesn’t look like that:

<!-- wp:lazyblock/curso-datas {"lazyblock":{"slug":"lazyblock/curso-datas"},"blockId":"10Nqd6","blockUniqueClass":"lazyblock-curso-datas-10Nqd6"} /-->

JSON export of that specific block.

Thanks.

• This reply was modified 1 year, 7 months ago by Alvaro Gois dos Santos.

Also, doesn’t this make this fields less compatible with other plugins (or code) that are fetching that data?

Thanks.

Hi,

So, this is expected?

I’m having an issue where those values aren’t being updated, I was wondering if it was something with this.

Thanks.

Hi @propovoice,

Any idea if this (and/or when) will be available?

Thanks.

Hi @kimmyx

Sorry for the delay, I was unable to test the issue for a while. It seems not be happening when using Firefox. So I guess it’s some Chrome extension that’s causing the issue. I don’t see any console errors related to this.

Thanks.

Hi Peter,

Great!

As to the performance, I’m sort of a slow reader, I’m afraid I would easily miss that boost. But it does load really fast. Congrats!

Best,
álvaro

Oh, I see it, it’s a Premium feature.

I’m missing a search option in WPDA docs.

Thanks.

Alvaro

Hi Peter,

I did manage to create a publication table from my View but I don’t see any export actions. Just the search input.

What am I missing?

Thanks.

Alvaro

You’re welcome @bluejay77

Hi @prd689,

I apologize for intruding on this topic but it’s a situation that has already occurred to me and I have a suggestion that is relatively simple and with little impact on server processing.

You can use WPT Custom Mo File plugin and upload a .mo file with the customized terms.

Let’s say you want to change every quote and quotes for proposal and proposals. Download the current .po language file for Jetpack CRM and edit it with POedit, for example, to change “quote” and “quotes”. Then, upload the resulting .mo file to WPT Custom Mo File and every instance will be translated as you wish. You don’t need to change the plugins language files, and that customization will withstand plugin updates (unless the base string is changed, of course).

I’m not sure I can add the plugin link here but you can search the directory.

It’s a lighter solution then using a plugin like Loco Translate.

Hi Stef,

I’ve opened a new ticket regarding the issue with the custom fields and API.

Look forward to see the changes in the custom fields CSV format.

Thanks.

Hi @aicee11

I’ve never said I was importing a .CSV file, I was referring to custom fields being saved in CSV format.

The issue was with the fields’ CSV format. Custom fields is a core feature, that’s why I asked here in the first place, in the hope JCRM core had already corrected this issue.

Thanks.