gizmola

It's really very simple: you can not start output before session start. You are outputting HTML at the start of your file, which sends the http header, so there's no way for PHP to provide the cookie with the session id. This is a big reason to have a bootstrap script or front controller so that you can do essential initialization and setup in one place. Obviously you don't have either of those currently, but you could for now make a script named something like "initialize.php" and put things into it that you always want to do, like redirecting to https://, configuring a database connection or starting the session with session_start. Then it's just a matter of going through other scripts and adding require_once("initialize.php") as the first line.

So, first off, json is a data format. A "json file" is just a file that contains serialized json, that can be unserialized back into a json structure. The primary use of json is to provide interoperability between javascript functions, and in many cases persistent storage. Yes, you should use json to for example, provide data to ajax calls, but that would be something you would design into your backend api and javascript UI code. You can for example, read data from a database and easily turn it into json format using the json_encode() function. Ditto with receiving client information and converting it back into arrays or objects with json_decode(). As these are just notes telling someone what to do, there isn't any intrinsic benefit to storing the data in json format, and even less value in having that json be in a separate file that needs to be maintained, tracked, read from and written to. If you had chosen to build your app around MongoDB, that uses json format to store data and query the db, that would be another thing, but your idea about using json, clearly is making your system less uniform and stable, with no strong justification. Just use a mysql text column. Again, I don't know if you have 1 table, 3 tables or 50 tables. Even without knowing that, I can tell you some things, based on the information you've provided: This "Ready to Load" flag is for: A truck For one load Again, I don't know anything about your business, so I don't know if a truck can have multiple loads in a day. These details are important, because they are manifested in a design that will work, vs. one that doesn't. As for the note itself, the thing that jumps out at me, is your statement that these are just instructions for the person printing out ERP material. Again, I don't know who enters these notes, but I assume it's a back office person, so the obvious question is: why isn't that note being put into the ERP? Doesn't the person printing the material use the ERP to view and print the appropriate materials from it? Seems like that should be something in the ERP and not in a totally separate system. Let's assume that you are going forward with your current plan --- For example, let us say you have a truck table, so you add a "ready_to_load" attribute (tinyint: 0 or 1 value) and a "print_notes" text field that you put notes into. "someone" in your company sets this flag based on some criteria, which then should signify to the "manifest printing person" that various documents from the ERP system need to be printed, and some additional activity should happen. I should also point out that these are 2 different features that aren't really associated. One is an activity flag, and the other is some information for a person performing a particular activity. What are the potential problems putting both these things into the truck table? How does this data get reset? Perhaps when the truck is loaded there is a button that a user uses when the truck leaves the depot? It's unclear. If users are expected to interact with the system, reset the flag, and overwrite the note, you have a situation where you invite mistakes because a user forgets to clear the note, and on the next load, people are operating based off notes from a prior load. A person could see a flag set and prematurely print manifests that aren't actually ready yet. If you reset the flag and empty the note, the data is now lost forever. If the instructions weren't followed, how do you know what the were, and where the mistake was made? Did the original instructions omit something needed? My best guess is that this information should go into a table related to truck that has a one-to-many relationship to it. It might be named "truck_load". truckload ---------- truckload_id (int unsigned primary key auto_increment) truck_id (foreign key containing truck_id from truck table) load_date (date, datetime or timestamp, depending on requirements) ready_to_load (tinyint, default 0. 1 indicates ready to load) notes (text) This is my best guess at what you should have to make this work. One row for each truckload. You can join to the truck table using the truck_id, and will display the data for the particular day or day/time combination.

