The admin link will automatically show when viewing a page within the admin links. Mainly whenever the url has /panel/ as the first directory after the domain.
We can also remove the config option for this now too but I didn't see where to find it at yet.
The force HTTPS option in the config now turns any link into HTTPS. This also works on reverse proxy setups.
The previous option in the config is now being replaced with the new option FORCE_ROUTE_HTTPS which redirects all routes and pages to HTTPS. This option should never be used behind a reverse proxy.
See issue: https://github.com/JulianPrieber/littlelink-custom/issues/216
Added support for custom meta tags via a new config file.
Custom meta tags will only be active if "CUSTOM_META_TAGS" is set to "true" in the config.
Replaced "<html lang="en">" with "@include('layouts.lang')" meaning HTML lang can be changed in the new config, defaults to en if not active or not defined.
Switched to dark mode detection via CSS instead of JavaScript on users LittleLink pages and the home page.
I decided to use this approach instead of the previous JavaScript version. This means that a manual switch to change between light and dark mode by user won't be added.
Adds the ability to insert code snippets into the head and body element laid out by the sidebar with blade by including:
@push('stylesheets')
<!-- your code -->
@endpush
@push('scripts')
<!-- your code -->
@endpush
Added a security check on the sidebar.blade.php that tests if critical config components are accessible externally by anyone.
This is a fairly crude method and not at all optimized. I might change this in future revisions. At least this feature is disabled for normal users, so it won't affect load for non admins. This is the same code from the new diagnostic tool added in the previous commit. I had to change the names of each variable, otherwise the diagnostic tool could not use the same variables. The smart thing to do here would probably be to simply use the variables only in the sidebar, since they are loaded anyway since the sidebar layout is included on the diagnostic tool, effectively loading the variables twice. I might change this later, but for now I will leave it as.
Read more about the diagnostic tool on the blog here: https://blog.littlelink-custom.com/new-security-check-tool/
Added option to only notify about major updates. This setting is now the default and can be changed in the config by changing the setting "NOTIFY_UPDATES" from "major" to "all".
This setting was achieves by turning the previous if statement into an if-else statement with the new option. For this, I utilized a function that gets the latest tag from the GitHub repository.
I wasn't able to implement the 'if URL exists' check, the URL would just not return an error negating the function. I will probably fix this in the future, but as it is now, if the GitHub API server can't be reached this might trow an error.
The major release is still the previous update version retreated from the GitHub repository. This means I will only update that version for major or otherwise important updates.
I implemented this feature because I didn't want to spam new users with a new update notification every other day.
Fixed word spacing bug in texts added by the new page editor. This bug caused inserted links to have extended spacing between words.
This 'bug' was a previous feature added to display links further apart for easier readability. The feature didn't scale well with the newly added page editor which allowed users to add their own links to edited texts, causing the bug.
The extended spacing was achieved with the 'padding' CSS tag. I simply removed the tag from all an HTML tags and made it into its own class, 'spacing'. I added the class to every element on the site that previously depended on this tag.
Added option to hide Events. Next to all event notifications, an "X" will now be displays, which hides the notification if clicked until a new event notification is shown. This works by setting a cookie with the ID of the event notification. Learn more about this on the Blog post here: https://blog.littlelink-custom.com/hide-event-option/
I re-enabled the footer disabled by Latuminggi's LittleLink Admin fork. This footer adds a Home button which brings you to the landing page, in addition to Terms, Privacy and Contact buttons.
I also edited the policy pages for the buttons named above to include the new logo as well as the dark mode detection.
LittleLink Custom now includes an .env config editor. This editor can be accessed via the Admin Panel under Admin>Config.
This editor allows admins to edit, backup, download and upload the .env configuration file. All in all, the new feature, allows users to more easily edit the configuration file, contributing to my goal of making LittleLink Custom easier to use.
Read more about this topic on the Blog https://blog.littlelink-custom.com/built-in-config-editor
This 'bug' was caused due to the way the dark mode was applied. The dark mode detection detects the preferred theme style from the client and then saves the preferred type with a cookie, all with JavaScript. Then a simple PHP if-else statement loads either the dark or light mode CSS theme, depending on the cookie.
The problem here was that the cookie would only be detected if the page was refreshed, so once the cookie was set, the dark mode was applied every time without a problem. But the first time a user visited the site and the preferred theme was set to dark mode, the page would still display the white version until the page was refreshed.
Now, I could have changed how the page applies the dark mode, however I decided against that and went with this commit instead.
Now I'm not really experienced with JavaScript at all, so this definitely could have been solved in a more elegant way, but this is what I did:
I added a bit to the JavaScript that sets and reads the cookie. When the page finished loading, a simple if statement is run that requires the following conditions:
The URL contains a '#' and the color scheme equals 'dark' and the cookie isn't set yet.
After these conditions are met, '#dark' is added to the URL and the page will be refreshed.
This refresh is only performed without the cookie, thus only refreshing the page on the first visit if the dark mode would be applied.
The '#dark' is only added to the URL to fail the first requirement of the if statement, preventing the page from being reloaded in an infinite loop. Otherwise, the '#dark' part of the URL fulfills no purpose and only the '#' part is required, so it doesn't even matter what comes after the hash. I just chose this for clarification.
If the dark mode cookie is blocked by the user, the page will be set to light mode and refreshed every time they visit but the '#dark' will still be added to the URL, preventing the infinite refresh-loop.