[mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
After spending 8 months with wordPress, I am throwing my hands up and 
moving back to my home language python.
I saw mezzanine was probably the cms that would give me the least 
problems, but I have some questions:
1. The edit page screen is really messy and difficult to navigate. I am 
using a screen reader, so that may be part of it, but why is the publish 
date stuff right under the title? why is not content right under title? 
I would like to enter the title, hit tab and enter the page content. 
Also, why is the body text editor not a multi edit field? The weird 
thing is that it now is almost unusable... I can't use navigation 
commands to get into it or out of it, it says "paragraph editable" while 
arrowing through each line and there is no advantage anywhere for having 
this. Perhaps it is a wysiwyg editor and that is why I don't see 
anything good about it. If so, how can I disable the wysiwyg editor for 
my account?
2. Not being able to write html from within the editor is horrible, I 
need to fix it. I spent all last night trying to think about how one 
could change the user permissions on them self, but couldn't come up 
with anything. Perhaps it has to do with the backend, but it just seems 
so unlikely it will never happen.
3. Is it possible to add short-codes or code within the editor so I can 
access variables and or functions that I have created without making a 
template?
4. Has mezzanine considered distributing brython along with the servers? 
I can add it, but it would make more sense to have things in brython 
rather than javascript for a python based product...
5. How is the user account support? I would like to have people connect 
with Facebook or google and grab info from there to populate the user's 
fields on their account pages.
6. What hosts are easy to use with mezzanine? I am looking for a new one 
and would prefer one with CPanel.
7. Are all the plugins there on the front page? Is there a way to get 
plugins or templates from within the dashboard? This is something that 
makes wordPress exceptional for quick development.

Thank you,

--
Brandon Keith Biggs 

--
You received this message because you are subscribed to the Google Groups "Mezzanine 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Josh Cartmell]

Hi Brandon, hopefully the following are helpful answers!

   1. Title + the publishing controls are present across all things that
   inherit from the Displayable class where as the type of content on those
   various models will vary from class to class.  Blog Posts have categories
   and content, Rich Text Pages just have content, Links have no content,
   etc... All the admin classes of those models inherit from Displayable so
   they end up all having those things grouped.  Besides the technical reasons
   I think the consistency is useful and I find it nice to always be able to
   have the publishing controls right there.
   2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's
   what they have to say about accessibility,
   http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe some
   or all of that isn't working?
   You can change what is used though, for example in your project's
   settings.py file you could put:
   RICHTEXT_WIDGET_CLASS = "forms.Textarea"
   Doing that should get rid of the WYSIWYG and those types of fields
   should just show up as normal HMTL textareas.  That would affect any admin
   user, not just yourself.
   3. There isn't anything like that built in, there might be other
   projects that do things like that for Django that you could integrate with
   Mezzanine.
   4. I don't think we have considered Brython but it should be easy to
   integrate any front end technology you want.  Right now Mezzanine ships
   with Twitter Bootstrap as a frontend framework and I think most people,
   myself included, are very happy with it.  But really, Mezzanine doesn't
   force front end technology on you, it just default to Twitter Bootstrap and
   you can change that easily by changing your project's base.html
   Brython does look interesting though so I may have to take a look at it
   at some point!
   5. Mezzanine does have some user account/profile support.  Here are the
   docs, http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine
   doesn't have any social login support but there are quite a few Django apps
   that do that which you could use to add that functionality
   6. I tend to use https://www.digitalocean.com/ (VPS) or
   https://www.webfaction.com/ (shared host).  I've never used it on a
   cPanel host but you do need ssh access to a host to be able to deploy
   Mezzanine.
   7. Mezzanine doesn't have plugins in the same sense as Wordpress.  You
   can't install anything through Mezzanine's admin interface other than
   possibly adding some Javascript to the content of pages.  Here is a list of
   modules that have been created for use with Mezzanine,
   http://mezzanine.jupo.org/docs/overview.html#third-party-modules but
   most if not all of them probably require modifying at a minimum your
   projects settings.py file

Here are a few more thoughts:

Mezzanine is Django so anything you can do with Django you can do in
Mezzanine.  That means that when you look for modules you can cast a wider
net than just looking for things that were specifically made for Mezzanine

The following is my opinion and I'm sure my bias towards Mezzanine will
show.  Mezzanine and Wordpress have fundamentally different philosophies.
Wordpress is more targeted at end users by making it easy to install
plugins through the admin interface.  I tend to think that with a Wordpress
site you could get 80% to 90% of the functionality you want with plugins
but that last 10% may be very difficult.  Mezzanine on the other hand
requires you to either have a developer or know how to code yourself.  It
doesn't try to be all things to all people but does provide a solid core
feature set and makes it easy for a Django developer to add missing
functionality.

Hopefully that helps.  Welcome to Mezzanine and please keep asking
questions.  Good luck!

On Wed, Apr 22, 2015 at 6:10 AM, Brandon Keith Biggs <
brandonkeithbi...@gmail.com> wrote:

>  Hello,
> After spending 8 months with wordPress, I am throwing my hands up and
> moving back to my home language python.
> I saw mezzanine was probably the cms that would give me the least
> problems, but I have some questions:
> 1. The edit page screen is really messy and difficult to navigate. I am
> using a screen reader, so that may be part of it, but why is the publish
> date stuff right under the title? why is not content right under title? I
> would like to enter the title, hit tab and enter the page content. Also,
> why is the body text editor not a multi edit field? The weird thing is that
> it now is almost unusable... I can't use navigation commands to get into it
> or out of it, it says "paragraph editable" while arrowing through each line
> and there is no advantage anywhere for having this. Perhaps it is a wysiwyg
> editor and that is why I don't see anything good about it. If so, how can I
> disable the wysiwyg editor for my account?
> 2. Not being able to write html from within the editor is horrible, I need
> to fix it. I 

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
Is it possible to have user settings for each person? Because I could 
have a check for my user profile and say if user == me, 
RICHTEXT_WIDGET_CLASS = "forms.Textarea".
I could also mod my account to look like I want it, but other users may 
wish to have their account look different. Are settings local to a user? 
If not, why?

thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all things that
inherit from the Displayable class where as the type of content on
those various models will vary from class to class.  Blog Posts
have categories and content, Rich Text Pages just have content,
Links have no content, etc... All the admin classes of those
models inherit from Displayable so they end up all having those
things grouped.  Besides the technical reasons I think the
consistency is useful and I find it nice to always be able to have
the publishing controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE. Here's
what they have to say about accessibility,
http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
some or all of that isn't working?
You can change what is used though, for example in your project's
settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of fields
should just show up as normal HMTL textareas.  That would affect
any admin user, not just yourself.
 3. There isn't anything like that built in, there might be other
projects that do things like that for Django that you could
integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be easy to
integrate any front end technology you want.  Right now Mezzanine
ships with Twitter Bootstrap as a frontend framework and I think
most people, myself included, are very happy with it.  But really,
Mezzanine doesn't force front end technology on you, it just
default to Twitter Bootstrap and you can change that easily by
changing your project's base.html
Brython does look interesting though so I may have to take a look
at it at some point!
 5. Mezzanine does have some user account/profile support. Here are
the docs, http://mezzanine.jupo.org/docs/user-accounts.html.
Mezzanine doesn't have any social login support but there are
quite a few Django apps that do that which you could use to add
that functionality
 6. I tend to use https://www.digitalocean.com/ (VPS) or
https://www.webfaction.com/ (shared host).  I've never used it on
a cPanel host but you do need ssh access to a host to be able to
deploy Mezzanine.
 7. Mezzanine doesn't have plugins in the same sense as Wordpress. 
You can't install anything through Mezzanine's admin interface

other than possibly adding some Javascript to the content of
pages.  Here is a list of modules that have been created for use
with Mezzanine,
http://mezzanine.jupo.org/docs/overview.html#third-party-modules
but most if not all of them probably require modifying at a
minimum your projects settings.py file

Here are a few more thoughts:

Mezzanine is Django so anything you can do with Django you can do in 
Mezzanine.  That means that when you look for modules you can cast a 
wider net than just looking for things that were specifically made for 
Mezzanine


The following is my opinion and I'm sure my bias towards Mezzanine 
will show.  Mezzanine and Wordpress have fundamentally different 
philosophies.  Wordpress is more targeted at end users by making it 
easy to install plugins through the admin interface.  I tend to think 
that with a Wordpress site you could get 80% to 90% of the 
functionality you want with plugins but that last 10% may be very 
difficult.  Mezzanine on the other hand requires you to either have a 
developer or know how to code yourself.  It doesn't try to be all 
things to all people but does provide a solid core feature set and 
makes it easy for a Django developer to add missing functionality.


Hopefully that helps.  Welcome to Mezzanine and please keep asking 
questions.  Good luck!



On Wed, Apr 22, 2015 at 6:10 AM, Brandon Keith Biggs 
mailto:brandonkeithbi...@gmail.com>> wrote:


Hello,
After spending 8 months with wordPress, I am throwing my hands up
and moving back to my home language python.
I saw mezzanine was probably the cms that would give me the least
problems, but I have some questions:
1. The edit page screen is really messy and difficult to navigate.
I am using a screen reader, so that may be part of it, but why is
the publish date stuff right under the title? why is not content
right under title? I would like to enter the title, hit tab and
enter the page content. 

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Josh Cartmell]

