gvh

I just noticed this post, https://www.ads-software.com/support/topic/yoast-seo-20-10-issue/, by Yoast’s devnihil. where he discusses how to preform conflict checks which are often relevant in the sort of issue I reported.

I think it’s best to follow his instructions for now and get back later if the problem actually traces back to the Yoast plugin. At this point I’d be surprised if it did.

Thanks for the fine plugin.

Thanks John

That’s great. I’m assuming that means the files, folders, data, and database tables Redirection installs and or creates. If not let please let me know.

george

Thanks Clayton James.

Yes, that url worked for me. The curl worked and I could also download the zip file by entering the url in my browser. The nslookup of downloads.www.ads-software.com gave 198.143.164.250.

I saw this nslookup result before. But now I also see that the zip file is accessible and waiting on the server for me to download.

Perhaps I should not mark this as resolved. But since I can now see that the zip file is available, I think this problem is most likely not a WordPress issue. Thus it’s probably not within the scope of this forum unless somebody thinks otherwise.

Thanks again Clayton James

• This reply was modified 6 years, 10 months ago by gvh.
• This reply was modified 6 years, 10 months ago by gvh.

I messed around with the code L267-L299 as per your suggestion, but no luck. These lines should be finding my single template just fine. And they do if I just drop the category from the url.

I also briefly looked at the L207-L265 and could not see why the permalinks for urls with categories are causing problems. But there is no way I could write code at that level, even though I can understand what you have written.

I’ve been trying to get these categories out of the urls anyway … urls too long. Who knows maybe they’ll go for it.

But please let me know if you feel this will end up being a limitation of this plugin. I will need to make other arrangements if I end up being stuck with these long urls. But I’ll wait on your response.

Thanks for your help. And great plugin. There should be more like it on the repo.

Thanks. I’ll give it a try. Give me a day and I’ll get back.

Thanks Michael. This one is resolved.

You were right. There were spaces. Every credit card related field had a space before the first letter. I didn’t notice them this morning in the ‘List of Fields’. I had to copy/paste the field content to and editor to see them.

I can use the Options in CFDB to remove all of the columns except one called “Cardholder’s Name”. I have no idea where that ” ‘s ” came from because it’s not in the Gravity Form anywhere I can see. The ” ‘ ” causes the plugin to put a “/” in front of it (I’ve seen this before somewhere else). But I can get rid of the column using your ‘cfdb_form_data’ hook in the php.

Thanks so much.

CFDB definitely has the best support of any plugin on the repo!

Thanks for the debug. Sorry for my slow response.

The ‘List of Fields’ columns shows all of the credit card fields but the unset didn’t remove them.

I noticed that Gravity Forms does not show the credit card fields in their entries ($entry). Could this have something to do with it? Or could I somehow use this fact with the gravity after_submission hook to limit the data CFDB puts in its database to just what is found in $entry? Or perhaps that’s a wild idea.

Thanks for the help Mike. Really appreciated.

Thanks Michael:

Good to know that this should be doable and that ‘Submitted From’ is behaving normally.

I have the spelling and case correct. I can add and unset all my columns easily using your documentation, page_id=747. But the credit card fields don’t work. I know that Stripe tokens are not straight forward to unset as is also the case with session variables. But credit card data in the CDFB database shouldn’t also carry these traits, should it?

Any direction you can give would be greatly appreciated.

Oh yeah. Could you tell me why ‘Submitted From’ cannot be removed?

Thanks again.

Hi.

I tried this.

add_filter('cfdb_form_data', 'remove_field');
function remove_field($formData){
	$formName = 'myform';
	if ($formData && $formName == $formData->title) {
	    unset($formData->posted_data['Card Number']);
            unset($formData->posted_data['Expiration Date']);
            unset($formData->posted_data['City']);
	    unset($formData->posted_data['Submitted From']);
	}
    return $formData;
}

It prevents CFDB from putting the ‘City’ field in the database, but none of the other three. The same is true when you put them in the comma-separated list on the options page.

That fixed it Michael!

Thanks so much. Great plugin. Fantastic support.

Hello Neo_dev.

Can I ask you? Is your problem confined to the situation where there are conditionally hidden fields and showing (submitted) fields that share the same field_name labels? Or does it simply occur on any form with conditional fields?

Also, do you recall the version of CFDB where this last worked.

Thanks for your input.

Sorry Michael. Let me try to clarify.

The form submitted has conditional fields. Some are hidden and some are not depending on the condition. Gravity documentation says that the hidden fields are not submitted, but of course the fields that show are submitted. Among the field, hidden and shown, are 6 fields all named “First Name”. 5 of the fields are hidden. Only one shows and therefore only one is submitted. However, there is no value present in the Contact Form DB. The column header is there, but no value. The query can be seen in Contact Form DB as well.

Thanks

Thanks for the response Michael.

By “no queries” I meant that when I make true the “Show the query used to display results” option, no query was listed for my check box field.

But I just figured out why that was and it now works fine. I had not added a field label to that particular Gravity field and was just using the check box choice label and of course value. When I give it a field label it works fine, and I can hide that if I wish.

I have another question, but I’ll open a new one for that.

By the way. Your plugin is very nice. Thanks

Sorry. I had this badly messed up. You can’t ad fields to the WordPress user profile in the free version.

Thanks Antti. The config file never occurred to me. It’s nice to not have to worry about the updates. I moved the line to wp-config.php, and of course, it works fine from there.

Best

geo