AdminLTE 3.0 Plans

Created on 27 Sep 2015  ·  133Comments  ·  Source: ColorlibHQ/AdminLTE

Hello everyone,

As you may already know, Bootstrap v4 is coming soon. Thus, a major update for AdminLTE is due with the release of BS4. For the time being, we will only take suggestions for AdminLTE 3. In other words, v2 will get bug fixes and patches but won't get new features.

Quick glance at our plans for AdminLTE 3:

  • Full utilization of Bower for package management
  • SASS instead of LESS
  • Customized Bootstrap via variables to significantly decrease the number of (override) lines of code in AdminLTE.css
  • Front-end template using the easily customizable color-scheme of AdminLTE to create a sense of consistency and broaden AdminLTE's domain
  • Color variables of AdminLTE will be removed and Bootstrap 4 color vars will replace them

    • That is to say, instead of @light-blue for example, we will use $brand-primary

  • The box component will be replaced with the new BS4 cards
  • The main header will use a custom navbar to avoid current issues with responsiveness
  • The treeview in the sidebar will be rewritten to provide advanced features and options such as treeview search and expand only when a specific element gets clicked.
  • App.js will be removed and ECMA6 will be used for each plugin to produce AdminLTE.js

    • Treeview.js for example will be its own plugin and app.js will only supply a demo use case

    • This gives developers the ability to create their own custom app.js and use only the relevant plugins

  • I still prefer Grunt over Gulp so I will keep using it (this is debatable)
  • The layout may make use of the new flexbox functionality that BS4 provides. Thus, reducing the number of calls to $(window).resize(...)

The product of these changes should make AdminLTE highly customizable and convert it into a framework level tool rather than just a template. Suggestions and contributions are highly recommended as always. If you know of new plugins, tools or ideas, please feel free to post them here.

news

Most helpful comment

Thank you all for your interest in AdminLTE 3. I understand that it has been a long time since any progress was made towards upgrading the template. The good news is that with BS4 finally out, I’ve been working on a new plan for AdminLTE and trying out the new BS4 framework. Soon, I will post a full update on the progress and hopefully have the ground work laid out for the next big release :D
I am really excited about resuming the work and coming up with new ideas and tools to make AdminLTE better for all of us.
Thank you for your patience and enthusiasm.

All 133 comments

"This gives developers the ability to create their own custom app.js and use only the relevant plugins" - perfect

"That is to say, instead of @light-blue for example, we will use $brand-primary" - but it would be nice if you could provide some precompiled .css files with old colors. You would save a lot of time for users who dont have experience with SASS.

@jlamer I prefer to completely break free and move forward with Bootstrap 4 and AdminLTE 3 and leave behind the old versions of both. Better not to drag anything from the old versions as that will become a liability to support and encourage some developers to stay with the past notions. It's normal to break backwards compatibility with major version updates. Moving to AdminLTE 3 is not mandatory and who needs to use the old model can choose to stay with v2.x.

I completely agree, but I dont think precompiling few css files with old colors would be problem. I think we could overcome a lot of questions about how SASS works.

It will start by the compiled CSS files, then requests will follow to provide their LESS sources to make modifications easy, then issues will rise concerning problems with certain CSS classes in this or that browser/version/device that need solving and support in the LESS files. And probably some developers who are comfortable with LESS will start copying classes from SASS to it increasing the need to support LESS. And before you know it, you'll find LESS sneaking in besides SASS and calling for attention and support. Why open the door at the first place?

I think you misunderstood me. What I was trying to say was that it would be nice if in dist there were also css files compiled with all color variables like $brand-primary etc. from version 2.

AdminLTE 3 will have its own colors. It would be more likely to use a new color scheme but it may reserve the old one in case we find it better.

Thanks!

@jlamer this way I think we are referring to different sides of the same thing and there's no conflict.

@almasaeed2010 my understanding is that you will not carry the old CSS classes over to v3 but instead use those of Bootstrap 4 even if you decide to revert to the old, still you'll apply them using Bootstrap 4's approach, right?

That is correct.

In my opinion that would be a good approach to to it.

Try to use NiceScroll Plugin.

It's worth considering suggestions in #539.

If you may consider adding RTL native support, currently I support RTL over AdminLTE by reference bootstrap.rtl and by swapping pull-right/pull-left.

Appreciated your awesome efforts.