I do want to just throw in my 2 cents and say that the schema Barand provided is the simplest solution, but not the one I would use for a variety of reasons. In general, a better solution is to design things so that when there are changes, as in for example, a boat is moved from one berth to another, you don't lose history. Another example, might be a boat being sold to a different owner. Certainly you could just edit the boat record and change the owner, but you'd in the process lose the data that showed who the original owner was. In general the solution to this is to add many-to-many relationships which require an additional table and "fromDate" and "toDate" columns. It does add some complexity to your queries as well because you need to be concerned with datetime ranges, but once you understand how to query with that additional criteria, it's fairly simple. Adding to Barand's example, I would personally have a table named boatBerth or berthBoat. This table will resolve the many -to-many relationship between boat and berth. This table would need it's own primary auto_increment key, and a foreign key to both boat and berth. The final ingredient would be fromDate and toDate columns, establishing when this row should be considered "active" or "current". berthboat ========= berthboat_id (primary key auto_increment) boat_id (fk to boat) berth_id (fk to berth) from_date (datetime) to_date (datetime) In order for this to work, the secret is that to_date for an active row should be set to the max allowable datetime which is for simplicity sake '9999-12-31'. A datetime has a time component, but if you omit the time portion when doing an insert or update, it will be upscaled to include a time, which isn't important. So lets say that you have boat #7, that is going to be docked in berth #23. Here is an example of the data in berthboat: berthboat_id: 1 boat_id: 7 berth_id: 23 from_date: '2021-04-14 12:32:17' to_date: '9999-12-31 00:00:01' Next week, boat# 7 gets moved to berth: 29. What needs to change? 1st, update the to_date for berthboat_id to be the day/time the boat was removed from berth# 23. berthboat_id: 1 boat_id: 7 berth_id: 23 from_date: '2021-04-14 12:32:17' to_date: '2021-04-18 09:01:01' This indicates that at 9am the boat was taken from berth: 24. Look at all the information you retained: You know that boat#7 was in berth 23 from April: 14 to April 18. Once it's docked in berth 29 a new row is added: berthboat_id: 2 boat_id: 7 berth_id: 29 from_date: '2021-04-18 15:32:17' to_date: '9999-12-31 00:00:01' This shows that boat#7 was moved and perhaps after some maintenance was docked in berth# 29 at 3:32pm. Times might be important for billing purposes or general history. You now have history either for the boat (was in berth 23, then moved to berth 29) or for the berth (boat 7 was in berth 23. It is currently empty.) MySQL like most relational database engines has some useful date/datetime functions that make determining what the active rows are. So for example, omitting the joins to boat and berth that you would probably want to do, depending on the data you're pulling, let's just say you only wanted the current active berthboat rows. MySQL has CURDATE() and NOW() you can use, which are equivalent to the current date or current date/time. So let's say in 3 weeks time, your system should only show a list of the current active berthings. The underlying query could be as simple as: SELECT * from berthboat WHERE NOW() BETWEEN from_date AND to_date In this case, your result will contain the row with berthboat_id = 2, but not the original berthboat_id = 1 row. This allows you to retain the history of all berth assignments, and could even be used for scheduled movements in the future, because you could have a from_date of next month, indicating that a boat is scheduled/will be moved to a particular berth. That row can co-exist with the row indicating that a boat will be removed from a berth in a couple of weeks. Most of the time all you are doing is updating the from_date of a berthboat row to indicate it is no longer associated with a berth and/or adding a new berthboat row to indicate a boat now resides in a berth. When you don't know how long a boat will be in a particular berth, you use the "perpetuity" date I illustrated previously. A similar scheme could be used for the relationship between a boat and a member. Again this would allow you to keep track of which owner owns a particular boat at a point in time, while not losing the information that previously it belonged to another member, and was perhaps sold to a new member. Again, this is probably what you want to do, but then again, I don't really know the full extent of your use cases, so it also might be overkill. The important distinction between this design and the original one from Barand, is that Barand's design will allow you to reflect the state of things at present, but can not retain any historic data, nor support advance pairing of boats and berths.

