[4.0] total rewrite on top of a REAL (micro) framework (Slim, Laravel, ...) ?

[panique]

Hey Ladies & Gentlemen,

I'm the main author behind php-login and want to discuss the future of the project with you in this ticket. Feel free to comment and speak freely, let's brainstorm this.

A. The future of php-login

The user authentication ("login") feature of php-login is obviously useful for lots of people, but the underlaying application structure is just a self-made quick-solution. In 2015 php-login will be rewritten, and to avoid creating another (pseudo) PHP framework the big question is: Should this project ...

1. ... be rewritten on top of a well-written, widely accepted and future-proof framework ? I'm thinking of Laravel here.
   PRO: high-quality code/architecture possible
   CON: this will raise the barrier for developers who are not on the "real framework" skill level. Hmm, but then php-login-minimal might be an alternative...
2. ... be rewritten with a extremely reduced architecture under the hood, self-written (?) or by using a micro-framework like Slim. Slim is more a router than a real framework as it comes without an own application structure, so I'm also unsure here. But in general this option feels good.
3. ... be rewritten as a plugin etc. for every custom framework. I've no idea how this could be possible, but maybe it's an option.
4. ... other ideas ?

B. How do authentication libs in big frameworks look like in 2014/2015 ?

Maybe the user auth / login solutions for major frameworks have evolved so much that php-login is completely obsolete now (I've written php-login because there was no easy-to-use and easy-to-understand standalone user auth solution available in 2012, beside that basically all auth tutorials were using horrible md5 hashing etc.). Please let's discuss this a little bit.

[nyubbie]

Laravel is a good choice -- I'm learning it myself.

That said, I believe everything can be made understandable as long as you document and explain each step taken to newbies (like me)... didn't take me long to understand your php-login framework, and this is coming from someone who develops Wordpress-based websites.

[olimorris]

Very good question to ask. I'm very fond of php-login as it taught me the basics of a good PHP framework and I have since built my own site around it. Few comments/questions on your above suggestions:

1. Laravel/Other big frameworks - If you did rewrite it for Laravel, do you think you'd still have a large user base? Are there not login plugins that are tried and tested for those frameworks? Also what would be the level of development time you'd need to invest to turn this around? From a personal perspective, would you get as much personal enjoyment out if conforming to someone else's framework?

2. This would be my selfish preference. Stays true to the current version of php-login and allows you to implement some great new features more quickly. Doesn't feel like it would be as time intensive as 1).

3. This sounds painful. Also wonder about all the different "fixes" you may need to include to keep it functioning for every custom framework.

4. Wonder if you plan on releasing an update to your php-mvc framework. Big fan of that as a simple framework and I would be keen to see php-login evolve in its own right but still based on your php-mvc architecture

[panique]

@olimorris He, thanks for the feedback! My personal favourite is #2 for sure, php-login on top of Slim or another mini-framework/router.

Regarding your question nr. 4 on php-mvc: The project has been renamed (it's now called MINI), restructured and partly rewritten two weeks ago, have a look! This is not final, so expect changes here and there. THere's also a smaller version of MINI (ex-php-mvc), called TINY, that runs in every environment. For 2015 I'm planning on MINI2 or MINI+, a much more advanced version that comes with proper architecture, SASS-compiling, Twig, Unit Tests, bowerPHP etc.

To question nr. 2: When php-login was written in 2012 there were no useful auth libs for Laravel (at least I didn't find any), and to be honest I'm unsure what the current status in the Laravel world is. There are probably much much more adavanced tools now. I'm also definitly not doing this for enjoyment :) If there's something that's better and easier to use than php-login, then I would instantly stop this project here (seriously!).

[abmmhasan]

I like the slim better than laravel. Fact is, I don't want a complex framework in this framework.
I can help you with some more name, if you like(I would love to contribute on this project too :)).
Fat free Framework is another one I like most.
Also, some more to mention
Hackwork
Silex
Rest
MicroMVC
I don't want to follow them all but Fat Free, Hackwork, slim are good. Silex, Rest, MicroMVC is good to be followed for some pattern!?!
Phalcon arranged some good example.
& the one that made me feel tiny :P Short PHP

[Dominic28]

Hey,
If you take a look at some of the linked frameworks of @abmmhasan you see they are totally different from what is php-login now (folder structure and so on). The people using your script chose it because it's easy to use and understand. Changing the structure wouldn't be good for most of them.

So for me Laravel would be better as the structure is nearly the same, but of course it's a bigger Framework and maybe too big for someone who just want to build a simpler website.

[cybernet]

hackwork seems small and awesome :)

[prisis]

Maybe you like to use my framework [https://github.com/narrowspark], it based on Slim, has the same structure like Laravel but its much smaller, but is not ready yet...

[normai]

Hello, here nothing productive, just a bit provocation.

Sure: Never re-invent the wheel! Instead use a framework.

But also remember what Marco Cecconi tells on http://www.dev-metal.com/architecture-stackoverflow (minute 25) about square wheels. When on a rugged road, they might be the better ones (http://c2.com/cgi/wiki?SquareWheel). On Stackoverflow, they sometimes purposefully disregard the 'Never re-invent the wheel' law.

Any framework will introduce additional dependencies, especially if it updates. The smaller the better.

Many greetings!

[panique]

Personal note
I'm writing this in November 2014, and most popular frameworks seem to have auth modules and example implementations now (this was not the case back in 2011/2012, some were even using md5 hashing then). Every professional developer would chose these solutions for sure, but these implementations are mostly hard to understand and don't come with a working example, so you'll have to build everything from scratch by yourself. This leads to the question:

Is there still a need for something like php-login ?

My personal opinion: Yes, a very near-native, extremely simple, out-of-the-box implementation of a simple user auth / login system totally makes sense. php-login itself was just a more-or-less quick and crappy thing i've written in my freetime to power some applications, and it has become a quite popular thing.

So, my current idea of php-login's future is:
1.) Building an extremely minimal out-of-the-box demo application with full "login system" (user auth) on top of a major *micro-framework
2.) Use Slim or Silex 1 2 for this. I would use Silex, as it's extremely professional and maintained by full-time developers while still totally understandable even for beginners (!). You'll realize how Silex works right after looking into the docs for 1 minute.
3.) MAYBE use Symfony's auth modules (to keep things professional)
4.) MAYBE a good start is this tutorial and this LIVE DEMO, demo's code here. FYI: The user handling/editing comes from this.