https://github.com/nakupanda/bootstrap3-dialog
Edit: The author cares about this project, I am sure that a Bootstrap 4 compatible version will be released.

I like the new framework idea of AdminLTE. Do you plan on dropping the jQuery dependency in a basic version of AdminLTE? By basic I mean a simple good looking template without 3rd party plugins (so BS4 with AdminLTE layout/design). Sure, if a 3rd party plugin depends on jQuery then the user will need to add jQuery.

JQuery is a must as Bootstrap 4 depends on it to work.

@lesichkovm not for all features..

@JeroenNoten @lesichkovm exactly ... AFAIK only javascript plugins need jQuery - see http://getbootstrap.com/javascript/ ... layout stuff can be nowadays accomplished without JS with CSS3

More background for my "no jQuery dependency" idea: If you use AdminLTE (or Bootstrap) with AngularJS, you don't need (or want :)) the jQuery versions of the plugins, since you are either write a plugin yourself using AngularJS or you adapt the jQuery-versions (by wrapping them into a AngularJS directive, but then I would add jQuery to the project).

Most of the time I just need the template without any functions from the JS plugins (neither from Bootstrap nor from AdminLTE). That's why I asked, if something like "removing jQuery" is in the backlog. :)

No external dependency on JavaScript at all is a great idea, if it can be accomplished, of course.

Enhancement: Add sidebars status cookies (without persistence)

Many developers addressed sidebar persistence, obviously it's a common need. While it should be handled on the server and will be implemented differently according to the language/framework used, still the first step is executed on the client by setting a cookie upon sidebar status change. That cookie will be used later on the server script (if found) to display the sidebar correctly.

I suggest to make setting the sidebars status cookies (both left and right) a part of the template core features with a standard cookie names, preferably configurable with a default values. The developers will then need to handle the server-side part of it using their chosen technology. That way we address a common need and avoid making each developer repeat the same step by adding it once to the core functionality.

Agree with @YasserHassan .

Maybe within the browser storage instead of cookies?

Highly agree with @ivantcholakov. For me it sounds like an access to the local storage to read/write the sidebar status. That can be done within a few lines of code. And for me it does not seem like a core functionality, since it can be added easily.

@ivantcholakov it's another way. We need to evaluate both. Maybe implement both with on/off switches and leave it to the developer to decide which to use. I'm sure a lot of developer are ready to contribute to it including myself.

@ManuelRauber the ease of adding a feature is not the measure of a core function but rather how common it is and whether it's client-side. Any developer who chooses to use the collapsible sidebars would expect their status to persist over page loads. By taking a part of the implementation and making it ready out of the box in a well-implemented, tested, and documented way with server-side samples, we could save some frustration. Notice that it might be easy for you but not for everyone such as those who ask about it every now and then.

I'm curious why the author does not release v3-alpha branch allows you developers to submit their desired function or component ... waiting for the official version BS4 procedures, functions, and merge the various submissions fixes some issues functionality.; this is not better ... if BS4 and other official version came out before you start alpha version, from v3-alpha to the official version, is estimated to be a long time .... I feel like this is not very good

@crperlin I prefer to settle on the main direction and conceptual points and giving them enough thought first before making the code available. Otherwise, the community would start pulling the project in different directions on a technical level via code contributions without a clear direction.

@YasserHassan Use Xmind to write programs using the process structure, determine the direction ??? such as this ??
image

@crperlin I'm not sure I've got your point. However my idea is to let the concept mature first before making the code available. I prefer discussions that reach conclusions that are then complied to a set of points.

@YasserHassan yes , But the lines are not frequent author, not engage in online discussions

@YasserHassan I see your point with having the persistence implemented in the core functionality. But I still don't see this as a server-side implementation, since the sidebar "shown/hidden" is a client state. What do you think about implementing this with client-side localstorage and providing a plugin with server-side persistence, rusing simple RESTful urls, leaving it to the developer implementing the server-side. Some samples could show how to implement the server using _insert favorite language here_.

Thanks for the suggestions guys! I will consider all of them when development of v3.0 starts.

Keep it up :+1:

@ManuelRauber the sidebar state server-side part is required for the initial page load. For example, if you collapse the sidebar after page load, it will show expanded first then animate to collapse with every page load. You need to set the state (class) to the correct status before sending the page to the server to show right initially. The client-side function should be capturing user's expand/collapse action and setting cookie only. Refer to #315 for this.

