requinix

Have you been able to shell_exec() PHP in some other way? Yeah, you've mentioned that. Lemme put this bluntly: For most servers, PHP running a website and PHP running from the command line are two different things.

Because PHP isn't installed as a command-line utility? Because it doesn't have the same extensions and configurations as the one running from the web? Because there are restrictions in place to prevent it from running correctly or at all?

How much do you care about good searches? The professional answer is to not use the database for it and to move to services like elasticsearch (which is free). It takes some setup work, and it's not trivial, but it's much better at handling searches than a regular database will be. But definitely don't do a keywords column. That's just not natural. (Tagging, on the other hand, is quite reasonable.) Are you having a specific problem with your searches? Or do you just want to learn more about it?

Is that relevant? Is there something in clearflags.php that can only possibly work from the command line?

Thoughts? Don't do that. Why do you have to run PHP code from a whole new process? It doesn't make sense. You're running PHP already so if you want it to do a thing then make it do the thing. Firing up new PHP processes for it is silly.

It might seem right but you're outputting invalid HTML. <select> </optgroup> <optgroup label='Support & Extras'> <option>On Site Support</option> </optgroup> <optgroup label='Licence'> <option>AllowME Multi Event Licence (Annual)</option> <option>AllowME Multi Event Licence (Quarterly)</option> <option>AllowME Multi Event Licence (2 Months)</option> <option>AllowME Multi Event Licence (Extension)</option> </optgroup> <optgroup label='Scanning Hardware'> <option>Long Range RFID Scanner</option> <option>Handheld Scanner</option> <option>Short Range Catering Scanner</option> </select> Does that look correct?

First you'll have to sort the results by the type. Because otherwise stuff will bounce between one type and another. Then you should probably sort by a secondary another field - I suggest the item name, since that's what the user sees. Really, most of the time you're running a query for data that gets displayed to a user, you'll want to sort by something. Even if you don't need anything grouped or sorted alphabetically, picking and sorting by a unique column (like an ID) guarantees that you'll get the same data in the same order every time. Anyway, when you have that sorting, your loop will need to know when the type changes. That means remembering what the previous one was. Get yourself a variable for it. Start it off empty. Inside the loop, if the current type doesn't match the previous type (and the first row definitely will not) then that means you need to start a new group. If there was a previous type then there was a previous <optgroup> already going for it and you'll need to close that out, then either way you start the new <optgroup>. Finally, you need to think about that last group. When the loop finishes you'll have been working on one group but the <optgroup> will still be open. So close that one out too.

You don't have to reinstall. They don't make the source code browsable on the internet for some reason, so it's not like you can go off to GitHub and grab the file, but at least they do support you downloading a few hundred megabytes (for the x86 version, whose index.php will be the same as the x64's) to grab one single file.

There shouldn't be any empty arrays... What's the code now and what do the arrays look like?

Considering how it will be extremely hard to know what the problem is without being able to see any sort of HTML or CSS, you should probably go ahead and post that URL.

That's the same code from before, right? The $cronograma array has data from both groups mixed into it. That means it will be hard to work with. What is the code you have to fill that array? Instead of putting everything into one single array, use multiple arrays. One array for each group. An array of arrays would be a good idea for that.

Which part? What code have you written so far and what problem are you having with it?

So... I'm right, then? You need those 4 pairs of start/end dates? What I said before about splitting the one array into two (one for each subject), then go through each array looking for the total=0 and total=34 dates and then for the total=34+time (that allows you to support any class duration instead of total=36 which only works for 2 hour classes) and total=68 dates.

Then it would probably work better if you had said something like "how do I translate the below equations into PHP code" instead of "PHP doesn't have a ln function so what do I do". What are PREBUN and POSTBUN and TIME and all those? Do you already have them set up as variables?

But aren't the subject dates different for each group? One goes from 09-21 to 02-01 and then 02-08 to 06-14, while the other goes 09-22 to 02-09 then 02-23 to 06-22.

In that chart, why is 2020-09-21 a 4? Shouldn't there be a 2 in 09-21 and another 2 in 09-22? The way I see it, the first step is to split that array of dates for both classes into one array of dates for each class. So one array has 09-21, 09-28, 10-12, and the other has 09-22, 09-29, 10-06, and 10-13. That also means each array's total increments exactly the way it should: the previous total + the current number of hours. 2, 4, 6, 8, and so on. No confusion about 2, 2, 4, 4, 6, 6 or 64, 68, 66, 68. Each array will then have one and only one item in it with a total of 34 hours. And only one 68 hours. From there I'm not sure because I don't know what the output is supposed to represent. Is it a "schedule" for someone to get 34 hours of each class, but they can only take one class at a time?

But how do you know which is which? 2020-09-21 - 2 - 0 - 2 2020-09-22 - 2 - 0 - 2 2020-09-28 - 2 - 0 - 4 2020-09-29 - 2 - 0 - 4 The 09-21 and 09-22 dates are for the two classes. The 09-28 and 09-29 dates are also for the two classes. But it isn't obvious that the 09-21 and 09-28 dates are the same class. Is there anything other than the 7 day difference to tell which one goes for which class? What if a class is rescheduled to be a day earlier or later? I see one class will be missing two dates at the beginning of 2021-12 - aren't they going to be 4 hours behind the other?

Those dates look like they come from two different data sets. Why is the first end date 02-01 and not 02-09? Why is the second 06-22 and not 06-14?

Where are you getting 2021-02-01 from? Where does the 34 from $tot come in? How about this: given those three arrays, $cronograma = array( "2020-09-21" => array("2020-09-21", 2, 2, 2), "2020-09-28" => array("2020-09-28", 2, 2, 4) ); $id = array( 58, 60 ); $tot = array( 34, 34 ); (1) what is the output you want to get, and (2) what thought process did you follow for you to come up with that output?

Dunno. It was a clear decision to padding-bottom about 50%. They might be expecting someone to put an image in the background? Fixed. IPS made tons of theme changes, but fortunately the conflict resolution process has been mostly to just revert all changes - seems the new layouts are a bit more compatible with theming.

$chosen_methods = WC()->session->get( 'chosen_shipping_methods' ); Apparently there is no "chosen_shipping_methods" value in the session. You need to provide a default - an array of shipping method values to use when that session value isn't present. Guessing based on the code, you can do so with $chosen_methods = WC()->session->get( 'chosen_shipping_methods' ) ?? ['suitable:set:of:values'];

What do you mean by "group"? The normal way this "I have 2 dropdown boxes being populated" problem goes is that you get a list of all titles and put that in the first one, then get a list of all artists that match the title selected in the first. Neither have anything to do with grouping.

As long as the filesystem permissions are set up to allow whatever user PHP is running as to write files then yeah, sure, you can do that.

Try wrapping the class definition in an if(true) { }, which will prevent PHP from optimizing away the declaration, and then logging a debug_backtrace() somewhere before the if. Locally you should see two traces while in production there should only be the one. Then you can compare the traces to see if that suggests anything.

To be clear, you're talking about ignoring errors in the sense that PHP continues execution after? No: once the error has been raised, that's it. They can't be trapped with set_error_handler() either, although they can be detected with some register_shutdown_function() trickery. Assuming production isn't running some hacked version of PHP, and assuming that everything is running properly to completion, that must mean there aren't any fatal errors. So there's some difference between there and your setup.