Hi Brandon, conceptually settings are intended to be configured for a
project as a whole and aren't intended to be configured per user.

That said something I think you could do, I've never done this, would be to
create a user profile and have one of the fields be a CharField that stores
the dotted path to a rich text widget.  You could have it default to being
blank, and then in your case change it to "forms.Textarea"

Then you would set RICHTEXT_WIDGET_CLASS to a custom widget which you would
create.  You custom widget would need some logic to check the current
user's profile and basically return whatever widget their profile indicated
if any, and otherwise return the Mezzanine default (or something like
that).

On Wed, Apr 22, 2015 at 11:26 AM, Brandon Keith Biggs <
brandonkeithbi...@gmail.com> wrote:

>  Hello,
> Is it possible to have user settings for each person? Because I could have
> a check for my user profile and say if user == me, RICHTEXT_WIDGET_CLASS =
> "forms.Textarea".
> I could also mod my account to look like I want it, but other users may
> wish to have their account look different. Are settings local to a user? If
> not, why?
> thanks,
>
>  Brandon Keith Biggs 
> On 4/22/2015 4:46 PM, Josh Cartmell wrote:
>
> Hi Brandon, hopefully the following are helpful answers!
>
>1. Title + the publishing controls are present across all things that
>inherit from the Displayable class where as the type of content on those
>various models will vary from class to class.  Blog Posts have categories
>and content, Rich Text Pages just have content, Links have no content,
>etc... All the admin classes of those models inherit from Displayable so
>they end up all having those things grouped.  Besides the technical reasons
>I think the consistency is useful and I find it nice to always be able to
>have the publishing controls right there.
>2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's
>what they have to say about accessibility,
>http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
>some or all of that isn't working?
>You can change what is used though, for example in your project's
>settings.py file you could put:
>RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>Doing that should get rid of the WYSIWYG and those types of fields
>should just show up as normal HMTL textareas.  That would affect any admin
>user, not just yourself.
> 3. There isn't anything like that built in, there might be other
>projects that do things like that for Django that you could integrate with
>Mezzanine.
>4. I don't think we have considered Brython but it should be easy to
>integrate any front end technology you want.  Right now Mezzanine ships
>with Twitter Bootstrap as a frontend framework and I think most people,
>myself included, are very happy with it.  But really, Mezzanine doesn't
>force front end technology on you, it just default to Twitter Bootstrap and
>you can change that easily by changing your project's base.html
>Brython does look interesting though so I may have to take a look at
>it at some point!
> 5. Mezzanine does have some user account/profile support.  Here are
>the docs, http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine
>doesn't have any social login support but there are quite a few Django apps
>that do that which you could use to add that functionality
>6. I tend to use https://www.digitalocean.com/ (VPS) or
>https://www.webfaction.com/ (shared host).  I've never used it on a
>cPanel host but you do need ssh access to a host to be able to deploy
>Mezzanine.
>7. Mezzanine doesn't have plugins in the same sense as Wordpress.  You
>can't install anything through Mezzanine's admin interface other than
>possibly adding some Javascript to the content of pages.  Here is a list of
>modules that have been created for use with Mezzanine,
>http://mezzanine.jupo.org/docs/overview.html#third-party-modules but
>most if not all of them probably require modifying at a minimum your
>projects settings.py file
>
> Here are a few more thoughts:
>
> Mezzanine is Django so anything you can do with Django you can do in
> Mezzanine.  That means that when you look for modules you can cast a wider
> net than just looking for things that were specifically made for Mezzanine
>
> The following is my opinion and I'm sure my bias towards Mezzanine will
> show.  Mezzanine and Wordpress have fundamentally different philosophies.
> Wordpress is more targeted at end users by making it easy to install
> plugins through the admin interface.  I tend to think that with a Wordpress
> site you could get 80% to 90% of the functionality you want with plugins
> but that last 10% may be very difficult.  Mezzanine on the other hand
> requires you to either have a developer or know how to code yourself.  

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Tom Lockhart]

On Apr 22, 2015, at 8:26 AM, Brandon Keith Biggs  
wrote:

> Hello,
> Is it possible to have user settings for each person? Because I could have a 
> check for my user profile and say if user == me, RICHTEXT_WIDGET_CLASS = 
> "forms.Textarea”.

Yes. But not out of the box afaik.

> I could also mod my account to look like I want it, but other users may wish 
> to have their account look different. Are settings local to a user? If not, 
> why?

Most functionality can be extended while using the Mezzanine framework. But for 
example the nifty client-facing tinymce content editing is only enabled if one 
has staff privileges, which you might not want to extend to all users. So you 
would need to modify those template tags for your own purposes.