Considering the above, in my opinion, local storage is not the right way to do it unless you need to do extra work to sent its value with each request to the server (in turn could be stored in a session), something a cookie would do directly and implicitly.

@almasaeed2010 thank you for your effort. I suggest having a special label for V3 issues to take each V3 idea to its own thread while differentiating them from V2 to avoid mixing them all in this issue.

@ManuelRauber @YasserHassan I dont see reason why I should store sidebar state on my server. Imagine someone is using 3 devices: smartphone, tablet and desktop. So he opens site first time on desktop and he has a plenty of space so he keeps sidebar open. Now, if he decided to open it in tablet or smartphone, he would have sidebar opened so he has to close it and on dekstop open it again. I dont think thats very good UX. Yes, you could store something like HTTP_USER_AGENT but it can change very often when new versions are installed and why all that extra work? Cookies are not an ideal option - they can be deleted by some cleaning/security/whatever software and you cant set them to "forever". I am sure localStorage is the way to go.

@jlamer you don't store sidebar state on the server, you only process it there. I'm also for storing the state on the client, the multiple clients point you mentioned is another reason. There are pros and cons to both cookies and local storage so implementation depends on each situation and the developer's best judgement.

@almasaeed2010 I recommend "PJAX = pushState+Ajax" to achieve click the sidebar on the right page load effect;. And to avoid the whole station to achieve partial refresh refresh

PJAX project : https://github.com/defunkt/jquery-pjax;

I hope thie feture can add V3

First I use quite this thema think very good, I want to help in version 3. besides the setting bower we give the option to use cdnjs desvolvedor ? to perform the grunt

Is their any plan to add RTL in admin LTE 3.0?

Is there any plan on including the material design styles as an option

Sticky Footer - Non JavaScript Implementation

I would like the current sticky footer to be replaced with a non-javascript implementation. Pure CSS might do the job better, removing page blinking. Also, the pure CSS solution should avoid flexbox, in order to work on more devices and browsers.

Why avoid flexbox? http://caniuse.com/#feat=flexbox

Sticky-Footer with flexbox is really super easy to do. :)

@ManuelRauber
We are trying to support all major browsers including IE9-10 which don't support flexbox.

In 2014 I did a sticky footer with flexbox and I was reported that it failed on IE10 and on a relatively new Samsung mobile device. I don't know how the situation with flexbox is now, I just don't want to take chances.

Edit: I know, with flexbox is super-easy, but I think it is early for that.

I suggest evaluating the support of IE9 and 10, even 11. Microsoft is quietly replacing IE by its new Edge browser which is the default browser of the new Windows 10. One of the major reasons for supporting older IE versions was the wide use of Windows XP and that reason is no longer valid that XP has reached its end of life.

Some companies decided to fully drop IE support in favor of investing the time wasted in getting the projects to work right on it in favor of implementing new features and taking advantages of the new technologies.

It's hard to imagine deciding the future of a new project while dragging the weight of old problematic technologies that their own owner is trying to get rid of quietly.

I am not saying to fully drop the support of IE as that will not be realistic before a couple of years but to adopt a standards-compliant, modern-browser-first approach to implementation with partial support for IE. This would mean that some features will be partially or fully unavailable on older IE versions in favor of benefiting from all the new technologies and breaking the project free of dead weights so it can proceed faster.

@YasserHassan Microsoft announced 10 months after no longer provide support for legacy strong push IE11 IE browser , xp user has very few times .. We should instead accompany a small number of users in the end Sike

@crperlin if I understand you correctly, Microsoft itself will not support IE 9 and 10 in the near future, correct?

What I see is that their goal is to kill the whole IE line and replace it by Microsoft Edge which is a completely new browser. It has already started on both PC and mobile with Windows 10.

A sticky footer example without flexbox: http://codepen.io/jamiemlaw/pen/Bnscp

I just came across some disucussion about Bower development slowing down and thought I'd share it here. Here's another interesting comment.

Personally I've never had a reason to use Bower over NPM, but it's nice to have options and I hope Bower teams gets their stuff sorted out. I just thought I'd at least bring up a discussion whether a dependency to Bower is absolutely neccessary for this project especially for a new major release.

