gizmola

There is no reason to use parent child directories in pathing to web resources, and plenty of ways doing so can be the source of problems. If your webroot is /foo, then have a directory under /foo like /foo/js. Put your .js files in the /foo/js folder. In your example you have a .js named add.js. At that point you can refer to add.js inside your html via the relative path: <script src="/js/add.js"></script> Notice the leading '/' which indicates the webroot directory is the parent.

In addition to Barand's comment, what you can do is inner join the result back to quote by quote.id in order to pick up the version, as well as any other data specific to the max quote row of the group.

Actually that is rarely the case. If I understand you, part of the data you are looking up is "user" data from a user table. That data certainly is not always changing, and in most system designs, you absolutely know/control when it is changing. Let's say for example, there is user data + profile data perhaps in 2 related tables. What a memcache based cache would provide is --- your code checks for the existence of the data in the cache. You have to figure out what the cache key is going to be to be able to resolve it, and usually that is some sort of string like: '/user/{userid}'. If the key exists, you just read the data from memcache. This eliminates the need to query the database. If the key doesn't exist you perform the query, and save the result in a new memcache key. You have the option of specifying a ttl value for the key. Now this query could also be a query that joins to the user profile table. In your routines that change/update the user or profile data, you invalidate the memcache data for that user when you save it to the database. The next read/select of the data will create a new cache entry. The main trick that memcache does is to allow for it to be clustered, and this is why facebook originally used it, given their enormous graph. There are very few systems that have that level of scalability issues, but most applications get a significant performance and scalability boost out of using some sort of in-memory cache. A lot of projects I've worked on have used Redis. You do need to do some thinking about the type of data in your system, and whether or not portions of it are relatively static. It also tends to show you if you've made significant design mistakes. An example might be putting some sort of de-normalized counter in a table, such that you made something that is relatively static, like a user table, non-static. Putting a "last login" column, or summary columns like "friend_count" or "topics" all reduce database concurrency, and then cause people to move away from caching because they put these types of fields that require frequent updates into the main user table. So to conclude, let's say you have something that does get updated with some frequency but then requires a join to another table for context/data availability. An example might be a message system, where you need to join to the user table to get the to/from usernames associated with messages. Again, depending on your design, even though messages could be added with some rapidity, that doesn't mean there aren't users in the system who could have a cached version of the message data. It also doesn't mean that you can't use the cached user data to decorate the messages. You can also store a query that includes a join as in the example of a query meant to return "all private messages sent to user 5" That query can certainly be cached, and in doing so you will reduce load on your database. You just need to understand which queries like this need to be invalidated from the cache. So long as you have cache name schemes that make sense, it's not that hard to understand what caches you need to remove if data was added or changed. Most of those schemes are similar to way you might design a rest api.

MySQL uses a scheme where every user has a name & host component. So for example: root@localhost. It is possible to have wildcards for the hostname component, but typically accounts will start out being constrained to localhost. It's important to understand how this works, because permissions are then granted to a specific user@host combination, and if later someone adds a wildcard account for the combination (for example -- 'user@%' that user will not inherit/adopt the permissions of the existing user@localhost account. There will be a "root" level account for mysql that has all rights. By default, this is usually root@localhost. This user can create new users, change passwords, create databases and grant permissions for new or existing users to that database. Typically what is done for security purposes is: root level account creates a database root level account creates/GRANT access to the database for that user. Application will use this user to work with the database. Some of the specifics of the syntax of the SQL used to create a new user or assign it a password have changed over time between mysql and mariadb versions. Tools that were dependent on the syntax or specific password scheme may no longer work properly given a specific version. What your screenshot shows is that laragon is logging you in a specific configured user, that was created and given access to a database. That user does not have access to create a new database. This is a typical setup. You need to login to mysql as the "root" user that laragon setup initially. I think it is probably still 'root@localhost'. Apparently by default the root password was unset. This SO thread talks about this, although it is a 4 year old thread: https://stackoverflow.com/questions/50214540/laragon-never-use-mysql-password

I'm not that interested in looking at a defunct project, but the obvious question of where to start, would be -- have you for example, started with this line: $_list_archives = db_get_archives(); Have you dumped the result of that call and examined the data structure? Using this technique follow through the code, and anywhere that you expect archive or user processing to occur, do a print_r or var_dump and see what you can find. Alternatively if you have the option of xdebug setup, you could add a breakpoint and step through the code interactively.

