Redesign/add templates

[TamaroWalter]

This is the first of many PR that redesigns this plugins. It starts with simple corrections and adds templates.

[dlmsr]

I am rebasing this on some previous changes from me which I did not push. So expect history-rewrites for this branch. I am, at the same time, looking at your commits, @TamaroWalter, and making some adjustments.

[dlmsr]

The change remove deprecated utf8 function is a step in the right direction and we should keep it for this PR. In the long-run we should try to address #14.

[dlmsr]

add template for first overview is not quite the desired behaviour:

[dlmsr]

Just one quick question, @TamaroWalter:

fix SQL concatenation does not fix any bugs, does it? This is simply a reformatting of the SQL string building, right?

[TamaroWalter]

Just one quick question, @TamaroWalter:

fix SQL concatenation does not fix any bugs, does it? This is simply a reformatting of the SQL string building, right?

When accessing the request.php i always got an exception throw in the sql query due to a false format. Because of that I added the cast to int values.

[dlmsr]

I see. I reverted the commit locally and do not get any failures. Do you remember the error message? As far as I can see veranstids is an array of strings which do indeed represent integers. However, the cast to type integer should not really have any effect as its later concatenated with the . operator which implicitely casts back to strings anyways. While we're on it, I am still fond of reformatting the SQL string to be more readable but I would drop the explicit casts to integers when there are not any errors. I will force-push my changes and maybe you can have a look and test them in your local setup to make sure you wouldn't get the error message from before (or any error message 😆).

[dlmsr]

@TamaroWalter, the pull request is ready for merge IMO. The error messages from the PHP CodeSniffer need to be addressed in another PR. Could you please test the changes with your local setup to make sure no new errors were introduced? I would want to merge this soon when you approve it.

[TamaroWalter]

Alright, I will check this

[TamaroWalter]

I see. I reverted the commit locally and do not get any failures. Do you remember the error message? As far as I can see veranstids is an array of strings which do indeed represent integers. However, the cast to type integer should not really have any effect as its later concatenated with the . operator which implicitely casts back to strings anyways. While we're on it, I am still fond of reformatting the SQL string to be more readable but I would drop the explicit casts to integers when there are not any errors. I will force-push my changes and maybe you can have a look and test them in your local setup to make sure you wouldn't get the error message from before (or any error message :D).

This was the error message i get when i click on the second option (The course exists and i am authorized to create it):

Exception - pg_fetch_object(): Argument #1 ($result) must be of type PgSql\Result, false given

[More information about this error](https://docs.moodle.org/501/en/error/moodle/generalexceptionmessage)

Debug info:
Error code: generalexceptionmessageDismiss this notification

Stack trace:
line 128 of /public/local/lsf_unification/lib_his.php: TypeError thrown
line 128 of /public/local/lsf_unification/lib_his.php: call to pg_fetch_object()
line 181 of /public/local/lsf_unification/lib_his.php: call to get_courses_by_veranstids()
line 93 of /public/local/lsf_unification/request.php: call to get_teachers_course_list()
line 180 of /public/local/lsf_unification/request.php: call to print_coursetable()
line 291 of /public/local/lsf_unification/request.php: call to print_remote_creation()

I have the tables from the beispieltabellen.sql that are linked in the documentation

[dlmsr]

Ok, thanks. Unfortunately, I cannot reproduce this one. Also, looking at the backtrace it seems to me that the error is unrelated to the modified query.

[TamaroWalter]

Ok, thanks. Unfortunately, I cannot reproduce this one. Also, looking at the backtrace it seems to me that the error is unrelated to the modified query.

Maybe it's an error in the data...