Wanted to let you know that I have released Escher CMS into the world.
It is available for download here: http://www.eschercms.org/
I'm really excited to finally get this out for general use, feedback
and community involvement. Please join me on the Escher forums for
user discussions, help and to share experiences and feedback. There's
so much more to be done, and I'm really looking forward to this next
stage in Escher's development where more people can get involved and
contribute to the project.
Looking forward to hearing your feedback.
Best,
Sam
congratulations on the release of EscherCMS. First impressions of
spark/plug are very good. Nice to see OO in a cms -- not too used to
that with Txp. Patterns too!
I haven't started looking at the Escher source code yet -- trying to get
a feel of things lower down first.
htmLawed looks like a really interesting choice for sanitization. It's
the first time I've come across it and will be taking a closer look. Its
use also suggests that you are willing to leverage external libraries
within the spark/plug framework, which I like.
Along exactly those lines, I'll have a shot at preparing a patch for
sparkplug/plugs/sparkauth/sparkauthmodel.php to use openwall's phpass
instead of the single md5 password hashes.
As a related question, does Escher + Spark/plug allow a pam-like
replacement of the default auth model? It's not really possible in Txp
via plugins as the admin authentication has to happen prior to plugin
loading. If, in Escher, alternate plugs might be used for the
authentication, then I have another potential addition to the framework.
BTW, although this might not match the lightweight nature of the
sparkmailer you've written, http://swiftmailer.org/ is one highly OO
email system you can pretty much plug into any project.
Regards,
--
Steve
just looking at the manifest.php files I wonder if the 'runs_where'
could do with a more semantic type -- perhaps an enumeration or even a
string. As a newcomer to the code I have no idea what 'runs_where'=>1
means but the other entries (name/extends) are already semantic. Seems a
shame to break the orthogonality.
--
Steve
Thanks! Yes, I'm a big proponent of OOP, having been one of the beta
testers of the original AT&T "cfront" C++ pre-processor.
> I haven't started looking at the Escher source code yet -- trying to get
> a feel of things lower down first.
>
> htmLawed looks like a really interesting choice for sanitization. It's
> the first time I've come across it and will be taking a closer look. Its
> use also suggests that you are willing to leverage external libraries
> within the spark/plug framework, which I like.
Absolutely. Willing to incorporate any sensible library with a
compatible license.
> Along exactly those lines, I'll have a shot at preparing a patch for
> sparkplug/plugs/sparkauth/sparkauthmodel.php to use openwall's phpass
> instead of the single md5 password hashes.
Cool. This is one of your Txp patches that I was interested in. Would
be neat if you could create it as a plug extension to the existing
plug, rather than as a patch to its code. Spark/Plug and Escher are
designed to be patched and extended via plugs, so the goal is that the
core code or existing plug code need not be changed to add new
features.
> As a related question, does Escher + Spark/plug allow a pam-like
> replacement of the default auth model? It's not really possible in Txp
> via plugins as the admin authentication has to happen prior to plugin
> loading. If, in Escher, alternate plugs might be used for the
> authentication, then I have another potential addition to the framework.
It should be possible. Escher relies on Spark/Plug's auth, which is
just a plug. (BTW, I use "plug" for Spark/Plug plugins and "plugin"
for Escher plugins to disambiguate the two.
> BTW, although this might not match the lightweight nature of the
> sparkmailer you've written, http://swiftmailer.org/ is one highly OO
> email system you can pretty much plug into any project.
I've heard of SwiftMailer but never used it. Went with PHPMailer
because it is lightweight and I have used it in the past. No reason we
could not offer an alternative mailer plug for SparkPlug. If you
implement the same API as the existing mailer, then it would just drop
in as a replacement.
Sam
Good point. I'll add that to the todo list for next version.
1 -> runs in admin
2 -> runs in public side
3 -> runs in both