All the tables involved must be InnoDB. InnoDB is now the default engine for MySQL, although in the past myisam was the default engine. Make sure that all your tables are InnoDB, regardless of whether or not they are used in relations. The InnoDB engine has a number of other features that are important (data caching, row level locking, transactions, Clustered Indexes...).

An inline style should be the last resort. Why are you looking at doing that rather than using css classes?

I'm not sure what the benefit of admitting such a thing would be. I will say that there are people who first joined this site shortly after it was first registered, so you can take from that what you will.

We are not psychic. Most likely you have a pathing problem with your code. Paste relevant portions or the script in its entirety so that we can see what you've done. Make sure to use the code button <> when you paste the code so formatting is preserved.

To add a bit to this, Namespaces solve one major problem, which is class and function name conflicts. Here's a simple example: namespace Gizmola; function substr($string) { return \substr($string, 0, 3); } $test = '12345678910'; echo substr($test); With a namespace, I'm able to redefine a built in function, as well as use the built in function in my customized version of substr. I can then include my function and use it as a library in other scripts: use function Gizmola\substr as substr; echo substr('Now is the time for us to use namespaces'); This becomes even more valuable when you are dealing with class libraries. Without namespaces, the use of a library would mean that every single class across all the libraries you might want to be using, would need to have a unique name. Namespaces solve this issue, and allow you to organize your code, and refer to other classes in an unambiguous way. I can reference any class definition by including its namespace. // Logger.php namespace Gizmola; class Logger { public function log() { // ... } } Some other code that wants to use the Logger class. namespace MyApp; require_once('path/to/gizmola/Logger.php'); use Gizmola\Logger; $logger = new Logger(); $logger->log(); If for some reason I end up using a class library that also has a Logger class, like Seldaek\Monolog, I can do that via the ability to alias a class or function when I use it: namespace MyApp; use Gizmola\Logger; use Monolog\Logger as AppLogger; $logger = new Logger(); $appLogger = new AppLogger('main'); $logger->log(); $appLogger->warning('Problem with MyApp'); Alternatively, I could reference it directly via it's namespace to get around the conflict: namespace MyApp; $logger = new Gizmola\Logger(); $logger->log(); $appLogger = new Monolog\Logger('main'); $appLogger->warning('Problem with MyApp'); The other benefit of namespaces, is that by applying a convention to the way you map a namespace to a directory structure, a class autoloader can determine the location of a class and load it at runtime. This is where PSR-0 and now PSR-4 come into play. Library authors who conform the directory structure and location of their code to these standards will allow their library to be easily integrated into any project. These standards were designed to incorporate the organizational structure of as many pre-existing libraries as possible, so there is some interesting code in there, but for most people, creating your own class is as simple as putting it into a directory structure that more or less maps to the namespace. Composer is able to install a component library, and make that available to your app with its own libraries, and provide an autoloader and static class map for you to use if you want it, relieving you of having to require classes or be concerned about placing them in specific includable directories on your server, as you had to do in the olden days before namespaces were introduced.

I've written about using the Timestamp type. It would be appropriate for your application, and a timestamp only requires 4 bytes. You want to turn off the basic timestamp features when you define the column, but that is covered in my article: https://www.gizmola.com/blog/archives/93-Too-much-information-about-the-MySQL-TIMESTAMP.html As Barand stated, a Datetime is not much worse at 5 bytes as of MySQL version 5.6.4 when some storage mechanics were changed. Previous to that a Datetime used 8 bytes, but now it's much more efficient, so long as you don't need fractional seconds. For a scheduling app either one is fine and they are basically interchangeable as far as PHP is concerned, and the SQL statements and functions you can use them with.

Do you have an Entity Relationship diagram we can look at? Every table needs a primary key. The key is used to tell the difference between rows, so it must be unique across all rows in the table. I'm assuming you are using InnoDB for all the tables. You need InnoDB for referential integrity constraints, row level locking and transactions to work in MySQL. With InnoDB, the data is actually stored in primary key order, which means that when you read a row by PK, whether that be from a direct query or join, the entire data of the row is also read. This is because the table itself is used as the PK index. Sometimes you will see this referred to as a "clustered index". This design adds efficiency to many normal operations because MySQL only has to read the data directly via the indexing process and doesn't have to read an index first and then use that to locate the data. Not all searches are based on keys, but many are. When you say "MySQL would not allow me to create Table3" what error are you receiving?

