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/
Added email verification after user registration. After a user registered, an email is sent to the email used to sign up. The mail contains a verification link which is required to complete the registration process.
This feature can be turned off in the Admin Panel under: Admin>Config by changing the setting "Register_auth" from "verified" to "auth".
Read more about this on the Blog here: https://blog.littlelink-custom.com/optional-email-verification/
Added new Custom Website button which visually looks similar to the previously added Website button with an except of the icon of the new button being the favicon of the chose link. The text on the button is set with the button title, just like the Custom button.
The favicon request is performed via the Google API. The icon displays correctly in most cases, with some exceptions. I might add a function later on that displays a generic icon if no icon was found.
Made link title (previously required) optional when adding personal LittleLink links on the User/Admin Panel.
If the 'Title' field is left empty, the button name is now used instead of rejecting the addition.
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
LittleLink Custom now includes an open and free to use SMTP server. Mails from this service may only be used for password recovery and registration purposes involving users personal LittleLink Custom or LittleLink Admin pages.
Users of this service must abide by our Terms and Conditions found at https://llc-mail.tru.io/.
Motivations for this are explained on my blog post about this topic, which you can read here: https://blog.littlelink-custom.com/littlelink-custom-mail-server/
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.
Julian Prieber
Julian Prieber
Julian Prieber
dependabot[bot]