Re: [mezzanine-users] Missing pages after Mezzanine-Cartridg Deployme using Fabric - About/Blog/Category/Contact/Products

[vikraw]

Thanks Kenneth for your reply. You understood the issue correctly. Yes, I 
am running Postgre locally. So if i understand correctly, here are my 
options
1- extend fabfile + add some keys to the settings.FABRIC
2- manually do a local backup and then run a restore on target deployment

Option 2 looks easier to me at this moment. last night i tried running 
pg_restore on aws and was getting some "peer authentication" error which 
seems like some .conf/user accounts issue. 

However in future i would like to just run '*fab deploy*'. I am new to all 
these technologies and would appreciate if you could elaborate little more 
on *option 1* .

thanks
vikram

On Thursday, December 11, 2014 12:09:21 AM UTC+5:30, Kenneth Bolton wrote:
>
> Hi Vikram,
>
> To restate your problem, you built a local cartridge instance and ran 
> django's runserver against a local database. After deploying to AWS using 
> `fab all` and an appropriately configured settings.FABRIC dictionary, you 
> see none of the pages you added in your local instance.
>
> The fabfile that ships with Mezzanine does not move databases between 
> deployment targets. If you are using PostgreSQL locally, the fabfile can be 
> extended to do the dump for you. You will need to add some additional keys 
> to settings.FABRIC for the local database that is to be backed up.
>
> hth,
> ken
>
> https://groups.google.com/forum/#!topic/mezzanine-users/X_Xs-Ei0OVw
>
>
>
> On Wed, Dec 10, 2014 at 11:52 AM, vikraw > 
> wrote:
>
>> Hi 
>>
>> I have been working on Mezzanine-Cartridge development for a few weeks on 
>> my local development machine. 
>>
>> Now I deployed to a Ubuntu AMI on Amazon webservices using the default - 
>> Fabric.py script and 'fab all' command.
>>
>> However the following links are missing on the deployed site. 
>> - About
>> - Blog
>> - Category
>> - Contact
>> - Shop Products
>>
>> *Also I cannot see any additional products or added pages on deployed 
>> website. 
>>
>> Attached is a pic of my the default DEPLOYED  site
>>
>>
>> 
>>
>>
>> Attached is a pic of my the default DEVELOPMENT LOCAL site
>>
>>
>> 
>>
>>
>>
>>
>> HOWEVER, I can see the above mentioned links in the development 
>> environment which is also on Ubuntu.
>>
>>
>> Development environment is as follows - pip freeze o/p - using virtualenv
>> Cartridge==0.9.5
>> Django==1.6.8
>> Fabric==1.10.0
>> Mezzanine==3.1.10
>> Pillow==2.6.1
>> South==1.0.1
>> argparse==1.2.1
>> beautifulsoup4==4.1.3
>> bleach==1.4
>> boto==2.34.0
>> django-appconf==0.6
>> django-compressor==1.4
>> django-ses==0.7.0
>> ecdsa==0.11
>> filebrowser-safe==0.3.6
>> future==0.9.0
>> grappelli-safe==0.3.13
>> html5lib==0.999
>> mezzanine-bsbanners==0.1.4
>> oauthlib==0.7.2
>> paramiko==1.15.1
>> psycopg2==2.5.4
>> pycrypto==2.6.1
>> pytz==2014.10
>> reportlab==3.1.8
>> requests==2.4.3
>> requests-oauthlib==0.4.2
>> six==1.8.0
>> tzlocal==1.0
>> wsgiref==0.1.2
>> xhtml2pdf==0.0.6
>>
>>
>> I was expecting that one's development is finalized and uploaded to the 
>> repository, FABRIC will automatically create a similar snapshot in 
>> production server. 
>>
>> What should I do to get all my products and additional pages to come up 
>> on deployed site?? I read somewhere that fabric doesn't syncs the database 
>> even though it syncs the schema. So i am guessing if that is the issue?
>> My excitement of development on Mezzanine-Cartridge is fading as 
>> deployment is very tedious.
>>
>> I follow the following process
>> - virtualenv
>> - debug=true
>> - collectstatic
>> - git add *, git commit , 
>> - fab all
>>
>> I  would appreciate the help
>>
>>
>>  -- 
>> 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-use...@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.