The architecture of what you have is not conducive to making the change you desire. All the UI is serverside code, driven by session variables. To make something like this work, you would want to rearchitect it so that you use ajax calls to add or remove an item from the cart or change quantity. Your PHP scripts would then be solely responsible for manipulating the session state on the server. In essence you want one of the types of javascript UI's that people use js frameworks like Vue and React to create. You don't need to use a javascript framework to create something like what you want, but you certainly would need to rewrite your code to at least have separate markup, that you then manipulate based on javascript routines that get or change the data via ajax. You basic ajax call would get the representation of the current state of the cart from the session, ideally in json format. You write a javascript routine that takes this data and builds the cart entries using it. Once you do this, your buttons make calls that add items, or delete them or change the quantity of an existing item. In each case, the ajax call makes an api call to the server, which in turn changes the sessions accordingly. Those calls then call to your routine that gets the state of the cart and renders it. You really should have no PHP code that is creating html markup as a string, since that will all be managed in js. Basically you need to go back to the drawing board, if it's important enough for you to make this works the way you want. I will say that it would certainly be worth the effort, if you plan to do any maintenance or in general want a more responsive UI that doesn't require a form post in order to represent any change to the state or contents of the cart.

People are often confused about the way checkboxes work in a form. The first thing to know about checkboxes is that they will only exist in the $_POST when they are checked. If they were checked, they will be keyed in $_POST by the name of the input (name="thing"). I didn't look that closely at all the code but here is an example of problematic markup. <p><input type="checkbox" id="var5" name="var6" value="yes"> do you like it?</p> <p><input type="checkbox" id="var6" name="var6" value="yes"> are you sure? </p> Here you have 2 checkboxes with the same name. I don't know if you did this deliberately or by mistake. Using the same name is allowed for cases where you want to have a few options that the user could check, and you want them to be grouped under a single POST variable. If one or both of these are checked, $_POST['var6'] will be an array that will have one or more of the value "yes" in it. The problem is that you don't know which of the checkboxes was checked. If you understand the things I explained, you should be able to pinpoint what your problem is. Often people think they will get a $_POST'var6'] element even if the checkbox is unchecked. That is not the case. In case of a boolean, for example, you need to check for the existence of the variable in the $_POST, typically by using isset or array_key_exists so you can make the appropriate variable initialization for your database insert when a checkbox is left unchecked.

In the future, please post your snippets using the code block button of the editor <>

What is the real question you are asking? PHP code in a PHP application is one component, loop or no loop. So it seems your real question is: 1 Query (with a join) vs. Multiple queries. 1 Query will always be faster and more efficient than multiple, unless there is something very wrong/unoptimized with the query. With that said, when you have static related tables, then having those tables cached can save you having to join the tables or do queries in a loop. As the result set will have to be "hydrated/expanded" within your PHP script to make use of those, or at least resolve the values you need from the cached lookup table, the complexity of adding all that code isn't often worth the pain, and might not even be more efficient in the long run, given a PHP script's short lifespan. What is certainly worth looking at, is the addition of a relational result cache like memcached or redis.

The purpose of a table like product_type would be to have categories of products. If you don't need that, then there's no problem removing the table. If for some reason you need to have a grouping of products by category, then you should keep it. The product_type.description is not redundant with the product description. It contain the name of the category, like 'software', 'hardware', 'drugs', 'groceries' or whatever else.

My advice on the specific things to change: All the sequential keys should be renamed to id. example: product_id should be id. When it is a foreign key in a table, then you use tablename_id. So for example, order_item.product_id is correct, and that links the "non-defining" One-to-many relationship between Product and order_item. Fix product_type columns PK should be id type_descrip should be description. Since product_type is a foreign key in product p_type will be named product_type_id Other product fixes p_description should be description In regards to your shortcuts, I would not do what you are doing. I would suggest that you just have a member table, and you load that table with 1 row. Your code can then bypass what you need to, but still be accurate and relationally correct. From what you have, and what I would have you do: Rename member_detail to member. Load your one user into member, with id = 1. Then you can use this special user for orders. A good way to do this would be to define a constant = to that key of 1. Recreate the relationship between member and order. The link should go from member.id to order.member_id in the modelling tool. Again it is a non defining one to many relationship.