But, this might still be too complicated... hmm... Maybe totally native code is better here. I'm really unsure.

Useful links of existing auth solutions in major frameworks:

FuelPHP and Fuel auth pack , Slim / Slim demo implementation, Laravel Auth, but there's no demo implementation, but some tutorials here and here. Zend2 and Symfony2. Looks also good: Aura + Aura Auth

Extremely useful starter apps with Slim
1.) https://github.com/xsanisty/SlimStarter
I also totally love the installer, the self-starting one-click demos (!) and the overall attitude in the project! A serious killer thing.
2.) https://github.com/revuls/SlimMVC
Sexy! Love it! I like the simplicity. Please note that the SHA1 hashes are just for demo purposes.

Interesting statement about Slim not using controllers

Slim does not use controllers to organize application methods or routes; controllers are beyond Slim’s concern.

Taken from http://www.slimframework.com/news/how-to-organize-a-large-slim-framework-application

Useful package for easy login solutions (used in SlimStarter above)
https://cartalyst.com/manual/sentry/2.1
BUT, a pure SQL-solution might be more easy to use/edit here

[panique]

Personal note
I think the new php-login will be

a.) as native as possible (no HotExternalLibrary::getSomeStuffForMe() if not necessary)

b.) as simple as possible

c.) as readable as possible

d.) on top of Slim

e.) taking some architecture things from SlimMVC

f.) do not use the terms models, views etc to avoid "you're doing it wrong"-discussions with trolls and "every framework is shit"-experts (there are so many people out there spending a lot of time bashing basically every piece of software, it's unbelievable. let's give them as few space for attacks as possible)

