requinix

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?

I would think the option that is easiest on the microprocessor itself would be best. That probably means MQTT. Plus apparently that gets you real-time data.

You can use array_rand() to pick one of them randomly.

That was not easy to understand. 01-10 - Incoming: 10 - Outgoing: 5; 5 taken from today's inventory (10-5=5) - Ending inventory: 01-10 (5) 02-10 - Incoming: 10 - Outgoing: 7; 5 taken from 01-10's inventory (5-5=0), 2 taken from today's inventory (10-2=8) - Ending inventory: 02-10 (8) 03-10 - Incoming: 8 - Outgoing: 21; 8 taken from 02-10's inventory (8-8=0), 8 taken from today's inventory (8-8=0), remainder 5 - Ending inventory: deficit of 5 04-10 - Incoming: 15 - Outgoing: 3; deficit 5 taken from today's inventory (15-5=10), 3 taken from today's inventory (10-3=7) - Ending inventory: 04-10 (7) 05-10 - Incoming: 10 - Outgoing: 6; 6 taken from 04-10's inventory (7-6=1) - Ending inventory: 04-10 (1), 05-10 (10) 06-10 - Incoming: 5 - Outgoing: 7; 1 taken from 04-10's inventory (1-1=0), 6 taken from 05-10's inventory (10-6=4) - Ending inventory: 05-10 (4), 06-10 (5) Now that you've posted a whole bunch of code, half of which is commented out and I assume the other half of which does not do what you want it to do, let's disregard it and try starting over from the beginning. How is all of this data being stored? What do the database tables look like? What does the data in the database tables look like?

Yes, because the expectation was that you have "a lot" of emails to send, and instead of doing one email, yielding, then another, and yielding, and another, it runs multiple emails in series. There may not actually be a problem with doing that. Probably the only thing that would really be relevant is how frequently you have more emails to send - theoretically, the thing sending emails could be doing one at a time and something could be generating emails to send faster than the sender can keep up. Anyway, read what kicken said.

It is quite a bit simpler than having to deal with Redis queues, yeah. And unless the work needs to come from an external source, the approach I showed also allows you to add tasks over time. So you could have one "process" (whatever ReactPHP calls it) that has the emailer and doWork, and another process could just as easily add emails to it. And you can go even further than that...

In this case it's about using the generator as a coroutine. Generators can suspend execution and return to some caller, then that caller can have the generator resume. The use case here is that your doWork becomes a generator, and it yields (suspends) every email or so. When it suspends ReactPHP would have a chance to execute as it needs (ie, run through the event loop), and when it's ready it has doWork continue. Rinse and repeat until hair is sufficiently washed. https://3v4l.org/qlXCj As long as doWork is running, ReactPHP's loop will not execute. Because it's not truly asynchronous - it just looks that way. The basic problem you have is that doWork takes too long. The basic solution is to split the work according to whatever is not "too long". Since your metric is time, I suggested running work until some suitable amount of time has passed. Like one second. doWork is probably self-contained, right? It determines what work needs to be done and does it. You'd refactor that so that determining the work to be done happens before doWork, then doWork goes through that set until either too much time passes or it runs out of stuff. class DoesWork { private $work = []; public function __construct() { $this->work = ???; } public function addWork($item) { $this->work[] = $item; } public function doWork() { // exact code varies, but basically... $now = microtime(true); $end = $now + 1; while ($this->work && $now < $end) { $item = array_shift($this->work); // whatever $now = microtime(true); } } public function hasWork() { return !empty($this->work); } } // setup $worker = new DoesWork(); // inside the event loop, if ($worker->hasWork()) { $worker->doWork(); } If you look closely, you'll notice the code structure looks similar to what was in that 3v4l link...