As an aside: in general I strongly prefer to separate presentation from 
content. So as far as possible I try to keep the content with as little markup 
as possible, relying on templates etc to inject the html. That goal gets in the 
way of having users write their markup into their content, and having template 
layout and style filled in from db content. Past experience in porting a drupal 
site over to mezzanine, and trying to untangle the content from crazy embedded 
markup and from weird generic database structures, leads me to (try to) keep 
that content separate!

hth

- Tom



> thanks,
> 
> Brandon Keith Biggs
> On 4/22/2015 4:46 PM, Josh Cartmell wrote:
>> Hi Brandon, hopefully the following are helpful answers!
>> Title + the publishing controls are present across all things that inherit 
>> from the Displayable class where as the type of content on those various 
>> models will vary from class to class.  Blog Posts have categories and 
>> content, Rich Text Pages just have content, Links have no content, etc... 
>> All the admin classes of those models inherit from Displayable so they end 
>> up all having those things grouped.  Besides the technical reasons I think 
>> the consistency is useful and I find it nice to always be able to have the 
>> publishing controls right there.
>> The editor is a WYSIWYG, particularly one called TinyMCE.  Here's what they 
>> have to say about accessibility, 
>> http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe some or 
>> all of that isn't working?
>> You can change what is used though, for example in your project's 
>> settings.py file you could put:
>> RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>> Doing that should get rid of the WYSIWYG and those types of fields should 
>> just show up as normal HMTL textareas.  That would affect any admin user, 
>> not just yourself.
>> There isn't anything like that built in, there might be other projects that 
>> do things like that for Django that you could integrate with Mezzanine.
>> I don't think we have considered Brython but it should be easy to integrate 
>> any front end technology you want.  Right now Mezzanine ships with Twitter 
>> Bootstrap as a frontend framework and I think most people, myself included, 
>> are very happy with it.  But really, Mezzanine doesn't force front end 
>> technology on you, it just default to Twitter Bootstrap and you can change 
>> that easily by changing your project's base.html
>> Brython does look interesting though so I may have to take a look at it at 
>> some point!
>> Mezzanine does have some user account/profile support.  Here are the docs, 
>> http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine doesn't have 
>> any social login support but there are quite a few Django apps that do that 
>> which you could use to add that functionality
>> I tend to use https://www.digitalocean.com/ (VPS) or 
>> https://www.webfaction.com/ (shared host).  I've never used it on a cPanel 
>> host but you do need ssh access to a host to be able to deploy Mezzanine.
>> Mezzanine doesn't have plugins in the same sense as Wordpress.  You can't 
>> install anything through Mezzanine's admin interface other than possibly 
>> adding some Javascript to the content of pages.  Here is a list of modules 
>> that have been created for use with Mezzanine, 
>> http://mezzanine.jupo.org/docs/overview.html#third-party-modules but most if 
>> not all of them probably require modifying at a minimum your projects 
>> settings.py file
>> Here are a few more thoughts:
>> Mezzanine is Django so anything you can do with Django you can do in 
>> Mezzanine.  That means that when you look for modules you can cast a wider 
>> net than just looking for things that were specifically made for Mezzanine
>> The following is my opinion and I'm sure my bias towards Mezzanine will 
>> show.  Mezzanine and Wordpress have fundamentally different philosophies.  
>> Wordpress is more targeted at end users by making it easy to install plugins 
>> through the admin interface.  I tend to think that with a Wordpress site you 
>> could get 80% to 90% of the functionality you want with plugins but that 
>> last 10% may be very difficult.  Mezzanine on the other hand require

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Ken Bolton]

I think Josh's suggestion should work. You could save yourself some
headache by using the `choices` argument of CharField to limit the options
to the tinymce or forms.Textarea options.

-ken

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Josh Cartmell]

Ken makes a great point, I would definitely set choices to avoid typos
breaking things.

On Wed, Apr 22, 2015 at 12:08 PM, Ken Bolton  wrote:

> I think Josh's suggestion should work. You could save yourself some
> headache by using the `choices` argument of CharField to limit the options
> to the tinymce or forms.Textarea options.
>
> -ken
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Mezzanine Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mezzanine-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mezzanine-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
2 things:
1. setting the allowd markup to everything still produces something like
Hello world

and copying the line:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"

gives the following error:

ImproperlyConfigured at /admin/pages/richtextpage/9/
Could not import the value of settings.RICHTEXT_WIDGET_CLASS: forms.Textarea
Request Method:
GET
Request URL:
http://127.0.0.1:8000/admin/pages/richtextpage/9/
Django Version:
1.6.11
Exception Type:
ImproperlyConfigured
Exception Value:
Could not import the value of settings.RICHTEXT_WIDGET_CLASS: forms.Textarea

Thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all things that
inherit from the Displayable class where as the type of content on
those various models will vary from class to class.  Blog Posts
have categories and content, Rich Text Pages just have content,
Links have no content, etc... All the admin classes of those
models inherit from Displayable so they end up all having those
things grouped.  Besides the technical reasons I think the
consistency is useful and I find it nice to always be able to have
the publishing controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE. Here's
what they have to say about accessibility,
http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
some or all of that isn't working?
You can change what is used though, for example in your project's
settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of fields
should just show up as normal HMTL textareas.  That would affect
any admin user, not just yourself.
 3. There isn't anything like that built in, there might be other
projects that do things like that for Django that you could
integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be easy to
integrate any front end technology you want.  Right now Mezzanine
ships with Twitter Bootstrap as a frontend framework and I think
most people, myself included, are very happy with it.  But really,
Mezzanine doesn't force front end technology on you, it just
default to Twitter Bootstrap and you can change that easily by
changing your project's base.html
Brython does look interesting though so I may have to take a look
at it at some point!
 5. Mezzanine does have some user account/profile support. Here are
the docs, http://mezzanine.jupo.org/docs/user-accounts.html.
Mezzanine doesn't have any social login support but there are
quite a few Django apps that do that which you could use to add
that functionality
 6. I tend to use https://www.digitalocean.com/ (VPS) or
https://www.webfaction.com/ (shared host).  I've never used it on
a cPanel host but you do need ssh access to a host to be able to
deploy Mezzanine.
 7. Mezzanine doesn't have plugins in the same sense as Wordpress. 
You can't install anything through Mezzanine's admin interface

other than possibly adding some Javascript to the content of
pages.  Here is a list of modules that have been created for use
with Mezzanine,
http://mezzanine.jupo.org/docs/overview.html#third-party-modules
but most if not all of them probably require modifying at a
minimum your projects settings.py file

Here are a few more thoughts:

Mezzanine is Django so anything you can do with Django you can do in 
Mezzanine.  That means that when you look for modules you can cast a 
wider net than just looking for things that were specifically made for 
Mezzanine


The following is my opinion and I'm sure my bias towards Mezzanine 
will show.  Mezzanine and Wordpress have fundamentally different 
philosophies.  Wordpress is more targeted at end users by making it 
easy to install plugins through the admin interface.  I tend to think 
that with a Wordpress site you could get 80% to 90% of the 
functionality you want with plugins but that last 10% may be very 
difficult.  Mezzanine on the other hand requires you to either have a 
developer or know how to code yourself.  It doesn't try to be all 
things to all people but does provide a solid core feature set and 
makes it easy for a Django developer to add missing functionality.