[mezzanine-users] Re: Using recaptcha with mezzanine

[cyclebelfast]

On 10/12/14 16:34, Amber Grimaldi wrote:



On Tuesday, December 9, 2014 8:20:07 PM UTC-7, gmflanagan wrote:

On 09/12/14 21:51, Amber Grimaldi wrote:
 > Hey! I'm trying to use recaptcha with the registration form to
stop bots
 > from signing up on the site. I got recaptcha to work using
 > django-recaptcha package and it's present in the template but not
sure
 > how to actually integrate it into the form because currently you can
 > still register without getting the recaptcha verification. Any
 > suggestions other than c/p mezzanine's accounts app and customizing?
 >


Here's an example using django-simple-captcha:


https://github.com/averagehuman/mezzanine-invites/blob/master/invites/forms.py




I imagine recaptcha would look similar.


The problem with the above is I would have to edit mezzanine's
accounts/forms.py to utilize. Is that what you suggest or am I missing
something?



Sorry, I should have added that you would also need to add this setting:

ACCOUNTS_PROFILE_FORM_CLASS = ".forms.ProfileForm"

to your settings file (or similar). ProfileForm in the above example  is 
a factory function rather than a class, but Mezzanine only expects that 
your ACCOUNTS_PROFILE_FORM_CLASS value is callable.


But in any case, no, you certainly don't need to edit any mezzanine 
code. This is definitely a solvable problem without forking mezzanine. 
If you are still not getting anywhere, perhaps post a minimal setup - 
settings + urls + views + forms - and we can try and reproduce.


Gerard







--
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] Missing pages after Mezzanine-Cartridg Deployme using Fabric - About/Blog/Category/Contact/Products

[Ken Bolton]

Hi Vikram,

To restate your problem, you built a local cartridge instance and ran
django's runserver against a local database. After deploying to AWS using
`fab all` and an appropriately configured settings.FABRIC dictionary, you
see none of the pages you added in your local instance.

The fabfile that ships with Mezzanine does not move databases between
deployment targets. If you are using PostgreSQL locally, the fabfile can be
extended to do the dump for you. You will need to add some additional keys
to settings.FABRIC for the local database that is to be backed up.

hth,
ken

https://groups.google.com/forum/#!topic/mezzanine-users/X_Xs-Ei0OVw



On Wed, Dec 10, 2014 at 11:52 AM, vikraw  wrote:

> Hi
>
> I have been working on Mezzanine-Cartridge development for a few weeks on
> my local development machine.
>
> Now I deployed to a Ubuntu AMI on Amazon webservices using the default -
> Fabric.py script and 'fab all' command.
>
> However the following links are missing on the deployed site.
> - About
> - Blog
> - Category
> - Contact
> - Shop Products
>
> *Also I cannot see any additional products or added pages on deployed
> website.
>
> Attached is a pic of my the default DEPLOYED  site
>
>
> 
>
>
> Attached is a pic of my the default DEVELOPMENT LOCAL site
>
>
> 
>
>
>
>
> HOWEVER, I can see the above mentioned links in the development
> environment which is also on Ubuntu.
>
>
> Development environment is as follows - pip freeze o/p - using virtualenv
> Cartridge==0.9.5
> Django==1.6.8
> Fabric==1.10.0
> Mezzanine==3.1.10
> Pillow==2.6.1
> South==1.0.1
> argparse==1.2.1
> beautifulsoup4==4.1.3
> bleach==1.4
> boto==2.34.0
> django-appconf==0.6
> django-compressor==1.4
> django-ses==0.7.0
> ecdsa==0.11
> filebrowser-safe==0.3.6
> future==0.9.0
> grappelli-safe==0.3.13
> html5lib==0.999
> mezzanine-bsbanners==0.1.4
> oauthlib==0.7.2
> paramiko==1.15.1
> psycopg2==2.5.4
> pycrypto==2.6.1
> pytz==2014.10
> reportlab==3.1.8
> requests==2.4.3
> requests-oauthlib==0.4.2
> six==1.8.0
> tzlocal==1.0
> wsgiref==0.1.2
> xhtml2pdf==0.0.6
>
>
> I was expecting that one's development is finalized and uploaded to the
> repository, FABRIC will automatically create a similar snapshot in
> production server.
>
> What should I do to get all my products and additional pages to come up on
> deployed site?? I read somewhere that fabric doesn't syncs the database
> even though it syncs the schema. So i am guessing if that is the issue?
> My excitement of development on Mezzanine-Cartridge is fading as
> deployment is very tedious.
>
> I follow the following process
> - virtualenv
> - debug=true
> - collectstatic
> - git add *, git commit ,
> - fab all
>
> I  would appreciate the help
>
>
>  --
> 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.