I strongly recommend moving the search input form the left sidebar to the top bar with consideration to small screen size on mobiles. On small screens, a good approach is showing an magnifying glass icon that exposes the search functionality when clicked. Google Play Store mobile app is a good example.

I'm recommending the top search because it would provide a better user experience on small screens when the left sidebar is collapsed besides it's more common. However, if the left sidebar search is in high demand, we can have both to use from according to the project.

There is something that I am not quite sure about. Would it be good using Jekyll for generation demo pages and documentation? The static HTML pages require lots of copy/paste.

Suggestion: iCheck plugin replacing
radio and checkbox styling with pure CSS: https://github.com/flatlogic/awesome-bootstrap-checkbox

@racztiborzoltan :+1:

@racztiborzoltan +1

Suggestion:
Using more CDN service links (JavaScript plugins, CSS plugins, fonts), instead "plugins" files, without bower.

  • smaller AdminLTE package size
  • smaller size of plugins directory. Less not used garbage, for example, if the frontend developer would like to use newer plugin. (example: DataTables v1.10.7 --> v1.10.10)
  • Freer hand to the frontend developer! Assets management? Which programming language? Which library? Bower or Npm or Composer or ...? Minification? Caching? etc... I hope that was understandable.

Some examples:

_"plugins/bootstrap-slider"_: https://cdnjs.com/libraries/bootstrap-slider/5.3.0

_"plugins/bootstrap-wysihtml5"_: https://cdnjs.com/libraries/wysihtml/0.4.15

_"plugins/chartjs"_: https://cdnjs.com/libraries/Chart.js/1.0.2

_"plugins/ckeditor"_: https://cdn.ckeditor.com/

etc...

@racztiborzoltan I prefer an administration panel not to use CDNs.

I believe dependencies should be included the way that makes the template easiest to download and view. Typically, the template will not be used as-is and will need to be processed and prepared for use anyway. For example, with modern frameworks, it's typical to replace the dependencies like Bootstrap and jQuery with asset packages.

Suggestion: Pre-slice the template

Typically, the template needs to be sliced to separate the header, footer, ...etc and this repeats with each new version. It's better for project developers and for the development of AdminLTE itself to keep it sliced form the beginning. If viewing the template without a web server is required, a pre-generated static version could be added in a demo folder.

The problem with CDns is that when they are not working, the whole thing becomes a mess. And to the new user who visits Adminlte, It does not give a good first impression.

And they will be probably slower because of additional DNS lookups. Webservers using HTTP2 can handle multiple static files simultaneously without problem.

  • not every project uses bower
  • If a frontend developer starts an admin

    • example:

    • copy content of starter.html

    • paste into own template system (twig, blade, volt, etc...)

    • change the resource links (script src; link href, img src, etc...)

    • maybe use asset manager (javascript and css collector, minificator)

Who uses the starter.html file without the slightest change? Who has no problem using the CDN-s.
Otherwise: bower, npm, composer, etc. Decide the developer.

@racztiborzoltan first of all, we appreciate the suggestions! Regarding CDNs, we have tried that in a previous version of AdminLTE. A major problem was offline support. We'd like to offer the maximum amount of support across different environments. This is only achievable by providing the source code to run locally. However, we add links in the documentation to all the plugins we use. This way, it is easy for a person who prefers CDNs to pick the plugins that offer them.

Thank you all for the suggestions! We are working currently on V3 and very excited to push the newest changes. We think you'll love the new updates and features.

Thanks!

@almasaeed2010 : two types of github release?

  • AdminLTE.VERSION.zip - with local resource links (jquery, datepicker, etc. etc.)
  • AdminLTE.VERSION.small.zip - with CDN resource links, if CDN link exists
  • and, of course the original source code release

@racztiborzoltan unless this is fully automated, it would be a source of problems and unmatching packages. There have been problems with maintaining version numbers in packaging files (hopefully will be solved in v3), so imagine adding multiple editions to the mix.

@YasserHassan : thanks for the reply

Another suggestion: Polyfill services - A helping hand for the legacy browsers.

@racztiborzoltan as you can see from previous discussions, I'm not pro for supporting legacy browsers (e.g. IE 10 and earlier). It's either a trade off between either innovation and creativity vs. supporting old technologies or having both at a high extra cost. Besides that, I have a feeling that Polyfill would actually complicate things rather than solve problems. We better start from an objective and reach an agreement on one thing that needs to be done and adopt to it knowing that we won't get everything. The effort and time dedicated to managing different technologies just to get the template to work in different environments will not only not add to the project bottom line but will also consume part of the available effort that @almasaeed2010 and other contributors are thankfully dedicating to this project without a real gain.