I can't make any guarantee as to the ramifications of doing this, because you are working within the constraints of WooCommerce and Wordpress, but to solve your stated issue: function onboarding_update_fields( $fields = array() ) { $user = wp_get_current_user(); $roles = (array)$user->roles; $fields['billing']['customer_type']['default'] = empty($roles) ? 'Guest' : $roles[0]; return $fields; } add_filter( 'woocommerce_checkout_fields', 'onboarding_update_fields' ); This uses the function empty() to determine if the $roles array is null/empty/unset, and based on that will set it to 'Guest' or the role name as it did previously.

There are a lot of different ways to run PHP. You can't separate a security strategy from the operating system, privilege of the web server, or privilege of the PHP script and the user it runs as. There are also bugs and gotchas that can occur, not to mention differences between operating system filesystems as to the characters allowed to be used in a filename. Requinix and Kicken both have a lot of real world experience, so they are going to provide you advice that is also opinionated. Personally there is very little benefit and a lot of potential risk to allowing users to create their own directories and files on your server, with names of their own choosing. You can always store this user input in a table, and utilize the name in various features if you really want to, but don't forget that a single bad actor could be crafting a name that may have no effect on your server, but could launch an exploit on the system of an end user. Obvious concerns are when people try and craft paths that traverse your file system using slashes and periods. Another concern is file names that could trick parsing like file.jpg.php or some other name that might trick your system into executing code. A user could be using a character set that isn't supported by your file system, again causing a potential exploit that you aren't aware of. Or just allowing a name that causes your system to malfunction, because the name of the file includes case sensitivity or insensitivity, that either tricks or breaks your system entirely. Many OS's allow filenames that include spaces, tabs, and all sorts of other non-printable characters. Do you really want to open up your server, to the possibility of users creating hidden directories full of god knows what type of files, which perhaps appear to your system to be valid, but contain hidden payloads?

Sessions have expiration that you can set, as do cookies, so you have a couple different ways of handling it. I don't want to complicate things, because the way session files are cleaned up is complicated, and highly dependent on the amount of traffic a site has. Also, keep in mind that a session does not equal access. A session is just some stored data associated with a browser/client. So for example, let's say you allow access to a site via login, and you want that access to expire after 15 minutes of inactivity. One way to handle that is to have a last_request column in the users table which stores a timestamp. You can also alternatively, store that value in the $_SESSION itself. When a "logged in" user makes a request, you have an access check that reads this value and does some simple math against it (timestamp - last_request) and depending on the amount of time that has passed, you can allow the request to proceed, or if too much time has elapsed, remove whatever session data you have that indicates this user logged in successfully and redirect to the login page. Sessions are just a way to simulate a persistent connection across HTTP requests. They can facilitate your security scheme, but they aren't providing access or rejection of anything. I would suggest reading about cookies. Again they are the preferred method of session identification. As long as you only allow secure sessions (and cookies) you can avoid a lot of security gotchas, but cookies themselves can have expiration. Just keep in mind, that cookies like anything else that comes from the client can not be trusted. The client should honor the cookie settings when the server tells the client to set a cookie, or expire it, but that doesn't mean that the client will do that. For normal browsers, they certainly work as per the RFC for cookies specifies, but the request could come from some hacker who is using a modified browser or browser simulation code, that looks to your server like a regular browser, but isn't. In general, any data you get from a client has to be considered suspect, and that includes all forms of data the server gets from the client including the data in $_COOKIE. Most systems will include a variety of different methods to facilitate security. For sessions, another best practice is that anytime you escalate privilege (login, access to change secure data like a password, or financial transaction) your code should regenerate the session id, and re-prompt for authentication. I could go on in the abstract about this topic, but I really only intended to try and get you a jumpstart on your understanding, which I hope I did successfully.

