requinix

Is there a particular reason you want to block people from trying to browse the internet anonymously? Not everyone has the kind of freedoms that the western world gets to enjoy.

You're off to a surprisingly good start, actually. Most people who are like "I'll just make a database for it" just kinda go for it without really knowing what they're doing. That said, you're a treasurer. You have a rather important job of keeping very good track of money. You need detailed records of everything that happens, not just a summary of it all. So here's the database design I'm thinking of: units tenancies charges payments ----- --------- ------- -------- ID ID ID ID number unit ID tenant ID charge ID notes tenant date date start date amount amount end date? notes notes There are four concepts involved here: 1. The units. You could go with just numbers but that doesn't allow you do do anything else with the concept. 2. Tenants. It's one thing to track payments against units, but units don't make payments. People do. And people move in and out of units all the time. You should be able to differentiate between payment #100 for unit #1234 made by John Smith and payment #101 for unit #1234 by the new occupant Jane Doe. 3. Charges. Because how can you record a payment of $100 when you don't even know what it's for? 4. Payments. You may only want this system to tell you who is up to date with payments, but what you need is to be able to know every little detail about how money is changing hands. I imagine you would use the system something like this: A new tenant is moving into the area. You open the application and go to the page where you manage tenants. You open the details for the unit they will be moving into and see that your system correctly thinks it's unoccupied (having handled the previous tenant's previous moving out earlier). You enter their name and start date and save. A new month starts and new HOA dues are required from each unit. You open up the application and go to the page where you enter new charges. You tell it that you want to enter a new charge for all currently-occupied units and how much the dues are. The system tells you that it created new charges for some number of units. You receive a check for from some unit. You open up the application and go to the page where you enter new payments being made, and it asks you for the unit. On the next page, it presents you with the current state of that unit: who lives there, what charges they've owed, and what payments have been made. The page tells you that they have not yet paid (fully) for a particular charge. You look at the check, confirm the name and address on it, confirm that the charge they wrote as a note is indeed what they still need to pay, and confirm that they aren't overpaying. You select that charge, enter the amount paid, and save. The system tells you that they've fully paid for that charge (or not), and perhaps also lists any other charges still unaccounted for. The HOA comes to you and asks for a report of everybody who hasn't paid their dues yet. You go to a reports page, then to the page that can tell you about outstanding charges. You select the charge corresponding to the month's dues and the system tells you each occupant who hasn't paid (fully) yet. An IRS agent comes knocking to conduct an audit. You go to a reports page that tells you all activity over a date period. You select the past year and the system tells you about every charge and every payment, and even summarizes it. The IRS agent compares your printout to their notes, frowns, and tells you that everything is in order. You then wake up from your dream and wish audits were that simple.

By putting it in the prototype instead of directly on the object instance. Using the prototype means everyone calls the same function, literally, while putting it on the instance means everybody is calling their own version of the function. Or are you asking how that mechanism works?

Here's the structure of how your queries are run: foreach "SELECT * FROM production_data ORDER BY enterprise, job_number, TRIM(line_item) ASC" { $status_qc = "SELECT <status_id> FROM production_status WHERE order_id = <production_data.id> AND dept_code = <10> ORDER BY submit_time DESC LIMIT 1"; $status_thermoforming = "SELECT <status_id> FROM production_status WHERE order_id = <production_data.id> AND dept_code = <6> ORDER BY submit_time DESC LIMIT 1"; $status_vinylpaint = "SELECT <status_id> FROM production_status WHERE order_id = <production_data.id> AND dept_code = <5> ORDER BY submit_time DESC LIMIT 1"; $status_finalassm = "SELECT <status_id> FROM production_status WHERE order_id = <production_data.id> AND dept_code = <7> ORDER BY submit_time DESC LIMIT 1"; $status_crateship = "SELECT <status_id> FROM production_status WHERE order_id = <production_data.id> AND dept_code = <8> ORDER BY submit_time DESC LIMIT 1"; } There are two complications in here: the fact that your departments are dynamic but your code cares about five specific ones, and that you want the most recent record for an order per department. This means that while all six of these queries could be combined into one, you'd end up with one query that uses 10 joins. That sucks. So I think I would settle for two queries: getting everything you want from production_data, but before that getting the most recent status per department for all orders. With some quick preprocessing on that you could look up each status very quickly. SELECT p1.order_id, p1.dept_code, p1.status_id FROM production_status p1 LEFT JOIN production_status p2 ON -- find similar records p1.order_id = p2.order_id AND -- ...for the same order p1.dept_code = p2.dept_code AND -- ...and the same department p2.submit_time > p1.submit_time -- ...and that come after the row that p1 found WHERE p1.dept_code IN (5, 6, 7, 8, 10) AND -- limit to department we care about p2.id IS NULL -- filter to keep only the p1 rows that didn't have later p2 rows $statuses = []; // foreach $row from that query { if (!isset($statuses[$row["order_id"]])) { $statuses[$row["order_id"]] = []; } $statuses[$row["order_id"]][$row["dept_code"]] = $row["status_id"]; // }

