requinix

Moving the logic to a "getProperty" sweeps the problem under the rug: it's still there, not just as visible. I think what I'm seeing here that draws my attention most is using properties for half of the work and getter methods for the other half. Pick one: properties (list properties, check attribute, get value) or methods (interface method to list properties with capabilities and possibly getter closures).

I don't care for it because I don't like dynamic getters as a whole, but the design is widespread enough that I'm not going to protest too loudly. A basic thing like validating an attribute against a property should be done by PHP itself, but since it isn't, If you're looking for advice there, have RankedListAttribute do its own validation: add an interface (or not) and method for performing validation given a ReflectionProperty, then use your ReflectionAttribute to newInstance() and call it.

Reflection, list of properties, list of attributes given that there is no "hasAttribute"... yeah, that's about right. You could streamline the attribute search with a quick array_filter instead of a foreach: $hasAttr = array_filter($propReflect->getAttributes(), fn($attr) => $attr->getName() === RankedListAttribute::class);

I assume you've already searched your code for "MainContinueButton" to see if something added a handler to that specific button? You should know if it does AJAX by monitoring the part of the developer tools that shows you network requests and seeing that a request gets made. If Firefox's is anything like Chrome's then it can also tell you where the request originated from in code. For breakpoints, I don't know Firefox or what it can do. It should be possible to break on any newly running Javascript code, but it's easy for things like mouse movements to hit that too. Meanwhile Chrome's tools can list the event listeners registered on elements.

Set a Javascript breakpoint to stop when that button is clicked, then see what the handling code belongs to.

Are you using PHP 7 or 8? You should go with 8.0 because it has a number of nice changes from 7.x.

Depends on how do you want the site to remember - as in what mechanism saves the data. Because it has to be saved somewhere. For example, there's a session for saving information that you want to use on the rest of the site. And there's cookies for saving information on whatever specific device the user has at that moment. And there's databases for saving virtually anything for any reason. So for you to decide where you store it, you'll first have to decide why you want to.

The answer to that is most definitely We have absolutely no idea how your website works so we don't have the slightest chance of being able to look at that little bit of code you posted and give you useful answers for how to do things like query your database or add content to a webpage. Websites just aren't that simple. Who set up this site? Can you get them to do the work?

The most obvious thing I can see is that you're using a relative path for the images. Don't.

Rather than guess at what could be wrong. try to get some concrete answers. Such as why it would "redirect" to error.php. Under what circumstances does that happen? Upgrading PHP from 5.6 to 7.3 is a big jump. Did anyone do any testing before making the switch? Are there any PHP error logs available to look at?

It "stops working" doesn't actually mean anything. What does it do? What do you expect it to do? And post all of your code - not just some partial jsfiddle with a couple bits that don't actually match what your real code is.

Use one single onchange handler for all the dropdowns: put the filter inside a <thead> so you can use a simple selector to find them all (without any IDs). Then make that single handler retrieve and submit the values for all the dropdowns. And for crying out loud, learn how to name things. "your_id_name"? "selected" versus "selected_contact"? "selected_input" and "selected_input2"? Give those things actually meaningful values. It'll make your life easier.

Headings don't typically go inline with the content they head. Paragraphs shouldn't be inline either. If you want something visually different than the rest then use a <span>. Which is already inline.

Three problems. First is finding out exactly what $response contains. Try to print_r or var_dump it directly without any ->AddResponse or other changes. You'll discover that the response isn't what you think it is. Second is that $response is a string, not an object. Third, and arguably most important, is that you're implementing SOAP on your own instead of using PHP's existing SOAP functionality.

So apparently there are technical reasons why it can't delve into quotes like that: because they're embedded into posts according to the state of the source post at the time it was quoted. I've edited my posts to remove the username, but the truth is that once the content (with usernames attached) gets onto the internet, it's already been scraped and cached and archived. We can remove accounts and erase IP addresses and other identifying information from our database, but even if we could remove every instance of the username from the site (which can't include people manually writing out the name in their replies anyway) it's a trivial process to head over to Google or archive.org and see what they stored before that happened. At the very least, with the username removed from this thread, there's no way for anyone - myself included* - to find out what posts were associated with the author of this thread. * at least not once I've forgotten the username, which I mostly have already

At least it should... There might be some caches in play that still need to refresh? If it doesn't get fixed in a few minutes then I'll deal with it myself.

It will say "Guest".

Alright, then I'll do it in about 10 minutes.

No, I'm saying the account will get deleted but the threads and posts will not. They will get anonymized so they aren't associated with (what used to be) your account, but they will still exist.

Not you personally, no. To be clear, I'm only talking about not deleting content - as in posts. We can delete the account itself.

We don't delete content but we can anonymize it. I'll start the process in about 30 minutes in case you want to reply to that.

It's not possible unless you're running the web server on the same local network as the client. If that's the case then IIRC enable Kerberos authentication on the server.

Need more details. Or try from another angle. What kind of code do you want to write in order to get the data you need?

The select field should identify the row in the table - not the values in it. So if your "wholesale" row has ID #123 with price 100 and quantity 3, your select would say <option value="123">. You then take that ID and look it up in your database table to get the price and quantity. Why? Because a smart user can change the data in the select to be anything they want, which means I could choose quantity 10000 and price 0.01 if I wanted. "Can't you also change the ID 123 too?" Yes. And you can protect yourself against that far more easily than you can protect against a bad quantity or price.

And what's the question? Best I can tell, you're asking for help trying to find out what code does.