I looked more closely at your page, and I have a better idea of what you have, and how you got it. To answer your immediate question, the way you would get data to a PHP script, is to send that data from your form via a POST. This means that your form needs to submit the data with a standard HTTP request. I don't want to spend too much time with your current form, for reasons I'll explain, but in regards to its current html you have this: <form id="formc" name="formc" method="post" action=""> Let's assume that your PHP script is available in the document root of your site, and the name of the script is "process_order.php" Then this would need to be: <form id="formc" name="formc" method="post" action="process_order.php"> The button that you currently have named "display" would need to be changed to a submit button. You could change some code there to do the processing you need, and put the contents into a hidden field in your form. When submitted, the PHP script will receive the contents of the form in a superglobal array named $_POST. Using that data, the script can then send it along to your payment system in whatever way is required. Here are some significant issues you need to understand: I now understand why you approached this question in regards to excel. You used some facility of excel to take some spreadsheets and generate a version of it in html and javascript. Unfortunately the code that is generated is not designed to be modified or enhanced. It includes a number of irrelevant functions and variables and code that serve the purpose of its origin, but have little to no value as a solution. It is very important for you to understand that javascript runs on the client, and calculations and derivations that involve money can not be trusted. Your javascript can calculate whatever it wants, but once someone understands what is being sent to the server as a result, they can simply bypass that and send the result they want. For example, sending an order where they get 5 items, but at the price of 1. This is a problem as old as the web, and while there are many sophisticated methods for taking care of this, the key one is to have the server code validate the order. For that reason, your server needs the same data available to the javascript, in terms of the items, pricing and options. Typically you have this code on the server, and use the server to generate the html and javascript the client uses, so that the client and server have the same source of data. Even in that case, you still need to use the server data to verify that the data wasn't tampered with. Your form is actually very simple, and there is really no value to any of the excel additives. I'm again guessing this was your way around the fact that you don't really know HTML, CSS, javascript or PHP well enough to code this up yourself. A competent web developer would have everything you need in a day, hand written code, possibly integrating some common css libraries or frameworks, and with clear and sensible code that can be maintained. A significant concern for any person would be the need to change your application due to changes in product availability, pricing or vat%. Your app would need to be modified anytime any of those variables change, which is pretty far from a basic level of competence. While I understand that you have this generated code, and your hope was to use it as a basis for getting to your final product, it would take any developer far more time and effort to attempt to do so, than to code it from scratch, which would also provide a far superior and maintainable solution than you will ever get trying to hack code that was generated for you, and has the remnants of excel links in the names of html elements and generated javascript function code. I am sure this is not the news you were hoping for, but I have to be candid that what you currently have is basically spaghetti, that will need a lot of work to get it into a form that looks valid and professional enough to satisfy a customer. As a mockup of what is actually needed however, it does a good job of demonstrating the product, pricing and options a page needs to implement. My advice to you would be to engage a professional developer to create this code for you, using the specifications discussed in this thread and via any additional communication you desire. You are certainly welcome to continue to pursue help here, but on the other hand, this is a community aimed at developers and not suitable to people who used a code generation system to create something that is convoluted and beyond their understanding, with the hopes of fashioning that into a solution for their business without having to learn the things a web developer knows. I'll just conclude this by saying that my opinions are based upon decades of professional experience, and I've seen questions similar to yours many many times. If you want to move forward, you will need to learn an awful lot about programming for the web, which is a highly technical and complicated pursuit. If you were hoping for a short cut where you can get what you have fashioned into a solution, I am afraid that is highly unlikely in my experience. Developers like myself who make our livings doing this, and frequent this forum as a way of giving back to it, simply would not take on a project like this, even though I can tell you that I could modify it in whatever ways you might want or need. I wouldn't for the reasons I stated, and neither should you.

