Support

March 18, 2021 at 6:30 am

Just checking in to confirm that removing the CSS worked for you?

March 22, 2021 at 4:39 am

Hi Markus,

I’ll try to break down the questions/statements in the video and answer them.

Your developer states we don’t have methods for all of your fields some are custom and some our ‘our’ fields but we don’t have methods for them, this is incorrect, we have methods for all of our ‘system questions’ (because we know they exist) and we have methods which can be used to pull the answer to any custom questions.

The first field your developer checks for is ‘company’.

I checked on your registration form and can see that’s a custom question, so we can’t create a method within the code for a question we don’t know exists (custom questions can literally be anything and are created by the end user, we don’t have them in the code, technically we could create dynamic methods for those by thats not the design pattern we use). So your developer is correct in that we don’t have an $attendee->company() method, because its not a system question we add ourselves but there is still a method they can use to pull the value if they have the registration:

`$registration->answer_value_to_question( $question_id = 0, $pretty_value = true );

The ID of that custom company question is 12, so this:

echo $registration->answer_value_to_question( 12 );

Would output that value.

—-

The developer then moves onto ‘street’, referring to ‘Street, No’ in your registration form and searches for is on the EE_Attendee class.

‘Street, No’ in that example if the ‘Question Text’ of the field, and the question text value is customizable by the user within the admin (Event Espresso -> Registration Form -> Questions -> {Edit Question} -> Question Text) so you can’t rely on those values to search the code for.

‘Street, No’ in that example is the ‘address’ question within EE, you can see this within the page source. Right-click on that field and inspect, take note of the name/ID fields of each input:

ee_reg_qstn[{reg_id}][{question_id}]

reg_id is unique to each individual registration, but {question_id} is unique to each specific question within EE. System questions will use a text string there, fname, lname, email, address, address2, zip etc. Custom questions will use the ID of the question so 12, 14 in that screenshot shot custom questions.

That means for ‘Steet, No.’, you would use:

$attendee->address();

Zip code is a system question that has not had the question text changed which is why he can find it on the class but even if the question text was changes, to get the value for that question you use $attendee->zip();

‘Country’, ‘Address’ and ‘Address2’ are used on your registration form.
County = Your ‘country’ field, above zip.
Address = ‘Street, No.’ field.
Address2 = ‘P.O. Box / No.’

The ‘EE_Attendee’ object does have access to all of the fields on a registration form in itself and there’s is valid reason for that in that an Attendee can have multiple registrations on various events throughout your site. Each of the registration forms could have various different custom questions and collect various data. The attendee is still the same and the core questions (first name, last name, address, etc) all links to the same ‘Attendee’, but a question on the registration form for ‘Event A’ could be totally different from a question on the registration form for ‘Event B’ so those are linked with the EE_Registration and NOT the EE_Attendee.

A lot of this is explained in the model’s documentation which if they haven’t looked over can be found here:

https://github.com/eventespresso/event-espresso-core/tree/master/docs/G–Model-System