[mezzanine-users] Missing pages after Mezzanine-Cartridg Deployme using Fabric - About/Blog/Category/Contact/Products

[vikraw]

Hi 

I have been working on Mezzanine-Cartridge development for a few weeks on 
my local development machine. 

Now I deployed to a Ubuntu AMI on Amazon webservices using the default - 
Fabric.py script and 'fab all' command.

However the following links are missing on the deployed site. 
- About
- Blog
- Category
- Contact
- Shop Products

*Also I cannot see any additional products or added pages on deployed 
website. 

Attached is a pic of my the default DEPLOYED  site




Attached is a pic of my the default DEVELOPMENT LOCAL site






HOWEVER, I can see the above mentioned links in the development environment 
which is also on Ubuntu.


Development environment is as follows - pip freeze o/p - using virtualenv
Cartridge==0.9.5
Django==1.6.8
Fabric==1.10.0
Mezzanine==3.1.10
Pillow==2.6.1
South==1.0.1
argparse==1.2.1
beautifulsoup4==4.1.3
bleach==1.4
boto==2.34.0
django-appconf==0.6
django-compressor==1.4
django-ses==0.7.0
ecdsa==0.11
filebrowser-safe==0.3.6
future==0.9.0
grappelli-safe==0.3.13
html5lib==0.999
mezzanine-bsbanners==0.1.4
oauthlib==0.7.2
paramiko==1.15.1
psycopg2==2.5.4
pycrypto==2.6.1
pytz==2014.10
reportlab==3.1.8
requests==2.4.3
requests-oauthlib==0.4.2
six==1.8.0
tzlocal==1.0
wsgiref==0.1.2
xhtml2pdf==0.0.6


I was expecting that one's development is finalized and uploaded to the 
repository, FABRIC will automatically create a similar snapshot in 
production server. 

What should I do to get all my products and additional pages to come up on 
deployed site?? I read somewhere that fabric doesn't syncs the database 
even though it syncs the schema. So i am guessing if that is the issue?
My excitement of development on Mezzanine-Cartridge is fading as deployment 
is very tedious.

I follow the following process
- virtualenv
- debug=true
- collectstatic
- git add *, git commit , 
- fab all

I  would appreciate the help


-- 
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.

[mezzanine-users] Re: Using recaptcha with mezzanine

[Amber Grimaldi]

On Tuesday, December 9, 2014 8:20:07 PM UTC-7, gmflanagan wrote:
>
> On 09/12/14 21:51, Amber Grimaldi wrote: 
> > Hey! I'm trying to use recaptcha with the registration form to stop bots 
> > from signing up on the site. I got recaptcha to work using 
> > django-recaptcha package and it's present in the template but not sure 
> > how to actually integrate it into the form because currently you can 
> > still register without getting the recaptcha verification. Any 
> > suggestions other than c/p mezzanine's accounts app and customizing? 
> > 
>
>
> Here's an example using django-simple-captcha: 
>
>
> https://github.com/averagehuman/mezzanine-invites/blob/master/invites/forms.py
>  
>
> I imagine recaptcha would look similar. 
>
>
The problem with the above is I would have to edit mezzanine's 
accounts/forms.py to utilize. Is that what you suggest or am I missing 
something? 

-- 
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] ACCOUNTS_PROFILE_FORM_CLASS doen't appear to be having any influence.

[paul thomas]

Nope it was my own stupidity there is nothing wrong with the class.

The the guicorn pid wasn't getting killed due to a permissions issue. 

Works perfectly well. 

-- 
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] Direct POST payments in Cartridge

[Alexander Hill]

Lots of good points there.