g.) provide a basic login / auth solution for common use-cases, nothing special, just the normal login/logout thing, in the most easy-to-understand code possible, plain native PDO statements, easy to edit, easy to debug. No external libraries if not nessary.

h.) clearly label the project as free hobby-project, written by unpaid volunteers (to avoid idiotic discussions with people complaining (!) about missing features, non-optimal code, why-is-this-not-like-framework-X). sorry for the harsh words, but it's so true, people treat this like they have bought it for $100.000. It's extremely weird that so many people use your free software to earn lots of money with it (!) and then seriously expect free support (!!), personal code-fixing ("asap!" !!!) or long explainations why feature X is not delivered yet ("but i need the feature! can you please code faster ?") and then also don't accept a "sorry, this is not possible." and start to discuss. This is a serious issue, the communication channels of php-login should be chosen wisely (and maybe moderated?) to avoid bombardements of vandals, and to clearly communicate what this project is. People have a strange understanding of free things on the web.

The general goals is:
Create a modern version of current php-login repo. Create an extremely simple and easy to understand login solution that runs out of the box, comes with a modern architecture and uses "modern password security" (bcrypt hashing/salting like php-login does). Not more features than necessary for a common basic application.

[nyubbie]

I think that's a good way to go.

However, I don't think you need to really bother about people commenting on your framework to say it's crap and stuff because these people always exist and even if you avoid going down Path A, chances are there are always a percentage of them already waiting at Path B, C, D, etc just to bash your framework.

Just go with your own choice, it is your framework and your vision -- people who understand and use your framework will always thank you for it (look at them stars!), people who don't like it will contribute via branches, or leave sooner or later in the end.

[Melbournite]

My comments, which much align with yours:

• Stay native. There's plenty of existing login systems (even if not compiled as neatly as this) for existing frameworks. Many are clunky, bloated and annoying (not trying to elaborate on framework bashing, either!)
• Stay minimal with code.
• Will the latest social login systems be implemented also?

Not sure if you're intending on a professional/advanced/slim offering for the impending 3.0 version, however if so, the professional version could make use of Bootstrap or another widely used CSS project. Yes, it's not much work to implement, particularly on the "styless" versions, but for ubiquity it would be nice to be by default. Would put this far beyond existing boiler plates. It would use a system that's easy to apply existing and crafted styles to with minimal effort required. Perhaps I am being a little lazy and selfish, however...

I guess the downsides are ensuring that Bootstrap is up to date. Perhaps it could be a fork, though in my opinion it should be in the main branch. You may disagree with this and I fully understand, not everyone loves or uses Bootstrap.

Looking forward to seeing some progress on version 3.0!

[panique]

Current status 25th January 2015:

• 2.0 will be archived as the "old-stable", latest snapshot of 2.x is the v2.1.1 release.
• 3.0 will be the new version, release if in the next days. New architecture, massive rewrite, everything is as native as possible (so 3.0 is NOT using a micro framework under the hood). The project is also renamed to HUGE (to avoid the too generic name "php-login". the big PHP guys usually don't like it when a project name is too generic, and I basically agree with that)
• 4.0 might be a potential new version, rebuilding the status of 3.x on top of Slim, Silex or so, allowing quite professional things like RESTful architecture, Middleware, etc.

Let's release 3.0 for now and then let's introduce new features, step by step, into 3.x, over the entire year. I think this is a good plan :)

[tankerkiller125]

I will say it now that as a user that has never used a real framework the whole reason I even use php-login/HUGE was for the MVC framework. Even when I don't need authentication or logins I use HUGE because of its amazing ease of use and simple interface.

[normai]

On 2015-02-09 16:11, Roger wrote:

Can this be used with a Firebird SQL database?
Any interest in Firebird SQL Database?

See normai#2

[panique]

Hi, I'm closing this ticket, the reason is: Most other frameworks also have proper login systems, so there's no need to rewrite this on top of Laravel or so, this wouldn't make sense. I think it's cool to keep this project as tiny and independet as it is.