kicken

I believe it's just the order by being there at all. With join's in the view, your update is a multi-table update, which the documentation for update says: If your view had no joins before then it would have probably worked but now with joins it will not. I'm in the habit of not including an ORDER BY clause in my views at all. I mostly use SQL Server which doesn't allow you to do so unless you apply a limit to the result set as well. The ORDER BY clause is generally intended to only exist in whatever the final query is, so you'd do: select whatever from yourView order by whatever rather than have the order by as part of the view.

The ORDER By clause in your view was preventing my update attempt from working. Removing it allowed the update query to function. Did your queries have the order by clause before? Have you tried running an update query, or just going by the error your GUI tool is showing? Likely not related to the immediate problem, but you have a type mismatch in your DB. a_aau.aau_team_id is a VARCHAR being joined tot a_aau_teams.id which is an INT. The types should be matching, so you likely want to update your VARCHAR to be an INT as well.

Screen shots are not useful. I can't import a screenshot into Mysql to work on it. Post the CREATE TABLE statements in a code block so they can be copy/pasted into mysql.

If you post the structures of your tables, I can look into it more.

I don't typically use updatable views, so I'm not sure. I don't see anything off hand. Is the query referencing other views, or only real tables? Does the query return multiple rows for the same p.id value?

You can try reviewing the documentation on updatable views and see if you can spot a reason.

Your fiddle doesn't really make sense. You keep referencing an element with id="demo" but no such element exists. In mouseOver you set the content, while in mouseOut you just change the color to black. Strange combination. Your mouseOver function is using your element variable, which is your id="butts" div. That div does not have a com attribute. It seems like you're just trying to add tool tips to your buttons. If you only want simple text-only tool tips, then you can just use the title attribute and not use JS at all. A JS solution is only needed if you want stylized tool tips, or for them to display in a specific place on the page. If you do need the JS, then what you want to do is add both your mouseover and mouseout event handlers to your butts element. On mouse over, check if the target element has a com attribute and if so display it. On mouse out, clear whatever has been set. Modified fiddle const element = document.getElementById("butts"); element.addEventListener("mouseover", mouseOver); element.addEventListener("mouseout", mouseOut); function mouseOver(e) { if (e.target.hasAttribute('com')){ let text = e.target.getAttribute("com"); document.getElementById("demo").textContent = text; } } function mouseOut(e) { document.getElementById("demo").textContent = ""; }

The session ID is stored in a regular cookie, just like any other cookie data you would want to set. It has all the same cookie parameters, which can be configured with session_set_cookie_params. @jasonc310771 So long as the session cookie is setup with a domain parameter that allows it to be used on sub-domains, there should not be any issues with your session id carrying between domains. If the server-side code for both domains has access to the same session storage back end then sharing the data should work as well. If the two domains are hosted on different servers and you're using regular file based session handling, then the data won't carry over since the second server would not have access to the first server's session files. Have you checked if the session ID is being carried between domains by inspecting the requests your browser makes using it's dev tools? If it's not, try using the session_set_cookie_params function to setup your domain parameter prior to calling session_start().

The .style.* properties only provide values directly assigned to an element, either via JS or via a style="" attribute, they do not reflect CSS applied via selectors. For that, you need to use getComputedStyle. I do not see anything in your current code that is changing the left attribute of your elements, so it'd never change to be zero. Scrolling does not affect the left attribute of an element if that was your intent. If you want to check if something has been scrolled out of view, you need to find the scroll position and compare it to the position of the element.

You are setting the values by ID, but IDs must be unique within a document, referring to only a single element. You need to find the row that the data needs to be associated with, then set the values to the inputs in that row using something like querySelector and a class name. I think the first question to ask is how do you determine which row to associate the data with?

Canvas has a toBlob method, which allows you to create an image file from the canvas as a JavaScript Blob object. You can then upload that blob to your server using the FormData object and fetch(). Something like this: function uploadCanvas(canvas, url){ canvas.toBlob((blob)=>{ const data=new FormData(); data.append('canvas', blob); fetch(url, {method: 'post', body: data}); }); } On the PHP side of things, you handle it just like any other file upload by looking at $_FILES['canvas'] and saving it as desired.