I suppose I have unconsciously been thinking about this from the
perspective of someone who needs to take payments via external POST, and
also happens to want the unfinished orders hanging around as well. So
cleaning up and hiding the unfinished orders didn't occur to me.

I agree that this change doesn't warrant all of that, and I would be happy
with an easier way to make this configurable. One easy thing we could
change would be to make sure Cartridge's OrderForm works nicely if passed
an instance. I have no idea how far this is from being the case currently
(missing argument to __init__ aside). I'll have a play with this shortly.


Hmmm...

Another somewhat (!) more invasive idea is to unify orders and carts. I
think that could actually simplify Cartridge quite a lot, as there's a lot
of code marshalling data between sessions, carts and orders currently. Let
every order begin as a cart, and simply add data to it as the user
progresses through the checkout and payment steps. The status field would
indicate how far the order has come – cart, checkout, payment, complete,
processed.

We would be able to clean out old unfinished orders for free – we already
do that with carts. As a bonus, we'd also get user-based carts for free,
since carts/orders would have the user_id field set. We would satisfy the
use cases mentioned in this thread, and simplify the code and schema.

Big change I know, but what do you reckon?

Cheers,
Alex


On Wed, Dec 10, 2014 at 2:05 PM, Stephen McDonald  wrote:

> I don't know, which means I guess I'm not set. I understand the desire for
> it, but I've always felt it's important with Mezzanine and Cartridge to
> reject certain features, even when they'd be useful to someone, especially
> when they start to compromise the original intent of how things have been
> designed.
>
> So I suppose If it could be implemented simply enough with a setting, then
> sure - but what does it really entail?
>
> It would need some documentation around it, describing why unfinished
> orders get left floating around, and how they could possibly be cleaned up.
> It'd even best be up to Cartridge to provide the management command that
> does that, and notes in the documentation on how it can be used as a cron
> job.
>
> The SHOP_ORDER_STATUS_CHOICES will need something like an "Unfinished"
> status as well. Then the admin will need support too - if unfinished orders
> remain in the db, it really makes no sense for them to appear by default.
>
> You can see one seemingly small option controlled by a setting really does
> have a flow-on effect throughout the project, which is a major part of why
> I don't want it. Is this really not something that can be implemented by
> doing away with the final checkout step views of Cartridge, and just using
> something custom?
>
> Actually a better question might be - how can we make this configurable
> somehow, without actually implementing "order objects get created before
> payment" feature? Could we not break the checkout form (which I recall as
> being swappable via a setting) up into enough overridable methods, that
> control the behaviour, similar to how a lot of class based views work?
>
> On Wed, Dec 10, 2014 at 4:45 PM, Alexander Hill  wrote:
>
>> My understanding is that if CC details touch your server, even in memory,
>> you need to be compliant. The official PCI body says "The DSS globally
>> applies to *all* entities that store, process or transmit cardholder
>> data" at
>> https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf
>>
>> I agree that Cartridge's simplicity is a strength, but I don't feel that
>> adding this feature will compromise that. Are you pretty set on this, or is
>> it worth me making a branch and seeing if it can be done without
>> complicating things too much?
>>
>> Cheers
>> Alex
>>
>> On Wed, Dec 10, 2014 at 10:11 AM, Stephen McDonald 
>> wrote:
>>
>>> There was a lengthy mailing list discussion on this years ago where
>>> everyone agreed that there shouldn't be unfinished orders floating around
>>> in the database.
>>>
>>> I still agree with that and I'm not particularly keen on the idea of
>>> having to maintain this as an option and feature. Cartridge is
>>> intentionally very simple and limited compared to the alternatives, I'd
>>> rather keep it that way.
>>>
>>> BTW I naively assumed that Cartridge dealt with credit card handling
>>> well enough from a PCI-DSS perspective - the card number doesn't get
>>> stored anywhere and is only posted from one checkout step form to the next.
>>>
>>>
>>> On Wed, Dec 10, 2014 at 1:03 PM, Alexander Hill 
>>> wrote:
>>>
 Hi Josh,

 I'm interested to hear from Steve too. Since Cartridge was initially
 written to call payment processors from the server, only creating the
 orders after payment was submitted makes sense it makes sense – doing so
 earlier  does introduce a bit of extra complexity. Keeping the cart in sync
 with the