PHP and mysql -- well, MariaDb pretending to be mySQL -- is a fine and dandy choice for the task.
But I'd question the 'need' for JavaScript client-side since it should be written to work without scripting FIRST... and when it comes time to enhance the already working page with scripting, the last thing I'd do is add the train wreck laundry list of how not to use JavaScript that is jQuery.
Doesn't sound like all that monumental a task so long as you organize properly from the beginning. The list you presented makes a lot of sense so that's a starting point. On these types of projects I like to layout and create the database tables first so I know what data I'm manipulating, that way I have some idea what I'm going to be outputting when it comes time for the application of semantic markup -- since again content should dictate markup, content + markup + device capabilities should dictate layout.
Same goes for your queries -- database structure + user action should dictate the queries and processing.
It's often surprising how much of this industry approaches that from the other end. Letting some artist spank it on the screen in photoshop then insisting the front-end be based on some picture that doesn't even match the data or task. Trying to build queries and processing before the data structures are even established. etc, etc.
Work out what data needs to be tracked, organize it so it makes sense. Figure out all the user-actions you need, organize them in the order they are needed for usage and testing. Write that out as a list, follow the list top to bottom, done.