requinix

Browsers do not decide to rotate images for no reason, but they may decide to not rotate an image. If you see an image rotated in one place and not another then that's because of what I said earlier: Can you upload here one of the problematic images?

If you don't ask a precise question then you might not get a precise answer. Do you know exactly which WordPress image you're using? What OS is it based on? Debian does have a "php-yaml" package so if you use that one then you can probably set up your own Dockerfile that FROMs the base WordPress image and apt-installs the php-yaml package.

I don't see instructions for doing it within Docker already written for you. Do you understand how Docker images work? What Dockerfiles do? It would not be hard to take the regular installation instructions and port them to a Docker environment.

Do you know what the HTML markup is for checkboxes? Your drop down does not support multiple selections right now. Checkboxes do support multiple selections. Do you want that, and if so are you working on changing your PHP code to support that?

FastCGI and php-fpm are not the same thing. If you don't want php-fpm to log then configure php-fpm to not log.

No offense, but there are tons of PHP + AJAX tutorials out there. Have you tried reading a few articles or watching whatever YouTube videos are out there? For the most part, all you have to do is write a bit of Javascript to send the data and receive the response (and do whatever else you would otherwise do). The PHP side is less complicated than your standard page because you output straight data (using JSON) instead of some complicated webpage. If you can write a PHP script that takes the form data then you're most of the way there. And it sounds like you already have that piece.

Every time I see WordPress code I have to take a shower to wash all the disgusting off me. The easiest way to accomplish what you want is to not do that. If you want the member ID to look like four letters from the last name (what if their last name is less than that?) and the number then show the last four letters and the number. Make a function or class or whatever that can take a member and their ID and give you the string you want. But here's the thing. You cannot use that last four + ID as a real identifier. It will cause lots of problems. You can show it to people but under the hood you should always deal with just the member ID.

yaml_parse_file is documented in the online PHP Manual. It is part of the PECL yaml extension. There are instructions.

Always record data. A payment failing counts as data. What. I think part of my problem with this thread is that I don't even understand why you would consider this idea. Sign the user up. That's a separate step. Store the order data. That's a separate step. Take the payment information. That's a separate step. Attempt to process the payment information. That's a separate step. There is no reason why one of those steps resulting in a problem should somehow undo what happened before it. Even if you went for step #2 (which, to reiterate, is wrong), there's nothing incomplete here. A user is a user. Doesn't matter whether they have an order, let alone have successfully paid for an order. These are two completely different concepts. And the order has every reason to exist even if the payment didn't go through - again, always record data. If the disadvantages outweigh the advantages when why would Amazon do it? It's not your fault the payment failed. (Probably.) You have no control over that. If it fails and the user aborts the order then sucks to be them. You cannot store order data for an anonymous user. It's not good. The user must exist so that you can associate the order to it. That's fundamental ecommerce there. That's right. You have to do that. I'd say "you have to do that" but you already have: it's called "anonymous people don't have access to the paid portion of the site". The only difference now is that you need to tighten your restrictions to allow users who have also paid (or have an active subscription or whatever). Bad analogy. They don't let you do that because there's a high risk you'll sneak off to a screening while the staff aren't looking. Which totally does not translate to an ecommerce website. I cannot come up with a polite response to this one. Do whatever you want. I'm out.

Have you checked the documentation to see what else odbc_exec might be returning?

Sounds good. A transaction is only necessary if you have to run multiple queries and the database is not in a consistent state until they've all executed.

It's off by two hours, right? Because PHP is normally set to UTC time. date_default_timezone_set Or if you're based in that timezone and want everything to always be according to that, change the date.timezone value in your php.ini to say Africa/Johannesburg. (And restart your web server and/or PHP.)

- System takes Shopping Cart details associated with PHPSessionID and links them to the new Member record Do you care about storing shopping carts with an account? Some sites do, some sites don't. If you don't care then you don't have to do that step. Look at your process this way: If a worst case scenario was to happen between any two steps, would your process be able to recover gracefully from the failure? Will you lose any information? Will the data in your database be incomplete or otherwise corrupted? For example, - System runs the payment - System hopefully gets back a "success" message from Payment Processor One potential worst case here is that you submit a request to your payment gateway but the system blows up before it can receive the successful response. What would happen with the plan you've described? What should happen? But be careful: I've chosen a particularly devious scenario for you to consider. The answer may surprise you.