Hopefully that helps.  Welcome to Mezzanine and please keep asking 
questions.  Good luck!



On Wed, Apr 22, 2015 at 6:10 AM, Brandon Keith Biggs 
mailto:brandonkeithbi...@gmail.com>> wrote:


Hello,
After spending 8 months with wordPress, I am throwing my hands up
and moving back to my home language python.
I saw mezzanine was probably the cms that would give me the least
problems, but I have some questions:
1. The edit page screen is really messy and difficult to navigate.
I am u

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Josh Cartmell]

Hi Brandon, I don't understand the first question.  What was the input and
what would you expect it to produce?

The widget probably needs to be updated to "django.forms.Textarea" I had
been thinking of something else when I omitted the django. previously.

On Mon, Apr 27, 2015 at 7:12 PM, Brandon Keith Biggs <
brandonkeithbi...@gmail.com> wrote:

>  Hello,
> 2 things:
> 1. setting the allowd markup to everything still produces something like
> Hello world
>
> and copying the line:
> RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>
> gives the following error:
>
> ImproperlyConfigured at /admin/pages/richtextpage/9/
> Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
> forms.Textarea
> Request Method:
> GET
> Request URL:
> http://127.0.0.1:8000/admin/pages/richtextpage/9/
> Django Version:
> 1.6.11
> Exception Type:
> ImproperlyConfigured
> Exception Value:
> Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
> forms.Textarea
>
> Thanks,
>
>  Brandon Keith Biggs 
> On 4/22/2015 4:46 PM, Josh Cartmell wrote:
>
> Hi Brandon, hopefully the following are helpful answers!
>
>1. Title + the publishing controls are present across all things that
>inherit from the Displayable class where as the type of content on those
>various models will vary from class to class.  Blog Posts have categories
>and content, Rich Text Pages just have content, Links have no content,
>etc... All the admin classes of those models inherit from Displayable so
>they end up all having those things grouped.  Besides the technical reasons
>I think the consistency is useful and I find it nice to always be able to
>have the publishing controls right there.
>2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's
>what they have to say about accessibility,
>http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
>some or all of that isn't working?
>You can change what is used though, for example in your project's
>settings.py file you could put:
>RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>Doing that should get rid of the WYSIWYG and those types of fields
>should just show up as normal HMTL textareas.  That would affect any admin
>user, not just yourself.
> 3. There isn't anything like that built in, there might be other
>projects that do things like that for Django that you could integrate with
>Mezzanine.
>4. I don't think we have considered Brython but it should be easy to
>integrate any front end technology you want.  Right now Mezzanine ships
>with Twitter Bootstrap as a frontend framework and I think most people,
>myself included, are very happy with it.  But really, Mezzanine doesn't
>force front end technology on you, it just default to Twitter Bootstrap and
>you can change that easily by changing your project's base.html
>Brython does look interesting though so I may have to take a look at
>it at some point!
> 5. Mezzanine does have some user account/profile support.  Here are
>the docs, http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine
>doesn't have any social login support but there are quite a few Django apps
>that do that which you could use to add that functionality
>6. I tend to use https://www.digitalocean.com/ (VPS) or
>https://www.webfaction.com/ (shared host).  I've never used it on a
>cPanel host but you do need ssh access to a host to be able to deploy
>Mezzanine.
>7. Mezzanine doesn't have plugins in the same sense as Wordpress.  You
>can't install anything through Mezzanine's admin interface other than
>possibly adding some Javascript to the content of pages.  Here is a list of
>modules that have been created for use with Mezzanine,
>http://mezzanine.jupo.org/docs/overview.html#third-party-modules but
>most if not all of them probably require modifying at a minimum your
>projects settings.py file
>
> Here are a few more thoughts:
>
> Mezzanine is Django so anything you can do with Django you can do in
> Mezzanine.  That means that when you look for modules you can cast a wider
> net than just looking for things that were specifically made for Mezzanine
>
> The following is my opinion and I'm sure my bias towards Mezzanine will
> show.  Mezzanine and Wordpress have fundamentally different philosophies.
> Wordpress is more targeted at end users by making it easy to install
> plugins through the admin interface.  I tend to think that with a Wordpress
> site you could get 80% to 90% of the functionality you want with plugins
> but that last 10% may be very difficult.  Mezzanine on the other hand
> requires you to either have a developer or know how to code yourself.  It
> doesn't try to be all things to all people but does provide a solid core
> feature set and makes it easy for a Django developer to add missing
> functionality.
>
> Hopefully that helps.  Welcome to Me

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
I think I figured out how to use the editor, you need to click on the 
html entry area in order to create HTML, then it makes little fields 
that are what you wrote.
Is there a place where I can edit how that add page looks like? I would 
like to add a heading at either the text that says:

Content:

or

Rich Text Area

Either that, or make it so when you press tab you are put into the text 
editor.
Currently I have to press 3 really weird key commands to move from the 
title to the text field. It is really not user friendly for me. (I have 
to press capslock+space to exit the forms area, x to move to the menu 
checkbox, then shift tab to get into the richtext area.)

Also, is there a key command to switch to the html editor within MCE?
I am having a weird problem that the insert link button is grayed out, 
so in order to add a link I have to go into the source and add the link. 
Does anyone know what may cause this?

Thanks,

Brandon Keith Biggs 
On 4/28/2015 5:31 PM, Josh Cartmell wrote:
Hi Brandon, I don't understand the first question.  What was the input 
and what would you expect it to produce?


The widget probably needs to be updated to "django.forms.Textarea" I 
had been thinking of something else when I omitted the django. previously.


On Mon, Apr 27, 2015 at 7:12 PM, Brandon Keith Biggs 
mailto:brandonkeithbi...@gmail.com>> wrote:


Hello,
2 things:
1. setting the allowd markup to everything still produces
something like
Hello world

and copying the line:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"

gives the following error:

ImproperlyConfigured at /admin/pages/richtextpage/9/
Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
forms.Textarea
Request Method:
GET
Request URL:
http://127.0.0.1:8000/admin/pages/richtextpage/9/
Django Version:
1.6.11
Exception Type:
ImproperlyConfigured
Exception Value:
Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
forms.Textarea

Thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all things
that inherit from the Displayable class where as the type of
content on those various models will vary from class to
class.  Blog Posts have categories and content, Rich Text
Pages just have content, Links have no content, etc... All
the admin classes of those models inherit from Displayable so
they end up all having those things grouped.  Besides the
technical reasons I think the consistency is useful and I
find it nice to always be able to have the publishing
controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE. 
Here's what they have to say about accessibility,

http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but
maybe some or all of that isn't working?
You can change what is used though, for example in your
project's settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of
fields should just show up as normal HMTL textareas.  That
would affect any admin user, not just yourself.
 3. There isn't anything like that built in, there might be other