The function you want is preg_split, not preg_match_all or preg_replace_callback.

Check your browsers development console for error messages. I'm assuming you'll see one about how JASON is not defined.

Seems the password is being written in clear text to a file. All you need to do then is read that file.

They will input however they can. That may be via POST data, GET parameters, the URL path, HTTP headers, Cookies, etc. Anywhere that your program accepts external input has potential for bad data. If that external input is then used in some way in your SQL query, you have the potential for SQL Injection. They don't need to make their own form on their own host, they can just manipulate your form using a browser's Development tools or submit requests with a tool like cURL. What you're describing regarding using another server to host a fake form an entirely different security issue known as Cross-site request forgery and the solution to that is unique tokens as part of your form data. You're conflating things here. Hard-coding a value means you're just inputting a string or number or whatever directly where it needs to be. This can make maintainence or configuration changes harder as you need to change every place that value is needed. Defining values as a variable or constant means you can put the values in one place, then just re-use that variable/constant where needed. Using those variables/constants doesn't suddenly mean you are vulnerable to SQL injection. SQL injection is caused by using end-user having control over the value of variables used in your queries. Using variables that have a hard-coded value is fine. Using variables whose value comes from outside your control is a problem. You seem to have some idea about this being the case. Yes, if you have a specific set of safe values, and require your variable to be one of those values before it's used in a query, then that is ok. Your code doest at least make an attempt to validate that $table is an expected value via the check: if(!in_array($tables[$table],$tables)) { die('Invalid Table!'); } That check may work, but is not ideal. An invalid table value would give you E_NOTICE errors about an undefined index. Your $headings and $columns values would also be invalid since the invalid table doesn't exist. You should checking with isset or array_key_exists instead. You should also be checking this condition before you try and use the value for other things, not after. For example: $table = !empty($_POST['tbl']) ? $_POST['tbl'] : (!empty($_GET['tbl']) ? $_GET['tbl'] : 'spidered_web_index'); if (!isset($tables[$table])){ die('Invalid table'); } $headings = array_values($tables[$table]); $columns = array_keys($tables[$table]); Fundamentally, the difference between what is commonly called "procedural" vs "OOP" styles has to do with how data is handled, not code flow. Either way, code runs top to bottom within a block, and will jump randomly between blocks as you run functions, conditionals, etc. What's different is that with OOP, your classes hold both the context data they need and the functions to operate on that context. With procedural programming, the context gets passed around from function to function. In OOP, since the object owns it's context, it can control whether other parts of code are allowed to manipulate that context or not and the programmer cannot accidentally pass in the wrong context or just omit it entirely. With procedural, the program has to be sure to always pass along the context and make sure they pass along the correct context. For the mysqli API, you might have noticed that when you compare the function prototypes in the manual between the two styles, the procedural version usually has an extra parameter. eg: //OOP public mysqli_stmt::prepare(string $query): bool //Procedural mysqli_stmt_prepare(mysqli_stmt $statement, string $query): bool That extra $statement parameter is the context that you end up having to pass around from function to function when you code procedural style. If you pass in the wrong value, things break. In the OOP version of the API, that context is part of the object itself so there's no need to pass it between the functions. The functions can just grab it from the object they are being called on (the $this value in a class method). As a novice that's just using pre-made classes, there's little difference from your point of view, other than you end up typing $someObject->someMethod() instead of someMethod($someObject). When you start getting into writing libraries for others (or just yourself) to use in various projects, then you start seeing more of the benefits of OOP. Studying small libraries written in an OOP style may help to understand things more.

Sounds to me like you have the correct solution as far as the DB is concerned, it's just your framework choice that is the issue. I use Symfony/Doctrine and it could handle this setup no problem. If you can't do what you want using Laravel's setup, you may need to just resort to doing some manual queries. I don't use laravel so can't say for certain if this really is a limitation or how to work around it.

See: Reference Guide: What does this symbol mean in PHP? (PHP Syntax)