Are you familiar with database design and normalization? Do you have a schema diagram or structure of the tables? The main thing I can glean from your question is that you probably have a truck table, and that this is either some information where there is a 1-1 relationship between that information and a truck OR it is information that is related to a truck that is good for a period of time (ie. it could be current information with an end date, such that there would be a historic record of this information, but you also want to be able to locate and provide the current data for a particular truck, ignoring information that is now essentially expired. Really in order to design or alter a database schema appropriately, the requirements need to be clear and well understood to make the proper enhancements.

It is a great idea to read the PHP Manual page on session handling. There are many things you can configure about them, but to elaborate on kicken's answer here are a few things about Sessions that might help you understand them better. A session has to be started with session_start() prior to you doing anything else that might cause browser output from the server to the client. I'll explain why in a second. A session is entirely a server-side concept. Changes that happen to the $_SESSION variable can only been accessible to your client when a request (GET/POST, etc) is made. By default, a session has associated serialized data in it that mirrors the contents of the $_SESSION superglobal variable. So in your serverside php script, whatever changes are made to $_SESSION are immediately also saved/serialized, allowing you to restore them into the memory for another PHP script. So the obvious question is: how does PHP figure out whether a session is associated with a particular client/browser. This is done via a session id. The typical way the id is passed to PHP is via a cookie. Keep in mind that the way browsers handle cookies is that, for a domain, if a browser has a cookie for that domain, it will pass all the contents of the cookie data to the server for every request. Also keep in mind, that the server can set cookies by including in a response header, the cookie data. This explains why session_start() must occur before any output is sent. session_start() determines if there is already a session that exists by reading the cookie data and seeing if it can find a matching session id, OR it will create a new session, assign a unique session id, and add the http header to set the cookie. As soon as a response is sent, the client/browser will set the cookie, so that in requests that follow, PHP scripts can read the stored session data into the $_SESSION variable for use in your scripts. Hope this helps with your understanding.

Yes there is, it's called the "global even scheduler". Given the inherent limitations of a scheduler that runs within the rdbms, I haven't found it to be a highly used feature. It also has to be turned on by a user with root level access, I believe. You create events using a CREATE EVENT statement. They can be scheduled to run once, or to be recurring at a certain interval.

The 2 languages have their own ecosystems. Either one is a good choice for web development. For fortune 500/corporate systems who tend to prefer support contracts and microsoft based infrastructure, there tends to be a wider use of .NET/c#. As PHP is Free Open Source software (FOSS), it has a wider adoption in the SAS/startup space, paired with one of the open source rdbms (postgresql/mysql) or Document databases, whereas, typically you see .NET run on microsoft server infrastructure and MS Sql server. It also has a healthy amount of competition from Nodejs/MEAN stack. One unusual feature of the PHP development space is the variety and high quality of MVC frameworks, with the two primary competitors of Symfony and Laravel that are both supported by large active developer communities. It really depends on what type of system you are trying to develop, and the target market or customer for the system. Coming from c# you should be able to pick up PHP quickly, but you want to get familiar with composer and either of the 2 frameworks I mentioned, if you really want to get a feel for what professional developers do with the language and platform. One other thing to note, is that as PHP is typically deployed on linux servers, now more and more in containers, you really want a good working knowledge of Linux, and this is something that .NET developers sometimes don't have.

Try using chrome dev tools and looking at any errors being generated. You are asking us to guess, and that's not the way to figure a problem like this out.

I removed the apikeys from your message. Keep in mind this is a public forum, spidered by google. Even if those are development keys, you don't want to publish them to the world.

How are we supposed to help you when you haven't provided any information at all about the chat server/system you installed?

I haven't seen a lot of your code, but the other thing that jumps out is that having functions where you are passing 4-5 parameters indicates that you probably have blocks of code that are trying to do too many things, and are not discrete enough. I certainly could look back at code I wrote in the past and admit I did the same thing on many occasions. This leads to the type of problems you are concerned about: large code base, concerns over side effects if you make a change, cascading throughout the code, lack of DRYness etc. This tends to happen when you build everything from scratch, as your code evolves into a thing "that works for what I have" rather than something designed from the outset to be clean and maintainable, and unit testable. While you can't go back and change large swaths of the system now, you certainly can improve it incrementally by writing smaller more discrete functions for anything new or currently undergoing modification, and refactoring whenever possible. Sometimes a small improvement can be game changing in terms of system quality and maintainability. Write functions that do one thing, and always return a result of the same type. Most functions should have a handful of parameters. If there are more than a few essential parameters, look at ways to break the function into smaller more discrete functions/pieces that you can use to assemble your results Obviously having functions with 1000's of lines of code is hard to work with. Most editors have ways to open multiple windows and add bookmarks in your code, when you have to move from one to another. Some of the fancier IDE's also let you jump back and forth in your code, by creating linkages from the files where classes and functions were defined that the editor can then use to open the appropriate file when needed, akin to clicking on a hyperlink. PHPStorm has that type of function, and can really help when navigating a large codebase.

We don't have enough of your code to look at but to be clear -- when passing by value, you can update the array inside the function. You can echo out values, make assignments etc. and everything will look fine. Any of those changes will be discarded once the function exits, however, as inside the function you are working with a copy of the original variable as it was when the function was invoked. If this is not the issue, then we need to see some actual code, to help further, as anything at this point is simply an educated guess.

Defining a function with optional parameters is done the way you did it. <?php function foo($bar, $fruit=null, $candy=null) { echo "bar: $bar" . PHP_EOL; echo "fruit: $fruit" . PHP_EOL; echo "candy: $candy" . PHP_EOL; } foo('one bar'); foo('one bar', 'apple'); foo('one bar', null, 'snickers'); With basic functions, all parameters are passed by value, not pass by reference. $error = array('message' => ''); function testparams($msg, $error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); // Original error array was not changed, because it was copied internal to the function echo "Error: {$error['message']}" . PHP_EOL; To get around this, you can tell PHP that the $error array should be passed by reference, and change the original array variable. $error = array('message' => ''); function testparams($msg, &$error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); echo "Error: {$error['message']}" . PHP_EOL; // Result is Error: BAD SYSTEM

Think of it this way: Array1 (I'll call 'titles') is the destination array. It is static as defined, and you will update it based on the contents of Array2 (which I'll call 'images'). You do not need nested foreach statements here, only a foreach through the images array. // Get the person_id $person_id = $titles['person_id']; //Loop through images $index = 1; foreach ($images as $image) { $titles[$index]['person_id'] = $person_id; $titles[$index]['name'] = $image['name']; $index++; } This code is susceptible to issues with the structures you provided. Here is some testable code: $titles = array( 'person_id' => 3, 1 => Array ( 'title' => 'qwerqwer', 'medium' => 'dfsadfasda' ), 2 => Array ( 'title' => 'sadfasdfad', 'medium' => 'Asdfsadf' ), 3 => Array ( 'title' => 'asdfsadf', 'medium' => 'Sadfsedf' ), 'submit' => 'Submit' ); $images = array( 'image1' => Array ( 'name' => '_DSC0080.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpxY22EN', 'error' => 0, 'size' => 1784656 ), 'image2' => Array ( 'name' => '_DSC0030.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpy2Wq43', 'error' => 0, 'size' => 1724811 ), 'image3' => Array ( 'name' => '_DSC0001.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpZSBkAp', 'error' => 0, 'size' => 2278345 ) ); // Get the person_id $person_id = $titles['person_id']; //Loop through images $index = 1; foreach ($images as $image) { $titles[$index]['person_id'] = $person_id; $titles[$index]['name'] = $image['name']; $index++; } var_dump($titles); The result: array(5) { ["person_id"]=> int(3) [1]=> array(4) { ["title"]=> string(8) "qwerqwer" ["medium"]=> string(10) "dfsadfasda" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0080.jpg" } [2]=> array(4) { ["title"]=> string(10) "sadfasdfad" ["medium"]=> string(8) "Asdfsadf" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0030.jpg" } [3]=> array(4) { ["title"]=> string(8) "asdfsadf" ["medium"]=> string(8) "Sadfsedf" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0001.jpg" } ["submit"]=> string(6) "Submit" }

Alternatives to doing xampp is to use either virtualization and vagrant, or use Docker. Most development teams have moved to Docker, since many sites are now using Containers to deploy their infrastructure. Docker containers are like mini servers that run something for you, so you would have for example, an apache container, a mysql container and a php container. It is also very easy to add other containers to the mix, like a redis container, or a reverse proxy with traefik or nginx. Docker makes managing the internal networking for this very simple. The containers can all be started/stopped with a single Docker-compose. Since this is all running on your workstation/laptop/whatever it has the same advantages for iterative development/testing/debugging as doing xamp or mamp for the most part, as well as advantages you xamp doesn't have, like starting up multiple containers of a type to test out load balanced/clustered systems, or quickly testing a different version of php to see what breaks. There are a few different projects that have configurable/pre created packages aimed at PHP developers and make it easy to switch in/out different pieces (mysql vs postresql for example). These attempt to make the use of docker similar to an xamp or mamp install. In all cases you do have to start with installation of docker itself, but after that these packages can be a convenient way of getting started without learning much about docker. Here are a couple to look at: http://devilbox.org/ https://laradock.io/ Laradock was created for use with Laravel framework apps, but also works great for other framework based projects or any LAMP/WAMP/MAMP based project. Personally, I use Docker now, whereas in the past I used Vagrant files. One last thing to note is that php has a built in server for a while now. As I am frequently working with the Symfony framework, the symfony project makes it very easy and convenient to develop your apps, although this does assume that you would have a local mysql or mysql in a docker running. Details for installation and use are here: https://symfony.com/doc/current/setup/symfony_server.html

The basic features of PHP Oop are one thing. Do you feel comfortable with those things? In particular: What is a class vs an object What are class properties What is the difference between the property visibilities (public, protected, private) What are static properties What are class methods, and what visibilities can you use How do constructors work What other magic methods are useful What is inheritance What is an interface What are static methods? What syntax can you use to call a static method What are traits Once you are clear on the syntax and mechanics of php OOP, then you can read more about the way OOP is typically used. These OOP design patterns provide a way to design your code so as to get maximum value and avoid many pitfalls that exist when people first start out with OOP. Here are some resources that might help: Dependency injection articles by Fabien Potencier, founder of the Symfony framework. This is important to understand, as DI is the foundation of the most popular PHP frameworks: Symfony and Laravel, as well as any number of other projects and component libraries. http://fabien.potencier.org/what-is-dependency-injection.html Design Patterns in PHP https://phptherightway.com/pages/Design-Patterns.html More design patterns in PHP https://refactoring.guru/design-patterns/php

It does seem that in your mind you build things up to be a mountain, when they aren't. I don't see using some sort of version control as an option. It's just the overhead of doing any sort of professional coding. I honestly don't see how you continue to develop without it (or some other sort of version control). I don't understand every nuance of git. I have spent time going over some of the fine points, reading about the internals, and practicing, but for what I need on a daily basis it comes down to a handful of commands. Things you need to do at the start. -Your development and production systems need git installed -You need to initialize your code base to git. (From project directory root...) git init -You may have to create a .gitignore file to indicate which directories/files not to add to version control -You have to add all the files (stage them) git add -You have to commit your staged files. git commit -m "commit message" -You have to create your github repo, and push your files to it. git remote add origin [email protected]:username/new_repo git push -u origin master -At this point you'll have all your files in your private repository, in the master branch. Just about everything you need to do here is described for you in github. Daily development: -Decide what you are working on -Create a "topic" branch git checkout -b some_new_fix -Now you are in branch some_new_fix -change files however you please. Add files, modify files, delete files. Test until you are happy. -Want to review the things you will be changing? git diff -Add files git add -commit the changes git commit -m "Some fixes like..." -push this new branch to your remote (github) git push -u origin some_new_fix -merge changes git checkout master git merge some_new_fix -Push the master branch git push Your production system should be based on the master branch from your repository. You would use github as the source by cloning your repo as the production structure. Pulling any new code into the production master branch is now: git pull That is the basic flow of doing things, with just about all the commands verbatim. You could make a test repository, play with these commands, push to github, clone the project to a new workstation or subdirectory, etc, and the entire process of doing this and getting comfortable with git would probably take you an hour or 2.

Perhaps it isn't clear, but with version control, and at this point, the world has standardized on git (for relatively good reasons in my opinion) there is no danger in changing "tested code." This assumes that you have a development/test deployment and a production deployment. If you only have "production" -- well, it goes without saying that the second you have any actual users, you are in big trouble. So, I will make the assumption you have a dev/test system, and again, there is no question that you can change anything you want with git, and test things, and you can do these tests with impunity, and without endangering anything in production. Learn git. Bitbucket and Github are origin repositories where you can keep a master copy of your code in the cloud. They are both used by lots of companies, and both offer private repos for no cost. There are limits to the numbers of people and repos you can have, but in your case either one will be fine. I have accounts and use both frequently, but my recommendation to you would be to use Github. Make an account to begin with, and there are a gazillion tutorials, including interactive ones that will teach you the basics.

Not understanding -- sure that is an issue for many people. I will grant you that there is a learning curve, and for many people the big picture is difficult. With that said, most of these projects had great documentation, and tutorials and demo projects to help people learn them. Writing everything from scratch was a mistake, because your site should have implemented MVC to give it a sane and maintainable structure, and you also clearly wrote lots of code that doesn't have a set of robust unit tests, so your site is inherently more buggy and less stable than it would have been if you had used a framework. You also reinvented the wheel, big time, rather than concentrating on the important things, as in your business logic ,and the functionality of your site. To rationalize this decision as a "challenge" when that challenge did not even include learning the basics of PHP OOP -- is It is what it is, but the path to becoming a better developer is being able to admit you made a mistake. Most project teams include a post mortem for this exact reason -- to reflect on the process, evaluate what worked and what didn't and hopefully improve.

Pretty full article on using the various Geometry and Geospatial features of MySQL and it includes manual references. Using the Postgis extension with Postgres. It's also worth looking at MongoDB which has pretty much had a GeoJSON type since it's initial release, as well as indexing to support it.

This is not the problem you seem to think it is. Really the only really insurmountable problems that can't be fixed with media queries, would be if you are styling predominately through the use of inline style statements echo'd in your php code, or if you have the entire site layout in multiple nested html tables, as was the case for many a site in the olden days. Something as trivial as a margin/padding etc. is not a problem at all. You do a media query and simply change the things that are not mobile friendly. For example: @media only screen and (min-width: 320px) and (max-width: 480px) { .logo img { width: 60px; } .company-name { margin: 0; padding: 0; font-family: Helvetica,Arial,sans-serif; font-size: 25px; } .company-pictures { display: none; } } Simple examples of common things you might do for mobile (use a smaller or different image for a logo, redefine a style class you apply to certain elements, completely hide a block that is nice to have but not essential for mobile users). For the record, 8 years ago there were a lot of things available that you could have used to build your site with. MVC frameworks like Zend Framework (2006), CakePHP (2005) and CodeIgniter (2006). Symfony 1 was released in 2007. Symfony2 was released in 2011. Not long after that, composer was released. Laravel was released in June of 2011. I have made efforts to make you aware of some of these projects in the past. Fear of breaking things you manually tested should not be an excuse not to change code, either permanently or experimentally. Is your code in a git repo? Have you pushed this to a private repo under github or bitbucket? If not, why not? If so--- Here's what you do: Make a branch (git checkout -b css-test Change as much or as little code as you want to experiment Commit your changes (Optionally) push your branch to your repo [while in branch] git push -u origin css-test If it goes to hell, no big deal, you made a branch and you can delete it if you want. If things work out, you merge your branch to master.

Adding onto Barand's reply, here's the technique to ingest the original integer and turn it into an array of digits. function mul(int $int) { return array_product(str_split($int)); } echo mul(12345); // 120