projects that do things like that for Django that you could
integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be
easy to integrate any front end technology you want.  Right
now Mezzanine ships with Twitter Bootstrap as a frontend
framework and I think most people, myself included, are very
happy with it.  But really, Mezzanine doesn't force front end
technology on you, it just default to Twitter Bootstrap and
you can change that easily by changing your project's base.html
Brython does look interesting though so I may have to take a
look at it at some point!
 5. Mezzanine does have some user account/profile support.  Here
are the docs,
http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine
doesn't have any social login support but there are quite a
few Django apps that do that which you could use to add that
functionality
 6. I tend to use https://www.digitalocean.com/ (VPS) or
https://www.webfaction.com/ (shared host).  I've never used
it on a cPanel host but you do need ssh access to a host to
be able to deploy Mezzanine.
 7. Mezzanine doesn't have plugins in the same sense as
Wordpress.  You can't install anything through Mezzanine's
admin interface other than possibly adding some Javascript to
the content of p

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
I am reading the content architecture page and I am wondering where the 
.py files are supposed to be saved and how they interact with the HTML 
pages? I generally like to type out the examples given and then break 
them or change them.
I have no django experience, so should I go through their tutorial 
before going into mezzanine, or can I start with mezzanine then go into 
django if I wish?

Thanks,

Brandon Keith Biggs 
On 4/28/2015 7:28 PM, Brandon Keith Biggs wrote:

Hello,
I think I figured out how to use the editor, you need to click on the 
html entry area in order to create HTML, then it makes little fields 
that are what you wrote.
Is there a place where I can edit how that add page looks like? I 
would like to add a heading at either the text that says:

Content:

or

Rich Text Area

Either that, or make it so when you press tab you are put into the 
text editor.
Currently I have to press 3 really weird key commands to move from the 
title to the text field. It is really not user friendly for me. (I 
have to press capslock+space to exit the forms area, x to move to the 
menu checkbox, then shift tab to get into the richtext area.)

Also, is there a key command to switch to the html editor within MCE?
I am having a weird problem that the insert link button is grayed out, 
so in order to add a link I have to go into the source and add the 
link. Does anyone know what may cause this?

Thanks,

Brandon Keith Biggs 
On 4/28/2015 5:31 PM, Josh Cartmell wrote:
Hi Brandon, I don't understand the first question.  What was the 
input and what would you expect it to produce?


The widget probably needs to be updated to "django.forms.Textarea" I 
had been thinking of something else when I omitted the django. 
previously.


On Mon, Apr 27, 2015 at 7:12 PM, Brandon Keith Biggs 
mailto:brandonkeithbi...@gmail.com>> wrote:


Hello,
2 things:
1. setting the allowd markup to everything still produces
something like
Hello world

and copying the line:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"

gives the following error:

ImproperlyConfigured at /admin/pages/richtextpage/9/
Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
forms.Textarea
Request Method:
GET
Request URL:
http://127.0.0.1:8000/admin/pages/richtextpage/9/
Django Version:
1.6.11
Exception Type:
ImproperlyConfigured
Exception Value:
Could not import the value of settings.RICHTEXT_WIDGET_CLASS:
forms.Textarea

Thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all
things that inherit from the Displayable class where as the
type of content on those various models will vary from class
to class.  Blog Posts have categories and content, Rich Text
Pages just have content, Links have no content, etc... All
the admin classes of those models inherit from Displayable
so they end up all having those things grouped.  Besides the
technical reasons I think the consistency is useful and I
find it nice to always be able to have the publishing
controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE. 
Here's what they have to say about accessibility,

http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but
maybe some or all of that isn't working?
You can change what is used though, for example in your
project's settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of
fields should just show up as normal HMTL textareas.  That
would affect any admin user, not just yourself.
 3. There isn't anything like that built in, there might be
other projects that do things like that for Django that you
could integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be
easy to integrate any front end technology you want.  Right
now Mezzanine ships with Twitter Bootstrap as a frontend
framework and I think most people, myself included, are very
happy with it. But really, Mezzanine doesn't force front end
technology on you, it just default to Twitter Bootstrap and
you can change that easily by changing your project's base.html
Brython does look interesting though so I may have to take a
look at it at some point!
 5. Mezzanine does have some user account/profile support.  Here
are the docs,
http://mezzanine.jupo.org/docs/user-accounts.html. Mezzanine
doesn't have any social login support but there are quite a
few Django apps tha

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Asif Saifuddin]

You need to know django well in order to understand mezzanine development.