They likely pay various places for the data then consolidate it. I'd probably buy it. I've bought compiled lists of US zip codes with various other associated data (Timezone, Lat, Lng, etc) before. $35 and 5 minutes to buy and import the data was a lot cheaper than spending hours/days/weeks trying to compile it on my own.

Both of those use some third party API which you'd likely have to sign up for. Since I've never looked into either of them, I don't know how they operate and can't really judge the code. If your goal is to avoid third-parties and having to pay for access, then neither solution is great. AI isn't magic, if you don't really know what to ask for or ask for something too generic then you won't get good results. Knowing what to ask and how to ask for it means you need some working knowledge of the topic. Part of the issue with your prompts is that Bitcoin doesn't have some official gateway api, so you're getting solutions using third-party APIs. The way to interact with the bitcoin network yourself is by running a local node and using it's built-in RPC server. Once you know that, by studying how bitcoin works, you can develop a proper prompt that will get you some reasonable starting code. Prompt: Write a function in PHP that confirms a bitcoin transaction using a local node RPC server. /** * This function confirms a Bitcoin transaction using a local node RPC server. * * @param string $txid The transaction ID to confirm * @param string $rpc_user The RPC server username * @param string $rpc_password The RPC server password * @param string $rpc_host The RPC server host * @param int $rpc_port The RPC server port * * @return bool True if the transaction is confirmed, false otherwise */ function confirm_bitcoin_transaction($txid, $rpc_user, $rpc_password, $rpc_host, $rpc_port) { try { // Create a new RPC client instance $client = new \Nbobtc\Bitcoind\RpcClient($rpc_user, $rpc_password, $rpc_host, $rpc_port); // Get the transaction details $transaction = $client->getTransaction($txid); // Check if the transaction is confirmed if ($transaction['confirmations'] > 0) { return true; } else { return false; } } catch (\Exception $e) { // Log the error error_log("Error confirming Bitcoin transaction: " . $e->getMessage()); return false; } } This code is using some library to interface with the RPC server, you'll need to either find that library or write your own code to interact with the server. Yes, finding an AI forum (for ChatGPT or otherwise) would be ideal. I do not know of any. As far as crypto forums, the only one I know of is Bitcoin Talk. I'm sure your favorite search engine could help you find more for any subject.

Variable Scope

My advice is to not bother with it. After a brief search, I found that apparently you can request copies of zone files, but I'd guess your chances of being granted them is low as it's not a services intended for the general public.

You cannot just download a list of all domains and email addresses. All a DNS cache does is save DNS lookup results to avoid hitting the upstream servers for common lookups. Windows has one built-in already (see: ipconfig /displaydns).

It's not going anywhere. You don't have to absorb every detail in the first pass. By looking through it at least once though, you'll familiarize yourself with what's available and then when you encounter some problem hopefully you'll be able to say to yourself "I remember seeing this one thing that might be relevant here, let me go look it up again" instead of just being completely lost. I skim through the manual usually at least once per year or so, just to familiarize myself with what's available, mostly just looking at the index pages that list the extensions/functions/features. If something sounds interesting then I dig a bit deeper. A large part of being a successful programmer is knowing how to find the information you need, not trying to just memorize every possible thing. That means being familiar with good resources like the PHP Manual, MDN, W3C Standards, Can I Use, and so on such that you can quickly look stuff up when you need to. If you don't have or develop that basic skill and instead always "ask a pro" then you will find that you quickly run out of pros to ask (ex: your ban history).

You're generally not going to find such specific examples in a manual. You need to use the documentation and examples given to learn the components so you can then put them together as needed to accomplish your task. Perhaps you should lookup what getAttribute does. You might also need to read up on how the DOM (the link talks JavaScript, but the interfaces work the same in any language) works in general if you want to continue using DOMDocument. Spend some time reading the documentation for DOMDocument and some about the DOM and you should be able to figure out where you went wrong in your above attempts.

You don't have to sign-up for anything to use bitcoin. Just download the official client (or some third-party alternative) and create yourself a wallet to start using. I'd suggest taking any further crypto currency discussions to a crypto currency forum, you won't get much of a response about it here.