User's profile names are now used as the title and heading for their LittleLink pages. Previously the '@name' was used for this, so for example the page name x.com/@admin is now not tied to the @admin part anymore, so a space could be used in the name for example.
See an example of this here: https://i.imgur.com/iBS8Hsm.png
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.
Added share button that is displayed on user's personal pages that if clicked either copies the profile URL or opens a share dialog window depending on the browser and operating system.
Read the blog post about this topic here: https://blog.littlelink-custom.com/share-button
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.
Fixed bug where if a user was edited on the Admin Panel under 'Admin>Users> Edit User' changes would not apply without every value being changed.
This bug originates from LittleLink Admin (the fork of which this fork is based on).
One part of this issue was that most fields were required to fill in. If only one would be left, empty, none would apply. The problem was if this requirement was removed, the password would always overwrite the current password, even when left empty.
This meant you could only edit users if you knew their password, otherwise their passwords would be changed, probably preventing that user from login in ever again.
After some experimenting, I implemented the easiest fix I could come up with. A simple if-else statement that checks if the password field is empty and if so only saves the other parameters without touching the password. If the password is changed, the changes will be applied normally.
Also fixed the profile image size for the default placeholder image.
Added PHPinfo section to the config editor to display information about the current state of PHP.
This new section can be found on the Admin Panel under 'Admin>Config>PHP Info'.
For this, a new route and section in the admin controller have been added. The page is loaded as phpinfo.blade.php with the route .../panel/phpinfo if the user is authenticated as an admin.
I added the usual dark mode detection to the page, with an extra section that changes the background color according to the preferred theme setting. The page itself can be downloaded and saved as an HTML, for this JavaScript is used.
The homepage can now be changed to a user's profile page with the option "HOME_URL" in the config (found on the Admin Panel under Admin>Config).
This commit is a bit janky, I wanted to change the homepage with a setting saved in the database, but I couldn't finish this in time, so this has to do for now.
An if statement in the web routes PHP checks if the new setting is present in the config and changes the homepage to the listed LittleLink Custom name. If the homage is changed, the page previously set as the homepage where users can register and or login can now be found at .../home.
Added visual HTML editor for editing HTML on the footer and home pages. This editor is based on the open source CKEditor a Smart Visual Text Editor for HTML coded in JavaScript.
Read the Blog post about this topic for more info about this feature here: https://blog.littlelink-custom.com/visual-html-editor/
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.
Fixed bug where users littlelink pages (domain.com/@username) would display a 404 error. This was caused due to the .env config file not containing an App URL. This issue could be solved by simply adding a URL to the config, this is now not necessary anymore, making the setup process easier and less confusing.
I changed every instance of "{{ config('app.url') }}" to "{{ url(' ') }}". This effectively automatically uses the correct URL for LittleLink links, even if LittleLink Custom is set up in a subdirectory.
In my testing, I couldn't find any problems this might have caused, so this appears to do the job just as well as setting the URL in the config. If I find any issues with this, I will revert this change.
This displays an update notice if a new version of LittleLink Custom has been released.
This one is definitely a messy one. Everything I added is commented, but I'm going to try explaining it here one more time.
General outcome:
• This feature checks the local version against the newest version stored on a separate server.
Error prevention:
• I used 'file_get_contents' to get the version number from a JSON file. If 'file_get_contents' cant find the file, PHP will throw an Error Exception.
• To prevent this, I put the update section in an if-statement that only applies if the following conditions are met.
Check if files exist:
• To test whether the file on the server exists (remember, if the server can't be reached, you will get an Error Exception) I used a function that checks if the URL to the file on the server successfully returns a '200 OK' response (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200).
• If this condition is met, it sets the variable '$ServerExists' to true, if not to false.
• Now, the previous mentioned if-statement simply checks if the local file exists and the '$ServerExists' variable equals 'true' to proceed.
Get version number:
• If all previous conditions are met, two variables get defined via 'file_get_contents' '$Vgit' and '$Vlocal'.
• Both the file on the server and the local file simply contain the version number.
• The variable '$Vgit' is the newest version number retrieved from the server.
• The variable '$Vlocal' is the local version number.
Display update notice:
• To finally display the version number (added with HTML) one last check via an if-statement is performed. This simply checks if the current user is an admin AND if the version retrieved from the server is higher than the local one.
• If both conditions are met, the notice is displayed.
In addition, I should mention that I put the existing 'Watch Page' link as well as the update notice in a div with the class 'row' to display both links next to another instead of them being stacked.
Added 'fadein' class to avatar image, littlelink_name and littlelink_description text. This class adds the fade-in animation from 'animate.css' found in /littlelink/css/.
This fixed the issue of dark mode not displaying on the register, login, forgot password and a few other pages.
This one took me a while to fix, and I still don't really know what is going on here.
The aforementioned pages already implemented a dark mode, but it didn't seem to work for me. After some testing, I discovered that the dark mode preset doesn't load on chromium based browsers.
I have absolutely no idea why that is, if someone could help me with this that would be amazing. I might make an issue out of this later on.
As I still wanted to fix this, I finally achieved my goal by doing the caveman approach:
I first added the usual dark mode detection. The same used on the home and little link pages (see previous commits if you're interested).
Then I wrote and if statement that loads the newly added app-dark.css (see previous commit) that changes text and background color on the pages in question, if the browser type is chromium and dark mode is selected in the browser settings.
"@if(strpos($_SERVER['HTTP_USER_AGENT'], 'Chrome' !== false) and $color_scheme == 'dark')"
This doesn't look optimal, and I would rather just have the same dark mode as on Firefox, but this is the best I can currently do with my available time.
Julian Prieber
Julian Prieber