I could write a huge reply, but it'll be easier for me to just point you to MDN.

Almost certainly. What's the code for those functions?

The source of the slowness is going to be database queries - nested switches won't be much of a problem (as far as the PHP engine is concerned). I'm concerned about all those get_user_dept and get_order_status calls. Do they do database queries? About cleaning up the code, I'm sorry but that's way too much for me personally to bother with. My advice is to improve it one step at a time: find out the differences between each switch case, pull them out into something more manageable (like an array), and build your HTML using data from it. For example, the $user_dept_code=4/9 > $status_qc switch has all the buttons looking the same except for a CSS class or two and the inner text. Take those differences out into an array like [ 1 => ["btn-warning", "In Progress"], 2 => ["btn-danger", "Delayed"], 3 => ["btn-success", "Finished"], ... ] You can look up the CSS class and text using $status_qc. You may also discover that you messed up some of the markup. And please, do yourself a favor and create your own CSS classes. All those inline styles are bad.

Not with the way your code is written, no. I trust you're familiar with prototyping? Employee and SalesPerson both set up their methods through assignment. It works, but it's not modern Javascript. Using prototyping the code would be function Employee(foo) { this.foo = foo; this.name = ''; this.dept = 'general'; } Employee.prototype.method1 = function() { console.log('method1: ' + this.foo); } Now see what happens with and without those two lines. Using a prototype gives you "inheritance" without any additional work. There's one copy of the method2 function around and everybody uses it. With the older style, every single instance has its own separate method2.

But apparently you didn't read the second sentence on the page.

That is an IP address. It's called IPv6.

MDN has something useful.

Well, if you're just doing this for yourself then by all means, go ahead and experiment around with it. Rewrite what? PDO is one of the best database APIs available...

What have you tried so far?

Either https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_datediff or https://www.php.net/manual/en/class.datetime.php

Do you actually have an "S_POST" array?

Apparently the author of whatever PHP language server extension you're using decided that their list would show deprecated items and give you the choice of whether you used them. If you don't like that, see if there's a setting to hide them.

Here's part of a regular expression-based find and replace for you: function capitalizeWords(str) { return str.replace(/(^|[\s.-])([a-z])/g, function(???) { return ???; }); } It checks for all letters at the beginning of the string, or after spaces, periods, or hyphens, then gives each result to a function. Your tasks are to: 1. Fill in the arguments. The first argument is the whole thing matched, the second is the space or period or whatever that was matched before the letter, and the third is the letter to capitalize. 2. Return the string to replace at that position. Note that it will replace the entire string matched, not just the letter.

Digest authentication is rather complicated. Do you have any way to change the authentication system it wants to use? Perhaps to "Basic"?

Exactly my point.

Look carefully at the condition for your first rewrite. Have one redirect that does just the extension and one that does just the slash. (And in that order.) Don't try to do half of both at the same time.

So every time you log out, clear your browser cookies, blah blah blah, and log back in, you get the same token? Every time? And when you log in using PHP code they give you the same token as well?

Then that could be it. They're tracking client IP address with the token, and the token is not valid when used from another location. You'd have to generate the token from within PHP. Can't just copy and paste what your browser is doing.

Are you running PHP locally? That's the only thing I can think of.

At the moment the only thing I can guess is that you're updating all messages in a thread when you should be updating individual messages.

It seems right. Is there any more information you can get from the remote service? More detailed error message? An error log? Any logs at all?