Code Consolidation for API preparations & hard coded path replacements

[jaredb7]

Review required!!
This is my attempt at consolidating code and functionality into a common file to later be also used by a API.

No functionality has changed, just the code has moved and a bunch of helper functions written to make life easier (saveSettings(), getDirectory() and getFilePath() are some of them)
Everywhere some functionality existed that was moved into a function in common.php I've tested those pages and any actions (like protecting recordings) etc.

• All SQL Queries were moved into their respective functions and parameterised, there were some slight logic changes in the front end pages to accommodate data being returned differently but actual data returned and functionality is maintained

• A common function is used to execute all queries and looks after binding any parameterised values that have been supplied. We're already using prepared statement so updated all queries that would accept input from the user with place-holders which are later bound into the statement.

• The Config and Advanced setting pages received changes to use the new setSetting() function which looks after creating or updating the setting in the required config files. It also refreshed the global $config variable by re-reading the config files after saving. Optionally it also specification of a command to run after saving the settings.

• Service Controls page received changes with the replacement of the actual command to execute with a sort of shorthand human friendly versions e.g. service <service_name> -- service restart livestream.service.
  These commands map to the original commands in serviceMaintenance() so this could be called through the API without needing the full-blown commend.
  views.php was updated to accommodate this also

• System Controls page received a small change to make the process checking for new git updates or getting the last commit hash a single function call

• Two new functions getDirectory() and getFilePath() were introduced in aims and make it easier to relocate files in the future. This has been worked into all existing php files to replace all hard coded paths.
  Currently the home directory is still fixed to that of user id 1000 (normally pi) but can be changed once we get around to needed that.

• Other misc code for deleting / protecting detection's, frequency shift, Flickr API call etc have also been moved into common.php to be used later by the API as well

• Excuse the misleading branch name 😄

[Svardsten53]

I have some questions about this. As I mentioned earlier, I have made some modifications to the program for myself and other users in Sweden. In index.php the title has been changed and current weather info has been added below it. In views.php I have made a Swedish translation and modification of the menu. In other pages, English has been translated into Swedish. Everything is modified after each update by running some scripts and it works very well.

I have tried to understand the new structure, but do not know PHP very well. I would like to be able to prepare a bit so that it will also work in the future.

Is common.php a page that other pages that exist today only will call as a general resource?

Will index.php, views.php and all other files that build the appearance of the program remain with the same content in the future?

[jaredb7]

Hi @Svardsten53 , I did see your modified version, I like the weather at in the title :), are you using a different font too?

Correct all existing pages will call common.php to execute code that was in that file but now moved into common.

The layout/html code out from index.php, views.php etc to build the appearance we see today won't change or be replaced. So your script used to do the translations will continue to work after any tweaks if necessary, the code replacing the title with weather should also be ok too, depending on how you're doing it, the page links and bird stats chart might review.

The idea was we keep the current look and feel and output untouched, moved any code that can be reused to common.php, build a API that reuses that same code, then a new web interface can build off the data from the API.

[Svardsten53]

Thanks for a detailed answer. I found the program when it was only a few weeks old, wanted to adapt it somewhat to Swedish conditions and had a lot of contact with Patrick during that time. I haven't changed the font, but probably using what was first there, it may have been changed later in the original version.

The weather data is downloaded via an API from the nearest local official weather station and unfortunately the solution cannot be used in other countries.

It sounds hopeful that the files that control the appearance won't change too much. Then it should be enough for me to make some small changes in the four or five files I modified, the rest are just translations.

[ehpersonal38]

Thank you for the contribution. This is an absolute monolith of code, I'm honestly shocked and a bit scared 😄.

Anyways, there's a fatal error showing on my system when I tested this PR out -

[jaredb7]

It is quite a large change lol, hopefully the PHP comments made it a little less freighting haha 😅

Whoops and apologies, I'll investigate the error, I think it may be because it can't find the new config directory with the new json file which I've probably linked onto /homepage on my install but haven't added it into update_snippets

[jaredb7]

It was the missing symlink :(

[ -L ~/BirdSongs/Extracted/config ] || ln -sf ~/BirdNET-Pi/config ~/BirdSongs/Extracted

I committed the change to the same branch and opened a new PR, I'm sure there some magic you're able to do to revert the revert & pull in the fix :)

Let me know if something different has to be done.

[ehpersonal38]

Are you able to re-open this PR by chance?

[jaredb7]

Hmm, I don't seem to have the option anywhere, I do have a option to create a new PR from the revert but that doesn't work since the branch was deleted and probably not a good idea nyway

Would it be beneficial in creating a new PR, with the fix from #919 and resolve any conflicts then submit it against PR-Development and see how that looks?

[ehpersonal38]

Would it be beneficial in creating a new PR, with the fix from #919 and resolve any conflicts then submit it against PR-Development and see how that looks?

Yep, let's try that!

[jaredb7]

New PR #925 submitted against the PR Dev branch, I pulled in the latest commits to the main branch, made adjustments and resolved the conflicts that were occurring.
This also has #919 in it some small changes

Then I compared the files again what I have been running for the past few weeks just to see what I may have to re-test and there were no odd changes after resolving things.

I tested the new frequency shift option on the spectrogram page and also the 30Day graphs fix and fixed the issue my code created (wasn't supplying valid data)

Let me know if there are any issues :)