On Wednesday, April 29, 2015 at 12:07:42 AM UTC+6, Brandon Keith Biggs 
wrote:
>
>  Hello,
> I am reading the content architecture page and I am wondering where the 
> .py files are supposed to be saved and how they interact with the HTML 
> pages? I generally like to type out the examples given and then break them 
> or change them.
> I have no django experience, so should I go through their tutorial before 
> going into mezzanine, or can I start with mezzanine then go into django if 
> I wish?
> Thanks,
>
>  Brandon Keith Biggs 
> On 4/28/2015 7:28 PM, Brandon Keith Biggs wrote:
>  
> Hello,
> I think I figured out how to use the editor, you need to click on the html 
> entry area in order to create HTML, then it makes little fields that are 
> what you wrote.
> Is there a place where I can edit how that add page looks like? I would 
> like to add a heading at either the text that says:
> Content:
>
> or
>
> Rich Text Area
>
> Either that, or make it so when you press tab you are put into the text 
> editor.
> Currently I have to press 3 really weird key commands to move from the 
> title to the text field. It is really not user friendly for me. (I have to 
> press capslock+space to exit the forms area, x to move to the menu 
> checkbox, then shift tab to get into the richtext area.)
> Also, is there a key command to switch to the html editor within MCE?
> I am having a weird problem that the insert link button is grayed out, so 
> in order to add a link I have to go into the source and add the link. Does 
> anyone know what may cause this?
> Thanks,
>
>  Brandon Keith Biggs 
> On 4/28/2015 5:31 PM, Josh Cartmell wrote:
>  
>  Hi Brandon, I don't understand the first question.  What was the input 
> and what would you expect it to produce?
>
>  The widget probably needs to be updated to "django.forms.Textarea" I had 
> been thinking of something else when I omitted the django. previously.
>  
> On Mon, Apr 27, 2015 at 7:12 PM, Brandon Keith Biggs <
> brandonk...@gmail.com > wrote:
>
>>  Hello,
>> 2 things:
>> 1. setting the allowd markup to everything still produces something like
>> Hello world
>>
>> and copying the line:
>> RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>>
>> gives the following error:
>>
>> ImproperlyConfigured at /admin/pages/richtextpage/9/
>> Could not import the value of settings.RICHTEXT_WIDGET_CLASS: 
>> forms.Textarea
>> Request Method:
>> GET
>> Request URL:
>> http://127.0.0.1:8000/admin/pages/richtextpage/9/
>> Django Version:
>> 1.6.11
>> Exception Type:
>> ImproperlyConfigured
>> Exception Value:
>> Could not import the value of settings.RICHTEXT_WIDGET_CLASS: 
>> forms.Textarea
>>
>> Thanks,
>>
>>  Brandon Keith Biggs 
>> On 4/22/2015 4:46 PM, Josh Cartmell wrote:
>>   
>> Hi Brandon, hopefully the following are helpful answers!
>>
>>1. Title + the publishing controls are present across all things that 
>>inherit from the Displayable class where as the type of content on those 
>>various models will vary from class to class.  Blog Posts have categories 
>>and content, Rich Text Pages just have content, Links have no content, 
>>etc... All the admin classes of those models inherit from Displayable so 
>>they end up all having those things grouped.  Besides the technical 
>> reasons 
>>I think the consistency is useful and I find it nice to always be able to 
>>have the publishing controls right there. 
>>2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's 
>>what they have to say about accessibility, 
>>http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe 
>>some or all of that isn't working?
>>You can change what is used though, for example in your project's 
>>settings.py file you could put:
>>RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>>Doing that should get rid of the WYSIWYG and those types of fields 
>>should just show up as normal HMTL textareas.  That would affect any 
>> admin 
>>user, not just yourself.
>> 3. There isn't anything like that built in, there might be other 
>>projects that do things like that for Django that you could integrate 
>> with 
>>Mezzanine. 
>>4. I don't think we have considered Brython but it should be easy to 
>>integrate any front end technology you want.  Right now Mezzanine ships 
>>with Twitter Bootstrap as a frontend framework and I think most people, 
>>myself included, are very happy with it.  But really, Mezzanine doesn't 
>>force front end technology on you, it just default to Twitter Bootstrap 
>> and 
>>you can change that easily by changing your project's base.html
>>Brython does look interesting though so I may have to take a look at 
>>it at some point!
>> 5. Mezzanine does have some user account/profile s

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
I have been looking around the web, comparing different python CMSes 
with Mezzanine and I keep coming back here. I am wondering why mezzanine 
does not implement functionality for non developers to use it out of the 
box?
So for example, I have my website on wordPress and would like to migrate 
it to mezzanine. I know python, but not django. In order for me to move 
my site to mezzanine and make it look like I want, I need to both modify 
the CSS file, the template files, learn django so I can display some 
variables that I have on my front-page and figure out how to deploy 
mezzanine on a server.
After I get my website up and running I want to learn django and start 
building apps.
Granted, mezzanine has a much easier entry than any other python CMS I 
found, but I think it could and should be a little easier. After all, 
there is a huge audience of people who know basic python and would 
really like to use a python CMS, but don't want to learn django or a 
complex templating language to create a good looking website.
For example, why does it take 5 commands to run? (granted 5 is really 
good as most other places take 10+), but mezzanine-project myproject 
could totally make the db, setup the user and ask if you would like to 
run the server. (possibly a -s or -b could setup the server for 
server-side development and -b could set the folder like it is now).
I have not yet deployed it on a server yet, so can't say how difficult 
it is, but it would be really awesome if mezzanine either did what 
wordPress.com does or give a really easy (no more than 10 step) tutorial 
on how to install mezzanine on something like Python Anywhere.
Also, why does mezzanine not have a content folder with subfolders of 
plugins, themes, apps and the default templates? I think it would be 
super easy to make and would promote well-organized site structure.


I know that mezzanine is built for developers, but so is python. I think 
that mezzanine could totally remain super developer friendly while also 
being non programmer and basic python programmer friendly.


These are just a few thoughts from someone who is just coming into 
mezzanine never having developed for the web in python before. (Other 
than brython :)). I really would like to tell people to use mezzanine 
rather than wordPress because learning how to script in python is just 
so much easier than learning how to script in PHP, but currently it is 
too complex.
I am learning django and hopefully I can either make a separate CMS 
based off mezzanine or help mezzanine to become novice friendly.

Thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all things that
inherit from the Displayable class where as the type of content on
those various models will vary from class to class.  Blog Posts
have categories and content, Rich Text Pages just have content,
Links have no content, etc... All the admin classes of those
models inherit from Displayable so they end up all having those
things grouped.  Besides the technical reasons I think the
consistency is useful and I find it nice to always be able to have
the publishing controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE. Here's
what they have to say about accessibility,
http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
some or all of that isn't working?
You can change what is used though, for example in your project's
settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of fields
should just show up as normal HMTL textareas.  That would affect
any admin user, not just yourself.
 3. There isn't anything like that built in, there might be other
projects that do things like that for Django that you could
integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be easy to
integrate any front end technology you want.  Right now Mezzanine
ships with Twitter Bootstrap as a frontend framework and I think
most people, myself included, are very happy with it.  But really,
Mezzanine doesn't force front end technology on you, it just
default to Twitter Bootstrap and you can change that easily by
changing your project's base.html
Brython does look interesting though so I may have to take a look
at it at some point!
 5. Mezzanine does have some user account/profile support. Here are
the docs, http://mezzanine.jupo.org/docs/user-accounts.html.
Mezzanine doesn't have any social login support but there are
quite a few Django apps that do that which you could use to add
that functionality
 6. I tend to use https://www.digitalocean.com/ (VPS) or
https://www.webfaction.com/ (shared host).  I

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Ken Bolton]

Hi Brandon,

I hear your frustration. I encourage you to stick with it. Get through the
excellent official Django tutorial. I have observed individuals of wildly
varying skill levels and backgrounds use Mezzanine to great effect. The key
that unlocks Mezzanine is always Django.

There was talk recently on this list about a WordPress.com clone based on
Mezzanine. I hope someone does it and sees wild success.

Keep in mind that Mezzanine was built by developers who needed a powerful,
consistent, and flexible platform on which to build bigger projects.
Mezzanine is for developers, without apology. The first parts of the
documentation make it clear that a knowledge of Django is required and that
the target audience are front- and back-end developers and systems
administrators.

Finally: Until I deploy, I have nothing. So the first task is always to
deploy. A successful running deployment – even to a local VM – is the *mis
en place* of software development.

- ken

On Wed, Apr 29, 2015 at 2:52 PM, Brandon Keith Biggs <
brandonkeithbi...@gmail.com> wrote:

>  Hello,
> I have been looking around the web, comparing different python CMSes with
> Mezzanine and I keep coming back here. I am wondering why mezzanine does
> not implement functionality for non developers to use it out of the box?
> So for example, I have my website on wordPress and would like to migrate
> it to mezzanine. I know python, but not django. In order for me to move my
> site to mezzanine and make it look like I want, I need to both modify the
> CSS file, the template files, learn django so I can display some variables
> that I have on my front-page and figure out how to deploy mezzanine on a
> server.
> After I get my website up and running I want to learn django and start
> building apps.
> Granted, mezzanine has a much easier entry than any other python CMS I
> found, but I think it could and should be a little easier. After all, there
> is a huge audience of people who know basic python and would really like to
> use a python CMS, but don't want to learn django or a complex templating
> language to create a good looking website.
> For example, why does it take 5 commands to run? (granted 5 is really good
> as most other places take 10+), but mezzanine-project myproject could
> totally make the db, setup the user and ask if you would like to run the
> server. (possibly a -s or -b could setup the server for server-side
> development and -b could set the folder like it is now).
> I have not yet deployed it on a server yet, so can't say how difficult it
> is, but it would be really awesome if mezzanine either did what
> wordPress.com does or give a really easy (no more than 10 step) tutorial on
> how to install mezzanine on something like Python Anywhere.
> Also, why does mezzanine not have a content folder with subfolders of
> plugins, themes, apps and the default templates? I think it would be super
> easy to make and would promote well-organized site structure.
>
> I know that mezzanine is built for developers, but so is python. I think
> that mezzanine could totally remain super developer friendly while also
> being non programmer and basic python programmer friendly.
>
> These are just a few thoughts from someone who is just coming into
> mezzanine never having developed for the web in python before. (Other than
> brython :)). I really would like to tell people to use mezzanine rather
> than wordPress because learning how to script in python is just so much
> easier than learning how to script in PHP, but currently it is too complex.
> I am learning django and hopefully I can either make a separate CMS based
> off mezzanine or help mezzanine to become novice friendly.
> Thanks,
>
>  Brandon Keith Biggs 
> On 4/22/2015 4:46 PM, Josh Cartmell wrote:
>
> Hi Brandon, hopefully the following are helpful answers!
>
>1. Title + the publishing controls are present across all things that
>inherit from the Displayable class where as the type of content on those
>various models will vary from class to class.  Blog Posts have categories
>and content, Rich Text Pages just have content, Links have no content,
>etc... All the admin classes of those models inherit from Displayable so
>they end up all having those things grouped.  Besides the technical reasons
>I think the consistency is useful and I find it nice to always be able to
>have the publishing controls right there.
>2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's
>what they have to say about accessibility,
>http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but maybe
>some or all of that isn't working?
>You can change what is used though, for example in your project's
>settings.py file you could put:
>RICHTEXT_WIDGET_CLASS = "forms.Textarea"
>Doing that should get rid of the WYSIWYG and those types of fields
>should just show up as normal HMTL textareas.  That would a

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Graham]

Hi Brandon
Helping Mezzanine become novice friendly would be great I think.
There are 3 articles written by Ross Laird that I have consistently 
found really useful...


1. http://www.rosslaird.com/blog/first-steps-with-mezzanine/
2. http://www.rosslaird.com/blog/building-a-project-with-mezzanine/
3. http://www.rosslaird.com/blog/customizing-mezzanine/

In terms of why Mezzanine is designed the way it is, well that is a big 
question.  I have listened to this video 
http://blog.jupo.org/2014/08/21/pycon-apac-keynote-mezzanine/ a few 
times where Stephen McDonald talks about Mezzanine. It could be useful 
to give you a background as to where Mezzanine came from. I have heard 
that Vimeo may not be super accessible. Let me know if you have problems 
accessing the video...


Take Care
Graham

On 30/04/15 06:52, Brandon Keith Biggs wrote:

Hello,
I have been looking around the web, comparing different python CMSes 
with Mezzanine and I keep coming back here. I am wondering why 
mezzanine does not implement functionality for non developers to use 
it out of the box?
So for example, I have my website on wordPress and would like to 
migrate it to mezzanine. I know python, but not django. In order for 
me to move my site to mezzanine and make it look like I want, I need 
to both modify the CSS file, the template files, learn django so I can 
display some variables that I have on my front-page and figure out how 
to deploy mezzanine on a server.
After I get my website up and running I want to learn django and start 
building apps.
Granted, mezzanine has a much easier entry than any other python CMS I 
found, but I think it could and should be a little easier. After all, 
there is a huge audience of people who know basic python and would 
really like to use a python CMS, but don't want to learn django or a 
complex templating language to create a good looking website.
For example, why does it take 5 commands to run? (granted 5 is really 
good as most other places take 10+), but mezzanine-project myproject 
could totally make the db, setup the user and ask if you would like to 
run the server. (possibly a -s or -b could setup the server for 
server-side development and -b could set the folder like it is now).
I have not yet deployed it on a server yet, so can't say how difficult 
it is, but it would be really awesome if mezzanine either did what 
wordPress.com does or give a really easy (no more than 10 step) 
tutorial on how to install mezzanine on something like Python Anywhere.
Also, why does mezzanine not have a content folder with subfolders of 
plugins, themes, apps and the default templates? I think it would be 
super easy to make and would promote well-organized site structure.


I know that mezzanine is built for developers, but so is python. I 
think that mezzanine could totally remain super developer friendly 
while also being non programmer and basic python programmer friendly.


These are just a few thoughts from someone who is just coming into 
mezzanine never having developed for the web in python before. (Other 
than brython :)). I really would like to tell people to use mezzanine 
rather than wordPress because learning how to script in python is just 
so much easier than learning how to script in PHP, but currently it is 
too complex.
I am learning django and hopefully I can either make a separate CMS 
based off mezzanine or help mezzanine to become novice friendly.

Thanks,

Brandon Keith Biggs 
On 4/22/2015 4:46 PM, Josh Cartmell wrote:

Hi Brandon, hopefully the following are helpful answers!

 1. Title + the publishing controls are present across all things
that inherit from the Displayable class where as the type of
content on those various models will vary from class to class. 
Blog Posts have categories and content, Rich Text Pages just have

content, Links have no content, etc... All the admin classes of
those models inherit from Displayable so they end up all having
those things grouped.  Besides the technical reasons I think the
consistency is useful and I find it nice to always be able to
have the publishing controls right there.
 2. The editor is a WYSIWYG, particularly one called TinyMCE.  Here's
what they have to say about accessibility,
http://www.tinymce.com/wiki.php/TinyMCE3x:Accessibility, but
maybe some or all of that isn't working?
You can change what is used though, for example in your project's
settings.py file you could put:
RICHTEXT_WIDGET_CLASS = "forms.Textarea"
Doing that should get rid of the WYSIWYG and those types of
fields should just show up as normal HMTL textareas. That would
affect any admin user, not just yourself.
 3. There isn't anything like that built in, there might be other
projects that do things like that for Django that you could
integrate with Mezzanine.
 4. I don't think we have considered Brython but it should be easy to
integrate any fron

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Luke Plant]

Hi Brandon, Keith,

I think Keith is referring to the thread I started earlier about a 
service that would provide a very easy way to install Mezzanine.


Like you Brandon, I'd love to be able to recommend a Django-based 
alternative to WordPress. It seems that there isn't a solution like this 
yet. There is a real question in my mind about whether non-developers 
can really produce good quality web sites without learning quite a bit 
about coding. All of the approaches I know have serious problems:


1) The WordPress approach:

The biggest problem is security. WordPress themes and plugins are just 
PHP code. The system  suffers terribly in terms of security because of 
that. A WordPress site inherits all of the security problems that PHP has:


https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

In addition, WordPress adds it's own:

 * 'convenient' SQL APIs that makes SQL injection vulnerabilities
   extremely likely.
 * use of PHP as template language, which makes XSS very likely,
 * complete lack of proper structure in request handling, which makes
   access permission vulnerabilities very likely.
 * Ability to edit the PHP templates, which means that admin access to
   a WordPress site (e.g. through a guessed password) immediately
   elevates to a remote execution vulnerability - the most serious kind.

