Jack

Some will refuse to work on sites they don't control because they don't know how bad the underlying site or code is. It could be built with a page builder and the efforts may not be worth it. There's also a risk that the external developers could undo your work, or could affect what you have put in place. Strategically it often makes more sense to handle everything on a single side IMO.

The point in having this assigned to you as part of university is to implement it yourself. Even if someone could write it here, you would get very stuck trying to explain the code out if you were required to.
Multiple journeys could be plotted as an array of objects. This could then be used to plot onto a map using the latitude and longitude of each location.
[ { destination: 'Victoria', coordinates: { lat: '52.621780', lng: '-1.113930' } }, { destination: 'Oxford', coordinates: { lat: '51.514960', lng: '-0.144460' } } ] To actually plot these when you click, you need to store the coordinates so that you can query against a service like https://developers.google.com/maps/documentation/javascript/examples/directions-waypoints

I highly recommend you take the time to learn JS at even a fundamental level, or you will really struggle to understand any of this. Some resources that may help are (in order):

https://frontendmasters.com/bootcamp
https://frontendmasters.com/workshops/js-fundamentals-to-functional/ (paid with free trial)
https://javascript30.com
If you go through each of these in full, you will have a significantly better understanding of Javascript and programming in general.

Ah, my next "favourite" topic - the almighty ORM (just kidding). From the OOP principles point-of-view any ORM (or similar) tool is an anti-pattern. I wouldn't start that flame now. 
In my humble opinion using ORMs is making developers bad at database design. The most common mistakes are:
Improper relations between entities Lack of or dump indices Using ORM classes as anemic objects with data I am not saying that ORM tools are bad at all, but let me ask you following questions:
How many developers do you know to be using proper ERD (Entity Relationship Design) tools? How many of them are using Generalisation / Specialisation properly when it comes to ER modelling? How many of them knows how to use database indices properly? How many of them understands Database Normalisation in general and Normal Forms? Having to know when each tuple was created (created_at) or modified (modified_at) doesn't add that much value to neither your product nor data. The other funny part is so called "soft delete". Having such "hidden" rows in your table(s) would lead to database fragmentation and overall performance penalties. Let's see it in action, assuming we have following structure 
CREATE TABLE `users` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `username` varchar(64) NOT NULL, `email` varchar(255) NOT NULL, `email_verified_at` timestamp NULL DEFAULT NULL, `password` char(40) DEFAULT NULL, `remember_token` varchar(255) DEFAULT NULL, `created_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `email_unique` (`email`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 And have following considerations:
We are using (almost) standard users table provided by Laravel framework We are using TIMESTAMP columns for created_at and updated_at to utilise CURRENT_TIMESTAMP predicate and no to bother with handling these columns in our code (That's the power of Eloquent ORM here) We are trying to put our data footprint as small as possible hence password column is CHAR(40) assuming we will have SHA1 hashes instead of plain text password Now let's try to find most recently created user, a simple SELECT query would looks like
SELECT * FROM users ORDER BY created_at DESC LIMIT 1; But what happen behind the scene is
MariaDB [d1]> EXPLAIN SELECT * FROM users ORDER BY created_at DESC LIMIT 1; +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ | 1 | SIMPLE | users | ALL | NULL | NULL | NULL | NULL | 5 | Using filesort | +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ 1 row in set (0.00 sec) Definitely RDBMS is doing a full table scan. It will be blazingly fast with 5 rows of data but what about 500K rows?
Having "Using filesort" would lead to temporary table to be created in order to perform sorting and then limitation of the result set. When working with smaller result sets such temp. tables will be created in memory - which will be fast enough. Increasing numbers of rows in the table, ie. amount of data stored in the table, would lead to temp. tables to be created on disk - which is slow and resource consuming process. Also, such temporary objects have to be freed properly adding more time to overall execution time.
Now, given the fact we are aware of our database structure and we know how indices and auto_increment works we could make following assumptions:
All user IDs are generated automatically in (almost) sequential order All timestamps are generated automatically at same time as user ID Hence user with ID of 5 will be (or should be) created after user with ID of 4 Using different approach to fetch the most recently created user will give us
MariaDB [d1]> EXPLAIN SELECT * FROM users ORDER BY id DESC LIMIT 1; +------+-------------+-------+-------+---------------+---------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+-------+---------------+---------+---------+------+------+-------+ | 1 | SIMPLE | users | index | NULL | PRIMARY | 4 | NULL | 1 | | +------+-------------+-------+-------+---------------+---------+---------+------+------+-------+ 1 row in set (0.00 sec) But what if we create an index on created_at column to speed our first query, erm let see
MariaDB [d1]> ALTER TABLE users ADD INDEX created_at (created_at); Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [d1]> EXPLAIN SELECT * FROM users ORDER BY created_at DESC LIMIT 1; +------+-------------+-------+-------+---------------+------------+---------+------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+-------+---------------+------------+---------+------+------+-------+ | 1 | SIMPLE | users | index | NULL | created_at | 4 | NULL | 1 | | +------+-------------+-------+-------+---------------+------------+---------+------+------+-------+ 1 row in set (0.00 sec) It's the same result as using our primary key. So far so good one would say. If we end adding indices to all columns in our table then we will have index trees with the same size as underlying data which will render our indices unusable. Let see what we have when it comes to data storage
[mind@hive ~]# du -h /var/lib/mysql/d1/users.* 4.0K /var/lib/mysql/d1/users.frm 11M /var/lib/mysql/d1/users.ibd I am using innodb_file_per_table = 1 to optimise InnoDB storage but all in all - our table uses 11MB for storing our data (the actual size is less but that's not the point). What will be the size if we get rid of created_at index then?
MariaDB [d1]> ALTER TABLE users DROP INDEX created_at; Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 MariaDB [d1]> ALTER TABLE users ENGINE=InnoDB; Query OK, 0 rows affected (0.12 sec) Records: 0 Duplicates: 0 Warnings: 0 [mind@hive ~]# du -h /var/lib/mysql/d1/users.* 4.0K /var/lib/mysql/d1/users.frm 2.1M /var/lib/mysql/d1/users.ibd We could say the overhead of data storage was 550% having 10K rows in our table. Proving that adding indices with high cardinality is not a good idea storage- and performance-wise.
My previous examples where given to prove why date / date time / time related columns are broken by design. My current examples explains why using such columns to filter data are slower. Long story short - more data to seek in (ie. bigger storage) leads to more teach to do the search. Using DATETIME instead of TIMESTAMP is even worse because it uses 8 bytes (without fractional seconds) compared to 4 bytes.
Alas, when it comes to different environments figures will be very different. Doing tests on local (isolated) environment with handful of objects (databases, tables, rows in the tables, etc) is a way different that running same queries on heavy-loaded production servers using replication for example.
To give you a more natural example - let say we have our users table presented as a notebook and having each row written on it's own page. Which one will be fast:
Reading all pages to compare all created_at value, or Going to last page to read it's created_at value This applies on scenario with index on created_at column too because it is a secondary index.
 
Every bit of data sent by user should be seen as untrustworthy indeed. I couldn't agree more.
Disabling the UI is called Display Morphing, Representation Morphing pattern or more commonly known as in-place edit but yet could be best possible solution.
 
-Ursel

This would be true if you're querying datasets that contain a large amount of data that regularly increase. Without knowing anything about the size of the data, how often writes happen, and how the database is architected, saying there's a perf issue reading a value with a WHERE clause is completely over the top. Literally every CRUD app will use WHERE to filter things like getting a user ID, and they basically never run into issues with this until they hit very high scale. The app we're talking about here might only have 10 users and barely any data, so this type of query would be nanoseconds on a modern DB server. You don't even have to filter using WHERE on the date, you can grab the last value and do the comparison server-side.
OP hasn't been very clear about what they're trying to do, but if the aim is to have the data saved, the most important thing is to persist the data as soon as possible. A user can alter the app state in so many ways in a 5 min period, that can cause data to simply never be saved, or become corrupted.
If you're suggesting using setTimeout and waiting 5 mins before saving, that's likely going to lead to a lot of state bugs that are tricky to replicate. You can save to localStorage, but if the user closes their session, there is no action that runs in the background to ever save that data in the DB. Even if the user comes back, you'll have to run something on the client to check, and reading from localStorage, running that process etc, would be considerably slower than a single DB read, since localStorage isn't very well optimised. The chances of running into inconsistent state bugs and timing issues is practically guaranteed. This could also potentially be a security issue depending on what you're saving as LocalStorage can be modified on the client without any checks.
Again, we don't know much about what OP is actually trying to do as his question is vague. Hiding the content using LocalStorage for 5 mins would be fine just to "lock" content temporarily, but if saving is involved in some way, and the data needs to be accessed again later, I would personally write instantly and worry about perf later, if it even becomes an issue.

I think it depends on the subject.
Certainly if the client was asking for something unethical or in an illegal grey area that'd be a red flag and a sign to walk away.
Conversely if we're talking things like design or content presentation/structure then its your choice how to proceed. We all end up doing things the way the client wants sometimes, even though we recommend something different - in situations like this describe how your solution would work vs the clients solution and let them decide how to proceed - they are after all paying the bill.
Like @davep said, you don't have to add the site to your portfolio.

You basically need a platform that allows marketplace selling and payment distribution, neither Shopify or Squarespace offer that currently. The biggest question is how you're going to get both types of users required to make this work? This is the first step to work out, if you build something, there's no guarantee of getting even a single user without the right marketing strategy.
I would be looking to build a minimum viable product (https://www.productplan.com/glossary/minimum-viable-product/) to test your idea before committing too much. Speak to artists about selling their artwork through a simple store, with an agreed commission. This should give you an indication if you're heading in the right area, before having to invest in it heavily. The best way to validate your idea is through feedback as early as possible, you'll likely find things that need to be changed, or assumptions about your idea that didn't turn out to be correct and you'll be in a better position to adapt.

Make sure the version of Joi is the same as the one used in the tutorial.

Okay I missed that condition i.e. that a parent (as there can be many) must not have position static if it is to contain the absolute child element otherwise it uses the HTML element. An omission (W3Schools left this little caveat out too) to catch out the unsuspecting and throw them into absolute confusion.
I also made the error of not setting/uncommenting the absolute element position helper properties i.e. top, bottom, right, left, in my example. After reading your reply and using the helper properties it's now making sense.  
 

https://css-tricks.com/video-screencasts/110-quick-overview-of-css-position-values/

^ This might help.
It means it can go outside of the containing element to anywhere in the document. By default, if a position absolute element is not wrapped in something that's position relative, it will be relative to the document. In your example, your container doesn't have position relative on, so it's falling back to the document to provide a default position.
Here's an example that hopefully makes more sense - https://codepen.io/jackpallot/pen/bGBqZNq

You haven't provided a hostname. If you look at the HTTP examples on the Node site you'll spot the error.
https://nodejs.org/en/docs/guides/getting-started-guide
I probably wouldn't stick with using the HTTP module for too long. Something like https://expressjs.com gives you more out of the box with a nicer API.

You basically need a platform that allows marketplace selling and payment distribution, neither Shopify or Squarespace offer that currently. The biggest question is how you're going to get both types of users required to make this work? This is the first step to work out, if you build something, there's no guarantee of getting even a single user without the right marketing strategy.
I would be looking to build a minimum viable product (https://www.productplan.com/glossary/minimum-viable-product/) to test your idea before committing too much. Speak to artists about selling their artwork through a simple store, with an agreed commission. This should give you an indication if you're heading in the right area, before having to invest in it heavily. The best way to validate your idea is through feedback as early as possible, you'll likely find things that need to be changed, or assumptions about your idea that didn't turn out to be correct and you'll be in a better position to adapt.

If index.php has a normal HTML structure then I would add it there. If it's only PHP then I would be tempted to move that into a separate file and use index.php to serve your page. You can include the PHP file from within your index.php file like so:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Index</title> </head> <body> <?php include('template.php'); ?> <script> // JS code here </script> </body> </html>  

Ajax would be the best way to handle this.
Having said that, I have amended the plugin script you use for filtering to store and look for a default item https://codepen.io/jackpallot/pen/yLJwWKQ. You should be able to replace your current portfilter.js script with the one in my Codepen example. Also remember to add the classes and CSS to your list of items to match my Codepen demo (this prevents a flash of items before the script has fired).

I solved! It was a close div wrong position
This
</div> </div> <div class="hamburger-end">&#9776;</div> </div> </nav> </header> The close div must before hamburger
</div> </div> </div> <div class="hamburger-end">&#9776;</div> </nav> </header> I'm happy 😀

A WordPress plugin isn't a good thing to base your learning from. WordPress has terrible coding standards and doesn't use any modern aspect of PHP.
You need to decide whether you prefer frontend or backend development. I would avoid full stack development until you're competent in either of those areas. Learn the fundamentals of a language you want to learn, like JavaScript, and build something basic that builds on what you have learnt. As I mentioned previously, a todo list is good practice for using arrays, objects and functions, for example.
Don't waste your time going through other peoples projects and trying to learn from them. There's no guarantee those projects are written to a good standard and it's generally a poor way to try and learn to code. You won't know what half of it does, and playing around with code doesn't equal knowing exactly how it works.

I think the React course is one they update once or twice a year. The current version covers hooks and some of the newer API's.
If they want to learn some basics well, one of my favourite courses on there is the "JavaScript: From Fundamentals to Functional JS, v2" course. I learned a lot from the first version of the course years ago, so I'm sure the newer version is just as good. Bianca is easily one of the best teachers on there, along with Will Sentence, but his stuff covers more intermediate topics. It's part of the beginner learning path - https://frontendmasters.com/learn/beginner/

They produce a lot of courses each year now so not all of them get an update, unless they really need it. Even so, most are just fundamentals at beginner stage and don't really change from year to year.

You have two search elements called .js-search-trigger (an icon on desktop and an icon on mobile), document.querySelector only targets the first element. If you want to target multiple elements use document.querySelectorAll instead https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll.

You have two search elements called .js-search-trigger (an icon on desktop and an icon on mobile), document.querySelector only targets the first element. If you want to target multiple elements use document.querySelectorAll instead https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll.

You normally import any files from a subdirectory into your main Sass file and watch the main file, then any changes in your other files will automatically cause the main file to update.
https://sass-lang.com/documentation/at-rules/use
Since you have installed Sass globally you can change into whichever directory your main file is served from before running the Sass command.
cd programming/sass/scss sass main.scss --watch More on using CD and LS here - http://linuxcommand.org/lc3_lts0020.php
Just a quick note on your directory naming too, I would stick to either a sass or scss directory but not both, since they essentially are the same thing.

Just to be aware, your stylesheet will never cache if you add a timestamp like that and it's beneficial for performance to fetch from the cache instead of having to make a new request. What you probably want is for the file to be updated based on the modified date.
https://www.php.net/manual/en/function.filemtime.php

It's not CF7, the CSS just needs to be amended and the cols should be ignored.
.wpcf7-form-control-wrap { display: block; }  

It should do, you're wrapping the form elements in a span which needs to be display block if you want it to work like that.

What you're building sounds similar to https://pcpartpicker.com. They have a really extensive database of products and compatibility. You would honestly be better off scraping the data off a site like that, or another similar site and using it instead of keeping your own data up to date.
I don't think I'd use WordPress for something like this. You don't really need any of the features it ships with to be able to do product comparisons. The most important thing here is the data set, I'd say it architecturally this should look more like.
Scraper (runs daily or hourly) -> add to DB -> JSON API that talks to the DB - frontend to display the data.

You haven't set any display property, so the browser will default to using display: inline; which ignores any width and height you have set. Add display: block to the input, textarea and labels and this should work as expected.