+1 for gulp instead of grunt (for easier embedding in Angular based apps)

"Suggestion: Pre-slice the template"

Yes, yes, yes.

This is crucial for anything more than just playing a bit with the template. If you're trying to set up a site with some pages and not others, it's a lot of cutting and pasting and cleaning up. I imagine it's also a lot more of a pain to maintain for the author.

@YasserHassan
@drorm

"Suggestion: Pre-slice the template", I also like that.

But I don't like how the Bootstrap maintainers did that, I don't want to play with Jekyll in order just to see the template from a local computer. I think about something different, although I did not see it done by somebody else - to use Twig template engine, a JavaScript implementation: https://github.com/twigjs/twig.js It could assemble the final pages from their fragments, also it could fill the demo data. For those projects that use the Twig engine (or other similar engines that exist, with almost the same syntax) this would be a great easing.

Suggestion: Consider Semantic-UI http://semantic-ui.com , https://github.com/semantic-org/semantic-ui/ as a base for the next major implementation. This sounds radical, but I think it would be a good choice. For such an implementation I am motivated to help with some of my time here.

why closed? does the plan to move to bootstrap4 still exist?

Are we not moving to bootstrap 4 anymore?

maybe you can crowdfund this effort ?

Thanks for the great work! Is there a roadmap/timeline for version 3.0? I would be particularly looking forward to Angular support.

Would be more than willing to contribute time

I can also contribute :)

I am so happy if I can contribute also :)

Will you still be using bower as it is deprecated now?

AdminLTE 3.0 is completely dependent on the release of a stable Bootstrap 4.0. Currently BS4 is in alpha stages. Unfortunately, we can't do anything until at least a release candidate for BS4 is announced.

The product of these changes should make AdminLTE highly customizable and convert it into a framework

Perfect, i'll wait those changes 👍

@almasaeed2010 u are a genius men.

The beta is out, is it considered stable enough to be the root of AdminLTE 3.0 ?

They said that BS4 beta will have no more BC, so I think it is stable enough.

Awesome! Hype!

Bootstrap is currently v4.0.0-beta, this is stable enough to release a BS4 version of AdminLTE 3.0
Any plans for a first release soon!

@almasaeed2010 any updates?

Is this plan is active? The BS4 beta has released and now it is the latest version. The Bootstrap home page has change already.

@almasaeed2010 any update on the future of AdminLTE?

SASS instead of LESS

yes!

The box component will be replaced with the new BS4 cards

don't do that please, the box component is awesome and highly customizable, the perfect replacement for BS3 panels.

@EliuTimana +1

Hi,
any release date?
thank's

After 2 years any update ?

Any news?

Thank you all for your interest in AdminLTE 3. I understand that it has been a long time since any progress was made towards upgrading the template. The good news is that with BS4 finally out, I’ve been working on a new plan for AdminLTE and trying out the new BS4 framework. Soon, I will post a full update on the progress and hopefully have the ground work laid out for the next big release :D
I am really excited about resuming the work and coming up with new ideas and tools to make AdminLTE better for all of us.
Thank you for your patience and enthusiasm.

What about start using yarn instead of bower and webpack?

@EliuTimana using yarn(npm) instead of bower is good idea, but webpack is for module bundle not to manage packages ;)

I am also curious about the status of bootstrap v4 support. Laravel v5.6 uses Bootstrap v4 by default now. Various projects seem to be switching to CoreUI because of the lack of bootstrap v4 support in AdminLTE. Laravel-boilerplate uses CoreUI now.

I would love to contribute 💯

AdminLTE 3 dev is now available in the dev branch https://github.com/almasaeed2010/AdminLTE/tree/v3-dev

Eager to hear your opinion, issues and comments! Let's make this the best for everyone :D

the new branch. joined

@almasaeed2010 any approximate date of stable version/release for AdminLTE3?