I recently evaluated the practicality of using WordPress as a cheap 
replacement for our current church website. I found a professional 
looking plugin that would actually do our "sermon MP3" page, and so 
analysed the code. Within an hour I had found dozens of XSS 
vulnerabilities, and a bug that allowed *any* user (completely 
unauthenticated) to delete any file on the server.


In other words, in terms of structure, WordPress provides a free-for-all 
that guarantees a security mess. The situation is terrible, and we all 
know WordPress sites that have been hacked as a result. This is really 
not something you want non-technical people to be dealing with.


And even if you don't get hacked, you are still end up with something 
that is a nightmare to maintain - all the different plugins and themes 
are just cobbled together, and once you start upgrading things, you can 
expect a mess.


2) "Website builders"

e.g. http://www.wix.com/
http://www.weebly.com/
http://squarespace.com/

This is the other end of the spectrum. You get a fairly locked down 
system, in which you must choose a template, with some controls for 
customisation, and add your own pages. There might be an "apps market" 
if you want to add custom server-side logic, but that's probably your 
only option.


There are lots of downsides:

 * Quite limited in what you can do
 * Often badly optimised for mobile
 * Once you have more than a few pages, managing them all and keeping
   them consistent gets hard
 * You are locked into their platform

If their templates and functionality suit your needs, they are great, 
but you can hit a limit fairly quickly.


3) Designer oriented sites

For example https://webflow.com/

These can help web designers build good looking sites. You get a good 
level of control over HTML/CSS, but when it comes to CMS features I 
think they are lacking, and custom server-side logic is again going to 
be a problem. The idea is that designers "hand off" their code to a 
developer at that point.


And that is the point at where something like Mezzanine comes in, which 
aims at the people who have 1) found the above three solutions 
inadequate for their needs, and 2) are technical enough to handle the 
alternative, or are happy to pay someone else who does have those skills 
e.g. an agency that builds custom web sites for people.


It also aims to be "just Django", which gives you the flexibility of 
building a lot more than just a blog. But this flexibility means that it 
cannot be totally opinionated about what it does, and therefore cannot 
do everything for you.



I don't know if some "middle ground" between the alternatives is even 
theoretically possible. It is precisely the flexibility of WordPress in 
terms of installing arbitrary code that gives it the power it needs, and 
makes it a nightmare. Complete flexibility also means it's going to be 
very hard to create responsive (mobile optimised) sites, and that is 
more and more of a minimum requirement today.


I have been toying with the idea of a building a service that would help 
you get a Mezzanine instance up and running, and would manage it 
entirely for you, including providing a set of themes you can choose 
from. There are some challenges in doing that - the Mezzanine themes 
that are available basically assume that you are going to edit them with 
a text editor at some point, rather than be installable in a 
point-and-click way.


My ideal implementation of this would allow users to cut themselves 
loose when they outgrow the system, and at that point have a Django app 
that would be implemented using best practices, would have instructions 
ab

Re: [mezzanine-users] Some newbie questions for someone moving from WP to mezzanine

[Brandon Keith Biggs]

Hello,
Then there are the folks who know programming, but don't know python or 
django or if they do, don't know the strange stuff that has to do with 
web development. Either that or they don't know any html above .
What I was thinking is getting a reseller account at A2 hosting or 
something like that and have a full mezzanine setup for each new person.
Then offer an installer or something for new themes. This shouldn't be 
too difficult, just offer an upload screen where you can select your 
theme and once it is uploaded, you can activate it. (activating would 
basically just be changing the settings.py file.)

That way people could use the current themes.
Of coarse they would get FTP access, but the point is to limit FTP 
access, so you don't need to deal with anything but the front-end.
Then for super-users there could be a page where you could enter python 
code and add it to something like short-codes. For example, I have on my 
website a short-code in wordPress to display my age. It changes every 
year so I don't need to update my age every year. So it looks like:


Brandon Keith Biggs is a [age name="brandon"] year old singer, 
programmer and avid book-lover.


and it comes out as:

Brandon Keith Biggs is a 23 year old singer, programmer and avid book-lover.

In wordPress you make a function in functions.php and add it to the 
short-code list. I was thinking this could be nearly the same in 
mezzanine, but you could modify the functions.py file only if you are 
super-user.


I, for example, would love a setup like that. I really don't mind what 
theme I have, but I would like to be able to place variables or 
references to HTML blocks different places.


The reason why I am looking for a CMS other than WP is because I am 
trying to create a website that is a little more advanced than what I 
need for my personal website. I would like to make my personal website 
in mezzanine though.


I would like also to tell people to get a mezzanine hosted website as 
then I can help them if they need. Also, making plugins in django is way 
easier than in PHP...


Having an already setup mezzanine site on a person's new hosting account 
would make it so they just need to worry about learning how the CMS 
works and possibly django.


What would be the downside to something like this?
I have never worked for anyone who really tried to muck around with 
anything they weren't supposed to and generally if you mess up your 
website it is kind of your fault. There is always the back-up... Or you 
can pay me to fix it.
I am not sure about mezzanine, but in wordPress there is a way to 
separate users out to have different permissions. This group of users 
can add blog posts and that is it. These users can add pages under this 
category and that is it, these users can make products, add pages and 
blog posts, These users can add themes, plugins, pages, products and 
blog posts, these users can add or remove users below them, add themes, 
plugins...


So perhaps there could be superadmin and that has access to the script 
file, changing themes and whatnot, then normaladmin could add or remove 
accounts, add pages and menus and basically everything not code or theme 
related.


So it is, I believe, something like
https://webflow.com/
just in mezzanine and the ability to learn django if you wish.

Is there a problem with something like this?
thanks,

Brandon Keith Biggs 
On 5/1/2015 2:55 PM, Luke Plant wrote:

Hi Brandon, Keith,

I think Keith is referring to the thread I started earlier about a 
service that would provide a very easy way to install Mezzanine.


Like you Brandon, I'd love to be able to recommend a Django-based 
alternative to WordPress. It seems that there isn't a solution like 
this yet. There is a real question in my mind about whether 
non-developers can really produce good quality web sites without 
learning quite a bit about coding. All of the approaches I know have 
serious problems:


1) The WordPress approach:

The biggest problem is security. WordPress themes and plugins are just 
PHP code. The system  suffers terribly in terms of security because of 
that. A WordPress site inherits all of the security problems that PHP has:


https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

In addition, WordPress adds it's own:

  * 'convenient' SQL APIs that makes SQL injection vulnerabilities
extremely likely.
  * use of PHP as template language, which makes XSS very likely,
  * complete lack of proper structure in request handling, which makes
access permission vulnerabilities very likely.
  * Ability to edit the PHP templates, which means that admin access
to a WordPress site (e.g. through a guessed password) immediately
elevates to a remote execution vulnerability - the most serious kind.

I recently evaluated the practicality of using WordPress as a cheap 
replacement for our current church website. I found a professional 
looking plugin that would