Re: [mezzanine-users] Re: Fileupload Error
after I switch to mezzanine account, it still the same, not only on
profile, as long as uploading file, it return such errors. Even if I try to
handle file upload manually, when assigning the new uploaded file into the
FileField in Models, it will return same error
it stuck at:
*"python2.7/site-packages/filebrowser_safe-0.3.7-py2.7.egg/filebrowser_safe/fields.py
in to_python"return FileObject(url_to_path(value)) *
*"python2.7/site-packages/filebrowser_safe-0.3.7-py2.7.egg/filebrowser_safe/functions.py
in** url_to_path"*
value = mediaurl_re.sub('', value)
On Friday, February 13, 2015 at 10:23:33 PM UTC+8, Josh Cartmell wrote:
>
> I'm not sure what is causing the error, but instead of rewriting the
> account/profile management stuff I would recommend just going with what
> Mezzanine already has. If you haven't already take a look at:
> http://mezzanine.jupo.org/docs/user-accounts.html#public-user-accounts
>
> Mezzanine provides login/out and profile updating views.
>
> On Fri, Feb 13, 2015 at 5:42 AM, S.C. >
> wrote:
>
>> Forget the template:
>>
>> *Template:*
>>
>>
>> {{ title }}
>> {% fields_for userForm %}
>> {% fields_for form %}
>>
>> {% block account_form_actions %}
>> > "submit" value="Submit">
>> {% endblock %}
>>
>>
>>
>>
>> --
>> 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.
Re: [mezzanine-users] Re: status of django.contrib.sites in mezzanine
This probably doesn't have much chance of being included - it will most likely introduce an unwarranted increase in the complexity of how the page tree works. For example, all of a sudden you need to deal with the ordering of shared pages in the context of each site. Certainly not unsolvable, but probably not in a clean and simple way. Just some food for thought before embarking on anything. :-) On Mon, Feb 16, 2015 at 12:55 PM, Alexander Kominek < alexander.komi...@gmail.com> wrote: > Hey Josh, > > I'm trying to set up M2M for sites on one of my current sites and I > stumbled across this thread. Has any more work been completed on this in > the last year to bring it up to date with the latest version of Mezzanine? > If not, I'll probably end up updating it, but I just wanted to make sure > I'm not duplicating any work. > > Thanks! > > > > On Monday, January 7, 2013 at 3:28:15 PM UTC-7, Josh Cartmell wrote: >> >> Thanks again Steve, that blog post and your pointers helped me figure out >> a good direction to take. For anyone else tracking along I moved the >> migrations into a separate app which is here: >> https://bitbucket.org/joshcartme/mezz_sites_m2m >> >> One thing to note is that I had to change the calls to the orm since the >> migrations no longer reside in the app they modify. If this ever makes it >> into Mezzanine core we would probably want to change the orm calls back to >> the way they were. >> >> On Mon, Jan 7, 2013 at 8:56 AM, Josh Cartmell wrote: >> >>> Thanks Steve, that post is pretty useful. I'll give it a go. >>> >>> >>> On Sun, Jan 6, 2013 at 12:06 PM, Stephen McDonald >>> wrote: >>> Luke Miller (ex-colleague of mine) wrote a good post on how he does it: http://dodgyville.tumblr.com/post/23028930440/new-fields- in-mezzanine-without-editing-or-creating-a On Mon, Jan 7, 2013 at 7:05 AM, Josh Cartmell wrote: > Thanks Steve, I didn't realize I could put migrations in a different > app so that's very helpful! > > > On Sat, Jan 5, 2013 at 3:01 PM, Stephen McDonald > wrote: > >> I haven't had a chance to look at this yet myself. As for the >> migrations, you could probably put your one into a separate app, and >> if/when your changes get merged into the main project, just fake the >> (redundant) migration for it. >> >> >> On Sat, Jan 5, 2013 at 12:00 PM, Josh Cartmell >> wrote: >> >>> Hey everyone, I just wanted to check in and see if this is still on >>> the radar at all? >>> >>> I'm about to use this in a project so if it's not does anyone have >>> any >>> suggestions for how I should manage migrations? Would I just need to >>> always edit every future migration to reflect the divergent db >>> schemas? >>> >>> Thanks for all the feedback thus far. >>> >>> On Nov 19 2012, 12:42 pm, Josh Cartmell >>> wrote: >>> > Sounds good, thanks Steve! >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Mon, Nov 19, 2012 at 11:54 AM, Stephen McDonald >>> wrote: >>> > > I haven't gone over the code in detail yet, just waiting for >>> some space to >>> > > be able to do that. But as far as what we've discussed so far >>> I'm all in >>> > > favour of the feature and approach. >>> > >>> > > On Tue, Nov 20, 2012 at 6:51 AM, Josh Cartmell < >>> joshcar...@gmail.com>wrote: >>> > >>> > >> In regards to the changes I have made I just did a little >>> performance >>> > >> profiling (using Django debug toolbar) and surprisingly the >>> same number of >>> > >> queries are executed to render the About page of a vanilla >>> Mezzanine >>> > >> project regardless of whether you are using a foreign key or >>> the m2m >>> > >> versions of sites that I implemented. I'm wondering if >>> Django's current >>> > >> site manager does some sort of performance tweaking since it is >>> > >> specifically built to handle m2m's or foreignkeys. I haven't >>> made any >>> > >> improvements in regards to performance. >>> > >>> > >> With that in mind the changes I have made so far may be >>> basically ready >>> > >> to be pulled. What do you think Steve et al? >>> > >>> > >> On Fri, Nov 16, 2012 at 4:06 PM, Stephen McDonald < >>> st...@jupo.org> wrote: >>> > >>> > >>> Previously discussed here just for reference: >>> > >>> > >>>https://groups.google.com/group/mezzanine-users/browse_ >>> thread/thread/... >>> > >>> > >>> On Sat, Nov 17, 2012 at 8:07 AM, Robert Moggach < >>> r...@dashing.tv> wrote: >>> > >>> > It doesn't instinctively make sense if you only have 3 or 4 >>> one off >>> > pages that are 1 or 2 deep but if you're dealing with big >>> datasets and >>> > multiple sites it starts to make alot of sense. It wouldn't >>> affect
Re: [mezzanine-users] Re: status of django.contrib.sites in mezzanine
Hey Josh, I'm trying to set up M2M for sites on one of my current sites and I stumbled across this thread. Has any more work been completed on this in the last year to bring it up to date with the latest version of Mezzanine? If not, I'll probably end up updating it, but I just wanted to make sure I'm not duplicating any work. Thanks! On Monday, January 7, 2013 at 3:28:15 PM UTC-7, Josh Cartmell wrote: > > Thanks again Steve, that blog post and your pointers helped me figure out > a good direction to take. For anyone else tracking along I moved the > migrations into a separate app which is here: > https://bitbucket.org/joshcartme/mezz_sites_m2m > > One thing to note is that I had to change the calls to the orm since the > migrations no longer reside in the app they modify. If this ever makes it > into Mezzanine core we would probably want to change the orm calls back to > the way they were. > > On Mon, Jan 7, 2013 at 8:56 AM, Josh Cartmell > wrote: > >> Thanks Steve, that post is pretty useful. I'll give it a go. >> >> >> On Sun, Jan 6, 2013 at 12:06 PM, Stephen McDonald > > wrote: >> >>> Luke Miller (ex-colleague of mine) wrote a good post on how he does it: >>> >>> >>> http://dodgyville.tumblr.com/post/23028930440/new-fields-in-mezzanine-without-editing-or-creating-a >>> >>> >>> On Mon, Jan 7, 2013 at 7:05 AM, Josh Cartmell >> > wrote: >>> Thanks Steve, I didn't realize I could put migrations in a different app so that's very helpful! On Sat, Jan 5, 2013 at 3:01 PM, Stephen McDonald >>> > wrote: > I haven't had a chance to look at this yet myself. As for the > migrations, you could probably put your one into a separate app, and > if/when your changes get merged into the main project, just fake the > (redundant) migration for it. > > > On Sat, Jan 5, 2013 at 12:00 PM, Josh Cartmell > wrote: > >> Hey everyone, I just wanted to check in and see if this is still on >> the radar at all? >> >> I'm about to use this in a project so if it's not does anyone have any >> suggestions for how I should manage migrations? Would I just need to >> always edit every future migration to reflect the divergent db >> schemas? >> >> Thanks for all the feedback thus far. >> >> On Nov 19 2012, 12:42 pm, Josh Cartmell wrote: >> > Sounds good, thanks Steve! >> > >> > >> > >> > >> > >> > >> > >> > On Mon, Nov 19, 2012 at 11:54 AM, Stephen McDonald >> wrote: >> > > I haven't gone over the code in detail yet, just waiting for some >> space to >> > > be able to do that. But as far as what we've discussed so far I'm >> all in >> > > favour of the feature and approach. >> > >> > > On Tue, Nov 20, 2012 at 6:51 AM, Josh Cartmell < >> joshcar...@gmail.com>wrote: >> > >> > >> In regards to the changes I have made I just did a little >> performance >> > >> profiling (using Django debug toolbar) and surprisingly the same >> number of >> > >> queries are executed to render the About page of a vanilla >> Mezzanine >> > >> project regardless of whether you are using a foreign key or the >> m2m >> > >> versions of sites that I implemented. I'm wondering if Django's >> current >> > >> site manager does some sort of performance tweaking since it is >> > >> specifically built to handle m2m's or foreignkeys. I haven't >> made any >> > >> improvements in regards to performance. >> > >> > >> With that in mind the changes I have made so far may be >> basically ready >> > >> to be pulled. What do you think Steve et al? >> > >> > >> On Fri, Nov 16, 2012 at 4:06 PM, Stephen McDonald < >> st...@jupo.org> wrote: >> > >> > >>> Previously discussed here just for reference: >> > >> > >>> >> https://groups.google.com/group/mezzanine-users/browse_thread/thread/. >> .. >> > >> > >>> On Sat, Nov 17, 2012 at 8:07 AM, Robert Moggach < >> r...@dashing.tv> wrote: >> > >> > It doesn't instinctively make sense if you only have 3 or 4 >> one off >> > pages that are 1 or 2 deep but if you're dealing with big >> datasets and >> > multiple sites it starts to make alot of sense. It wouldn't >> affect small >> > sites adversely to implement, only add flexibility. If you >> start to have >> > page structures that are 5 or 6 deep with many siblings at >> each level, it's >> > a clear winner to use modified preorder tree traversal. >> > >> > http://en.wikipedia.org/wiki/Tree_traversal >> > >> > Take a look at how feinCMS implements their menu structure >> using >> > MPTT... >> > >> > Abstracting the presentation logic from the content logic is a >> good >> > thing. >> > >> > On Fri,
[mezzanine-users] Twitter query error (Could not authenticate)
Upon running "python manage.py poll_twitter" I persistently get an authentication error. Twitter query error [User: from:(removed) (removed)]: Could not authenticate you. Ideas where to start? I've verified the tokens and secrets are all correct. -- 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: Cartridge - Add product variants
Well, I've successfully implemented a workaround so that product variation
options are dynamic. Rather than gut the current ProductVariation
(shop_productvariation) table design, it simply appends a column as needed.
It introduces two new tables: OptionType (shop_optiontypes) and
OptionChoice (shop_optionchoice). The first represents categories of
options such as color or size. The second represents values that are
assigned to the types; for example blue or red could be assigned to color.
It also updates entries in ProductVariation when changes are made to
OptionChoice entries.
I can submit code to the project once I construct tests.
HTH
Brian
On Thursday, January 29, 2015 at 8:42:40 PM UTC-5, bw3...@gmail.com wrote:
>
> From the documentation and examining the code, options for product
> variants are based entirely on editing the value of
> SHOP_OPTION_TYPE_CHOICES in settings.py, and in turn adding a new column
> (e.g., option3) the shop_productvariation table. So it requires two steps,
> and has to be done by a developer.
>
> We have a client who would like to add product options and dynamically
> through the admin interface, eliminating the need to call the developer
> each time. (In some business, product offerings change frequently.)
> Updating options dynamically through the admin interface is a huge benefit.
>
> I've managed to get this "most of the way" by adding two new models:
> OptionType and OptionChoice. You can add types (e.g., color, size or
> fabric) and assign values (e.g., red or blue to color type). But, I'm
> struggling with one aspect, and hoping someone might offer a suggestion:
> inline formset that should be displayed on "Create new variations" on the
> product edit screen. After displaying the appropriate options, of course
> they should be saved properly. The new approach is not adding columns to
> shop_productvariation; instead adding rows to shop_optiontypes.
>
> class OptionType(models.Model):
> product = models.ForeignKey(Product)
> dscr = models.CharField('value', max_length=40)
>
> def __unicode__(self):
> return self.dscr
>
> class Meta:
> verbose_name = _("Option Type")
> verbose_name_plural = _("Option Types")
>
>
> class OptionChoice(models.Model):
> option_type = models.ForeignKey(OptionType)
> dscr = models.CharField('value', max_length=40)
>
> objects = managers.OptionChoiceManager()
>
> def __unicode__(self):
> return self.dscr
>
> class Meta:
> verbose_name = _("Option Value")
> verbose_name_plural = _("Option Values")
>
>
> PRODUCT_OPTION_CHOICES = [(option_type.id, option_type.dscr) for
> option_type in OptionType.objects.all()]
>
>
> Brian
>
>
--
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.
