maxxd

You've got single quotes around $semail in your setAddress() call. PHP doesn't parse variables inside single quotes - remove them. And Barand beat me to it...

This is too vague to answer, I think - is the 'undefined' something you wrote in your code? Are you using third party libraries? Post your form and processing code and we'll take a look. My initial thought is that you're doing something like if(isset($_POST['submit'])){ // process the form }else{ echo 'undefined'; } (assuming the submit button is named 'submit') which won't work with Internet Explorer. But that's only my initial thought because it's something that has bitten a lot of developers.

That just made me shoot milk out my nose and I haven't had milk in years. NotionCommotion - yes, just like that. Unless you have a reason to hide the sub-objects interface or you need to do some manipulation before or after interacting with the sub-object, in which case write the pass-through method.

As far as I view it, scope is scope whether it related to methods or properties. Of course, that's easy for me to say because I believe most things should be privately scoped anyway - at least initially. More on that later... The Open/Closed principle (quoting Wikipedia here) states that "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification". Using private (and to a degree protected) methods and properties - the way I understand it, anyway - is the basic building block of the principle. By using public getters and setters, you've created an effective and reliable API that other differently typed objects and classes can use with confidence. So you've got the extension aspect covered with the public API, but by encapsulating the inner guts of the class with private scope, it's tightly closed to modification except where monitored and expected. Personally I thinks it's better to start off with a tighter scope (private), then loosen up on methods as necessary to create your API. As ignace points out in the other thread (this post) if you find you need to give privileged information to a child object, set that information's scope to protected. All that having been said, I am a bit more strident in my belief that properties should be private no matter what. Methods need to be public at times - properties don't. By using a setter method you can validate and control the value before you assign it to a local property, and using a getter method allows you to tailor the response. And yes, it is sometimes a pain to write pass-through methods to sub-objects, but I feel the trade-off in system security and consistency is worth the time. Hopefully this all makes some sort of sense - I'm trying to quit smoking this week and my brain's having trouble keeping up.

Print out records 21 & 77, as well as the value of $first_name. My gut's saying that you're not using the values you think you're using, either in the processing script or the database. Of course, without seeing your full code and data set, it's difficult to know for sure.

Isn't this basically the same question we talked about here? I do realize there's a slight difference, but unless I'm missing something that difference seems extremely small.

@Zane - I'm at the beach in Wilmington. It's rough... 😁

Thanks very much, all - first round's on me, absolutely! 😁

And stop using mysql_* functions. They've been deprecated long enough that commercial hosts are starting to catch up. I'd bet you've got maybe six months to a year before any work you do to make your code work is rendered useless anyway.

IMO, a series of serialization objects is a good example of when using inheritance and protected properties is justified. Have a base serialization factory class that then calls child classes for JSON serialization, normal serialization, XML output, MLS XML, MathML, SuperSpecialUnicorn serialization (I'm making up examples, obviously), whatever. Each of the child classes can then read and modify any protected property on the parent factory class and as long as you program to that parent factory's API you really don't have to care which it is.

Take this in the spirit it's offered, but this code is a mess and really shouldn't be used on a production server. Especially if it's dealing with loan applications and tracking. You're wide open to SQL injection, none of the output is escaped, the queries are inefficient, and the mixing of logic and display is going to continue to make maintenance a nightmare. As to your question, given the fact that you want it to calculate when you select an option, this is a JavaScript question, not a PHP question. You'll need to check the value of the loan amount (which I assume is #original) within the loanamount() function to know which set of values to apply. Read what you wrote to describe the intended behavior - that's great pseudo-code. Now, using a simple if...else construct you should be able to convert that pseudo-code almost exactly as described to functional JavaScript. Give it a go and post what you come up with here.

I'm with ignace on this one - object properties should be private until they absolutely must be made public (which is hopefully never). Protected is better than public, but most patterns these days prefer composition over inheritance so protected is kinda pointless. Having said that, I'm a big fan of the encapsulation aspect of OO so I may be a bit biased. I think Google at one point released a white paper on writing speedier code and one of the things they recommended was eschewing getters and setters in favor of public properties. No, but thankyouverymuch.

Throwing in my $.02 - as far as thorough, understandable explanation of OOP as it specifically relates to PHP I've found this book to be a great resource - https://www.amazon.com/Objects-Patterns-Practice-MATT-ZANDSTRA/dp/1484219953/ref=sr_1_1?ie=UTF8&qid=1526221870&sr=8-1&keywords=php+objects+patterns+and+practice. Some of the earlier chapters may be a bit basic for you given where you stand and the research you've done, but I've actually bought the second, third, and fourth editions (the fifth isn't out in B&N e-book format yet, as far as I can tell) and to this day just pick it up to read on a random basis. I know this doesn't specifically address any of the questions you've laid out above, but if you're looking for an enjoyable read that's also informative, it's worth taking a look.

Ahh. I've not used BuddyPress before, so I'm afraid I'm not going to be of any help on this... Good luck, though!

If I'm reading this correctly, you're looking for user avatars, correct? If so, have a look here: https://developer.wordpress.org/reference/functions/get_avatar_data/ https://developer.wordpress.org/reference/functions/get_avatar_url/ https://codex.wordpress.org/Plugin_API/Filter_Reference/get_avatar On to some of your other points, there are a lot of files involved in a WordPress theme or plugin beyond just the required functions.php and style.css. If the CSS is being compiled on the fly, then I'd have to bet you're using a page builder. There's nothing wrong with that, they're just not my favorite method of theme development in WP for almost this exact reason - they mangle everything in the database with the shortcodes that most use to actually achieve the functionality. That being said, if the avatars are custom or from a plugin, chances are good that those image's locations are stored in the database. If they're default WordPress, they're served from Gravatar and accessible using the user's email address.