requinix

And what's the question?

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort

If the goal is simply to support *s then fnmatch can do that.

Has anyone run into an issue where they created the same dropdowns as you did, have them pop up a modal like you did, and stop working like yours did? Maybe. Post your code.

"Removing" a time is another way of saying you don't want to show the time. How are you showing available reservation times to the user?

If %s work for some reason then maybe your first attempt didn't work because you were looking for "FA" in [PART NUMBER] instead of [CATALOGUE_NUMBER_BOM]?

You have an asterisk, yes, but what about second asterisk?

I don't know what's going on. But I do know <input type="hidden" id="hidetext" value="{php:function( 'SobiPro::Txt', 'CATEGORIES_HIDE' )}"/> that won't work.

Does the XSLT include xmlns:php="http://php.net/xsl" or does it use a namespace-alias?

You agree that... you're looking at the wrong code? Not to your original problem, but you should fix it anyways.

"function function not found" suggests XSLT that looks like select="php:function('function', ...)" Are you sure you are looking at the right code?

You are doing a redirect. You cannot use $_POST after a redirect. That's the rule. Remove the redirect and do whatever logically follows from that.

I don't understand what your post is supposed to mean. Isn't that the same code as before? My reply is the same: you can't use $_POST after a redirect so put the message on the same page instead of redirecting.

The $_POST data is only good for the page where it was submitted to. Any page you redirect to after that will not be able to see it. If you want to output a message then do it on the page the form submitted to. Don't use a redirect for it.

Don't lie on your next job application and you won't have this problem again.

"Verify" customers? The API endpoint is "createCustomer"... Here's the deal with Javascript: it's public. Everything is visible for someone to read. Anyone can pull up your HTML and Javascript, see the API call, and start to abuse that. I don't see a hidden input in the form for some sort of API key, but that means (a) there's supposed to be one and you haven't included it yet, or (b) the endpoint is not authenticated. Either way, it really doesn't sound to me like this is the sort of thing that should be run entirely from Javascript.

10 years of code doesn't stop working overnight. Something changed. Find out what and you might get your answer. Maybe it's a PHP version? Did someone apply software updates? Changed server hardware?

Er, I missed this before. Whose API are you trying to use?

When you put those Proxy commands kicken's gave you into your .htaccess, you said you got an internal server error. What do the server logs have to say about why there was an internal server error? kicken gave you the "simplest thing" that could work. Evidently their API is not a simple thing. Says who? The internet isn't some plug-and-play thing. You can't wave a magic wand and suddenly have your site start talking to another site, just like how I can't travel to Finland and suddenly be able to speak Finnish. It will take some degree of work to make this happen.

That's not weird. It's only the larger companies that tend to provide SDKs for developers. Most of the time all you have to work with is documentation. Sounds like you don't have mod_proxy installed. If you control the server then you'll have to install that module first. If you don't, and if your hosting provider doesn't give you a way to enable features like mod_proxy, then you might have to go with a pure PHP solution.

You didn't include the answer in your follow-up, so I assume it was one or both of: (a) there was something wrong with $item->ID, like maybe it should been ->id or maybe $item is an array instead of an object, or (b) the ID was being passed correctly and viewuser.php needed to use $_GET or some other input abstraction layer to get the value.

CORS is implemented at the place receiving the AJAX call, not the one making it. 3rdpartywebsite.com/api would have to add those headers. Proxy the request: set up an API endpoint on your site that works the same way (at least as far as you care for it to work) which sends the request to that site and returns back its response.

Depends on your setup. With normal PHP yes, silencing the error keeps it suppressed. If you have a logging system set up to intercept and log errors then it depends. PHP will invoke the system's custom error logger even with @s, but in such a way that smart code will be able to recognize that happened and not log it. A naive logger will see "omg error, gotta log it". For the record. You're right in that you shouldn't do it: hiding errors doesn't make them go away, just like how stopping Covid-19 testing doesn't mean there are no more cases.

You mean some thing you can download and install that will do everything for you? No. I suggest you start by Googling "php mqtt".

What's the question? Are you saying that SHOW COLUMNS is deprecated?