So do what I said: deprecate the old endpoint, but keep it working until the DLL can be updated. Ideally you would keep everything working instead of redirecting because there are other nuances to consider, but at a minimum keep the non-GET/HEADs up. If it's something distributed to customers then you'll have to keep this going for however long you support your software. If it's something internal then, you know, update the DLL.

Are you using someone's blog as your reference? https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.8

There is no mechanism in HTTP to tell a client that it should submit POST requests to a new URL. The industry handles this in a fairly standard way: deprecate the old endpoint before taking it down. Continue supporting it for some period of time and give a warning to consumers that it will move.

What kicken said ^ Have your function take an optional argument for the current/default/selected/whatever you want to call it, value. In the while loop, mark the <option> as selected if it matches. Then your script calls the function with whatever value came from the form - if there was one.

Pretty much. The columns represent discrete identifiers that have no intrinsic numerical properties, meaning there's no reason you should ever do anything based on an order or product ID range, therefore all your queries will be straight equality - whether the row is or is not for a particular order and/or product. As such there are no benefits to having dual indexes on both columns.

More precisely, the query analyzer will only use an index if the first N columns in it are included in the query. Given indexes (columnA), (columnB), and (columnA, columnB), SELECT * FROM table WHERE columnA = 123 could use the (columnA) or (columnA, columnB) indexes. SELECT * FROM table WHERE columnA = 123 AND columnB = 456 could use the (columnA) or (columnB) or (columnA, columnB) indexes - and the last one is probably best. Note that (columnA) and (columnA, columnB) are redundant: anything that can use the first one could also use the second one. There's more to it than just about being "common", but that's a decent starting point. If you wanted to query for products across all orders. Point #1: An index takes up disk space to store the data. Point #2: Each index slightly reduces performance when making changes to table data because the system has to update its indexes. Point #3: (order_id, product_id) and (product_id, order_id) are mostly redundant. Conclusion: I don't think there's enough reason to create both. Addendum: Actually it kinda depends on the data. But mostly I'm trying to discourage the "moar indexes moar columns" mentality.

I like XHTML. At least the principles behind it. Bit out of date, now. Hell may freeze over, pigs may fly, and our Tangerine-in-Chief may suddenly become a reasonable and intelligent man overnight, but register_globals will never come back.

What fields do you think should go in which tables, and what fields are you not sure about?

What if I told you that you don't need a loop?

HTTP/1 is all text. You can totally run requests and get responses yourself. SSL makes the tooling a little harder because you have to connect using an SSL client, but still not too hard. GET / HTTP/1.1 Host: forums.phpfreaks.com Connection: close HTTP/1.1 301 Moved Permanently Server: nginx/1.16.0 Date: Sun, 26 Jul 2020 18:35:57 GMT Content-Type: text/html Content-Length: 169 Connection: close Location: https://forums.phpfreaks.com/ <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx/1.16.0</center> </body> </html> HTTP/2 uses binary, but otherwise the structure is about the same so I assume there are clients that can convert to it for you.

The client must send the slash at a minimum. Not submitting anything is a gross violation of the HTTP standard. "Forging a request" is as simple as 1. Typing the request out into some editor, then copying it all 2. Using telnet to connect to the web server 3. Pasting the request, remembering to include two newlines at the end if you're sending a request without a body The copy/paste is because web servers want requests quickly and you won't be able to type it out yourself fast enough before they close the connection. Forge a request that starts with "GET HTTP/1.1" (ie, the first line without the resource URI) to any website and you'll get a 400. Should not. But search engines are generally smart enough to recognize the difference between a site's branding H1 and some sidebar's H1 and the content H1. So the guideline is more about not using multiple H1s for a distinct section of the page. Google basically picks what is most popular, not necessarily what is correct. But if you have multiple URLs to the same page with the same content then you will be penalized for it. So deal with it sooner rather than later. Trailing slashes on files are dumb. Fortunately it's rare to see anyone do that. Trailing slashes on everything else is up to personal/business preference. (Personally, I don't like slashes on pages either. With exceptions.)

+1 to the full contents. Does each line have a specific meaning? Is the textarea just an easy way to enter all of them at once? Is the user copy/pasting stuff? In general, unless you have to come up with a particularly efficient solution, DELETEing everything and then INSERTing it (preferably with a prepared statement) all anew is easiest.