Using a contact form

I don’t see what the problem is referring to an ID in your code.

There’s a difference with an “associated id” and typing magic numbers out in code. I’m sure anyone who has passed programming 101 knows not to use magic numbers.

Technically your username is an “associated id”, yet I can type @jakept rather than #32984729384. Surely you see there’s a difference? I reference a file as path/file.php rather than inode #9238579487543.

I’m not clear why a functions.php that used this featured would be shared across sites either?

That’s how themes work. You make a child theme, you use the theme across sites that need the same features. Yeah you can do workarounds. It doesn’t make it right. And are you proposing that a contact form plugin requires you to write another plugin to get it to work semi-maintainably? Plugins are not only aimed at developers. Normal people should be able to use them.

OOP has been important to maintainably since forever. If I used on_sent_ok it’s saved WITH the form in the database. If I delete the form the on_sent_ok is deleted. It’s maintainable. It’s sane.

If I delete a form without telling you which it was, how will you delete the “if” statement from the php? Will you search every id in the php to see if there’s a form on it? Will you know whether each id appears only once, or more? It’s insane.

Are you seriously telling me you can’t see a difference in approaches? People wrote amazing code in assembly, but I sure don’t want to go there.

Hi Jacob.

Thanks for your time.

If you’re building functionality that you’re going to distribute across multiple sites that interacts with the wpcf7mailsent event of forms that are picked by the users then I’m sure you – expert programmer that you clearly are – would be perfectly aware that any ID in code could be substituted with a variable, and that you could add a field or option somewhere in WordPress that would be used for selecting that ID to associate it with the form.

I’m not a programmer, that is why I don’t want to deal with unmaintainable code. That’s why I’m asking you why it’s a good idea to have a php file that’s tied to a particular database. I cannot imagine why it is better than having all functionality related to a form with the form.

Frankly trying to understand that doco gives me headaches. It seems to be going from a user plugin to a dev plugin.

I don’t have the first clue about adding a variable and all that, but if I were to add a field or option somewhere in WordPress it would be on the plugin page, when I had a form selected. Which is the old functionality. Which has something wrong with it so that we should do it in a php instead.

If you were distributing the functionality across multiple sites, then you wouldn’t be using on_sent_ok anyway because that’s just storing it with the form in the database of one particular site.

I’m not. I have different forms on different sites, that do different things and redirect or do different analytics things. I’m saying I use the same theme across multiple sites, hence I don’t want to put site specific code in a theme file.

Besides, storing code in the database to execute when a form is submitted is hardly acceptable programming 101 either. Hence its removal.

Everything in WordPress is executable and in the db isn’t it? When I have a grid or slider that you can click that is code. Page builders are full of code. HTML in itself is code. I really don’t understand it at all.

If there’s a choice of the cleanest implementation possible by an author, or not having a functionality or having random programming 101 people like me hacking things together, surely the former is better?

Right now you’ve shown me the best outcome is to do more work to make some field that shows on a different page to the contact plugin that links some id to some variable to a php file. It doesn’t sound ‘better’.