Let's see if we can clarify some things about this project. From reading your initial post, and looking at your link, here is my interpretation of what you are asking: It appears that what you want is a shopping cart You have arrived at an html form While this may have started with excel, that is not relevant to what you eventually arrived at, which again is the simple html form and associated javascript Now that you have this form and javascript you want to expand its functionality The drop down lists of the form should be sourced from server side data rather than being static data in the html While not clear, you may desire some interactivity in the form based upon selections in the drop downs. You desire to have server-side processing of an order on your site which includes integration of a payment gateway If these requirements are correct, then my initial response to you is that this is a non-trivial set of requirements. It most certainly can be accomplished using HTML, Javascript and PHP, but regardless of the tech stack involved, this is a significant project. As a point of clarification, HTTP protocol is based on request & response. The client makes a request for a resource (URL). This request can be of a few different types. In the case of a form like the one you mocked up, that request is typically going to be a POST. When the server receives a request, it then returns a response. Typically that response is the HTML that is then assembled by the client/browser. At that point, there is no connection between the client and server. The connection to the server is closed, and interaction with the html page is happening on the client's browser. All javascript in the page is running inside the browser. These basics limit the level of interactivity possible in a web application. "Ajax" was an extension to the javascript standard intended to allow javascript in a fully rendered html page, to be able to make additional requests, without the client having to do another full HTTP request, which in turn would require the browser to have to reinterpret and rebuild the page. Ajax isn't a separate language -- it's just an extension to the built in javascript api that the browser provides. It allows a rendered html page to include javascript code that can make network requests which typically will be for the purpose of getting data from the server. It is nothing more nor less than that. It's also important to understand that traditional pre-ajax web applications were still capable of doing everything that ajax does -- only in a manner where all interaction required a normal HTTP request/response cycle. You can have a form, and when the user changes a drop down value, the form can be submitted and the desired HTML/javascript/css source can be returned based on the modifications made to the form. It's just not as efficient or user friendly as a page that incorporates ajax, and additional javascript code to manipulate the browser's DOM using data that may have been returned from the ajax call(s). Putting the complexity question aside, it would help to break things down into individual parts. For each drop down, what is the source of the data? Is it coming from a database? Then you need a PHP script that returns the drop down data and returns it, preferably in json format. You then need javascript code that can take the json data and recompute the relevant DOM object (in this example, the drop down). You also clearly will need a serverside script that accepts the submitted form, and if everything checks out, saves the order, and then makes the payment gateway request for payment processing. The status of that payment gateway request from the PHP script to the payment gateway then needs to be saved in the order, and a response returned to the client. None of this is actually stated in your question, so I'm extrapolating additional stages and steps that I know exist for any shopping cart/ecommerce application. Again this is a big project, with a lot of complexity that requires a solid foundational understanding of html/javascript with ajax/json/http protocol/PHP network client request. Phpfreaks exists to help people of any level work towards their goals, and aims to help advise and educate. I hope this might give you a better idea of what you will need to accomplish from a technical standpoint, and that this is not a simple project for which a simple solution exists. Because ecommerce is non-trivial, often the best way to get to a solution, is to utilize a commerce platform like Shopify, or a CMS like wordpress with an extension like woocommerce.