I am working on the control sidebar and figuring out which plugins have support for bootstrap 4. Any plugins that don't bootstrap 4 will have to get removed. Once those 2 tasks are done we'll release a beta version for people to test. meanwhile, we'll need to write the new documentation. If not many issues arise, we'll release 3.0. So the process might take some time. I'd assume 1 month before the stable release is available (can't promise anything but this seems reasonable to me).

I am really excited to get this version out there :) hopefully that won't take long.

Will the 3.0 release use Font Awesome 5.0?

Don't forget Right To Left Please :heart:

Any plan to release an angular version, as of now i am trying to build an angular app using PrimeNG which is an awesome component library, however many people are trying to include AdminLTE in Angular, i would be happy to contribute if there are any plans for the same and thanks for a great Bootstrap Template.

Any dates for release at npm?

@pacificobr see #1869

any news?

If its Bootstrap 4.0 then should it not be Admin LTE 4.0 to avoid confusion :)

The previous version was 2 and the bootstrap version that it was based was bs3, I don't see any problem with that.

any news?

现在离发布Admin LTE 3.0计划都几年了,难产了吗

期待Admin LTE 3.0早日发布

可能难产了

https://github.com/almasaeed2010/AdminLTE/tree/v3-dev

This branch seems unfinished? In that its missing skins and all sorts of other css files in the dist folder? Am I missing something obvious here?

https://github.com/almasaeed2010/AdminLTE/tree/v3-dev

This branch seems unfinished? In that its missing skins and all sorts of other css files in the dist folder? Am I missing something obvious here?

Yes, that's why there is dev in the name of the branch. It's under development.

https://github.com/almasaeed2010/AdminLTE/tree/v3-dev

This branch seems unfinished? In that its missing skins and all sorts of other css files in the dist folder? Am I missing something obvious here?

Yes, that's why there is dev in the name of the branch. It's under development.

I realise that - the reason I ask is that there is a Admin-LTE 3 Alpha release only a few commit behinds. Being alpha I would have thought most core stuff like skins would be in here?

Do I need to build dist/css/adminlte.min.css or something? I can see commits relating to skins so not sure why I cant figure this out.

Can see the skin files were part of the LESS CSS. But were deleted with this commit 7b67b58db6128bc5d3c6d2409b81ef4c1348d32a. Cannot seem to find the addition of the same files with SCSS.

AdminLTE 3 no longer has skin classes. To reduce the footprint of the framework, v3 defines a list of modifiers that can be mixed and matched to build your own "skin". For examples on available combinations, visit https://adminlte.io/themes/dev/AdminLTE/ then open the right sidebar:

screen shot 2019-02-20 at 1 13 02 pm

Oh I see! Right that makes sense. OK will have another stab at this. Thanks.

Waiting anxiously for version 3 to download ...

I am working on the control sidebar and figuring out which plugins have support for bootstrap 4. Any plugins that don't bootstrap 4 will have to get removed. Once those 2 tasks are done we'll release a beta version for people to test. meanwhile, we'll need to write the new documentation. If not many issues arise, we'll release 3.0. So the process might take some time. I'd assume 1 month before the stable release is available (can't promise anything but this seems reasonable to me).

I am really excited to get this version out there :) hopefully that won't take long.

Almost a full year out from this post, very excited to get working with this and hoping there is any update you can share?

It is now March 15, 2019. What is the story on the AdminLTE 3 release date?

Any news on AdminLTE 3?

It will come very soon

Hi, do you have any idea when it will arrive? or you are not working on it any more, that would be useful info as well.

Any news for the release date of V3?

Current get 404 error for V3 Dev Demo: https://adminlte.io/themes/dev/AdminLTE/

@pctin Oh dang, I did a misstake 🤦‍♂ I've fixed the 404 error.

About release:
I look forward to release soon v3.0.0-beta.1 with some fixes and nice enhancements, after release I need to look over all the open issues and pick all v3 issues or feature requests.
May I release beta.1 without docs and create them with beta.2.

That's excellent news indeed!

The AdminLTE3 preview is simply gorgeous. I have no doubt that it's by far the best free (as in speech) bootstrap admin template available. I do hope you can release it asap.

Just let us know if we can help with the documentation (I could help with the spanish translation, if you find it somehow useful)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jrlooney picture jrlooney  ·  3Comments

tester10 picture tester10  ·  3Comments

REJack picture REJack  ·  3Comments

riklaunim picture riklaunim  ·  3Comments

kgoedert picture kgoedert  ·  4Comments