Here's a few suggestions for you: Convention is important. Pick one and stick with it. You change your convention in nearly every table. Make your table name singular. Member (not Members). Product (not Products). Notice you made a table named Order. This is an example of the many inconsistencies you introduced. If a table or column is a compound word, use underscores for spaces. Don't use camelCase. Save that for your PHP code. productType: change table name to product_type. Note you did this for some columns like order_item_id (although as a pk, that should just be named 'id'. Make all table and column names lower case. Don't mix case. Example: orderID Use underscores for words in tables and columns Example: orderDate. (Use order_date) Don't add in the table name for columns in the table Example: productType. typedescription. (Just name column "description".) Name any sequential primary key columns 'id'. Don't add in the table name. (For Members table you inexplicably named the column userID.) Just call this column 'id'. Example: productType.pType?? Should just be id. When relating tables together, if a relation creates a foreign key column in the table THEN name that column tablename_id. Examples: In product table, product_type_id will be the fk to product_type.id. If you consistently apply a list of rules/conventions like this: it is much easier to use ORM's to map from the relational tables to model classes. Many ORM take conventions into account by default and mapping works automagically. Otherwise, you often have to make map file tweaks. Writing your embedded SQL code is simpler and easier to understand, because you know what a particular column name should be called. You know what columns are foreign keys, and which columns you need for making your joins. There is far less change of a typo screwing up a query you write. SQL statements are less likely to have errors. You can also clearly differentiate sql tablenames and columns from variables you create to represent values you fetched from the database. You also already will easily know the array key names when using routines that fetch a row into a php array, indexed by column name.

In this case, it's incorrect. Your code is essentially lifted from the manual. You need the die/exit after the readline(). die() is the same as exit() See https://www.php.net/manual/en/function.readfile.php There is no need to die() if the file doesn't exist really, as the script will do nothing. If you really want to handle it in the right way you should deliver a 404 error. You also seem to miss the point I made in that your downloader can be used to download any file that is passed to the get parameter. The fact that you are using a button is irrelevant. There is some problem with your code, because no path to the file was being picked up by the get parameter.

The errors are telling you what the problem is. You aren't showing us the full code either. You're cherry picking the wrong code. With that said, the code you posted has an obvious bug in it: function usdloader($l_filename=NULL){ if (file_exists($l_filename)) { $file = preg_replace("/\s+/u", " ", $l_filename); header('Content-Description: File Transfer'); header('Content-Type: ' . mime_content_type($file)); header('Content-Disposition: inline; filename="'.basename($file).'"'); header('Expires: 0'); header('Cache-Control: must-revalidate'); header('Pragma: public'); header('Content-Length: ' . filesize($file)); readfile($file); else die; } } Look at your blocks. Blocks need to be separated by { }. Your code has a superfluous else in it. Why? This is what you meant to do I guess: function usdloader($l_filename=NULL){ if (file_exists($l_filename)) { $file = preg_replace("/\s+/u", " ", $l_filename); header('Content-Description: File Transfer'); header('Content-Type: ' . mime_content_type($file)); header('Content-Disposition: inline; filename="'.basename($file).'"'); header('Expires: 0'); header('Cache-Control: must-revalidate'); header('Pragma: public'); header('Content-Length: ' . filesize($file)); readfile($file); die; } } Even with fixing that, we are missing the code that explains why "$file_url in <b>/home/foxclo98/public_html/mydloader.php</b> on line <b>21<". After your preg_replace, you have an empty string. Why is that? What are you trying to do with this preg_replace? $file = preg_replace("/\s+/u", " ", $l_filename); All you appear to be doing with this is take whitespace and replace it with space. What is the value of that? Why do you allow for any spaces in a file name? It's also important to note that this code will let a person download just about any file on your server that the apache server can read. For example, if someone crafts a url and passes this to your script what happens? mydloader.php?f=%2Fetc%2Fpasswd

He literally gave you code that works, only missing a semicolon: $result = array_udiff($table, $newdata, fn($a, $b) => $a <=> $b); var_dump($result); If you are familiar with Javascript ES6, it is a similar type of anonymous function shorthand, equivalent to this: $result = array_udiff($table, $newdata, function($a, $b) { return $a <=> $b; }); You need to have a current supported PHP version ( >= 7.4) although the syntax I showed works with any version 7.x or > The "arrow function" version was introduced with php 7.4

Most of these are named in a way that is fairly self explanatory, but sometimes you have to just take a look at the class to see what it is doing. \App\Http\Middleware\TrustProxies::class -> https://laravel.com/docs/9.x/requests#configuring-trusted-proxies (If you are using a proxy server or load balancer, this handles certain issues that arise) \Fruitcake\Cors\HandleCors::class -> https://github.com/fruitcake/laravel-cors (Configure your framework to set certain CORS related HTTP Headers) \App\Http\Middleware\PreventRequestsDuringMaintenance::class -> https://laravel.com/docs/9.x/configuration (See how to turn on Maintenance mode using artisan. Once it's turned on, this middleware enforces it) \Illuminate\Foundation\Http\Middleware\ValidatePostSize::class -> See source https://github.com/laravel/framework/blob/5.8/src/Illuminate/Foundation/Http/Middleware/ValidatePostSize.php (Notice that code just checks the configured PHP post_max_size against the size of an HTTP Post request. If the post request is too large, laravel throws a PostTooLarge exception.) The last 2 are again, very similar. Looking at the class definitions from the manual will show you what they do, and the code is simple and self explanatory, especially once you understand the things I explained about how middleware works in Laravel. See https://laravel.com/api/9.x/index.html and find the 2 classes.