[mezzanine-users] Re: Omitting empty fields from form email

[Eduardo Rivas]

Thanks Josh! I ended up not needing this but your solution is definitely 
the way to go.

-- 
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/groups/opt_out.

Re: [mezzanine-users] [ANN] youpatch.com is a Mezzanine site

[Josh Cartmell]

Cool stuff, great looking site, thanks for sharing!


On Thu, Feb 6, 2014 at 3:52 PM, John Barham  wrote:

> Hi folks,
>
> I'm pleased to announce that YouPatch (https://www.youpatch.com/), a
> site for pixel quilt design that I co-founded, launched earlier this
> week. So check it out and tell all your crafting friends!
>
> All of the content pages on the site were created in the Mezzanine
> CMS. Apart from tweaking some of the templates we're pretty much using
> Mezzanine out of the box as it Just Works (TM).
>
> Regarding Cartridge, YouPatch is an e-commerce in that we sell pattern
> PDFs so I investigated the feasibility of using it. In the end I
> decided against it since each pattern is essentially a custom
> generated "product" which didn't seem to fit in well w/ the default
> Cartridge product model.
>
> IMHO Mezzanine is Django's killer app as it frees up the programmer to
> focus on custom programming but provides a very rich and easy-to-use
> CMS for content specialists to build out the site content.
>
> So kudos to Steve in particular for creating Mezzanine and thanks to
> all the contributors for making it better.
>
> Cheers,
>
> John
>
> --
> 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/groups/opt_out.
>

-- 
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/groups/opt_out.

[mezzanine-users] [ANN] youpatch.com is a Mezzanine site

[John Barham]

Hi folks,

I'm pleased to announce that YouPatch (https://www.youpatch.com/), a
site for pixel quilt design that I co-founded, launched earlier this
week. So check it out and tell all your crafting friends!

All of the content pages on the site were created in the Mezzanine
CMS. Apart from tweaking some of the templates we're pretty much using
Mezzanine out of the box as it Just Works (TM).

Regarding Cartridge, YouPatch is an e-commerce in that we sell pattern
PDFs so I investigated the feasibility of using it. In the end I
decided against it since each pattern is essentially a custom
generated "product" which didn't seem to fit in well w/ the default
Cartridge product model.

IMHO Mezzanine is Django's killer app as it frees up the programmer to
focus on custom programming but provides a very rich and easy-to-use
CMS for content specialists to build out the site content.

So kudos to Steve in particular for creating Mezzanine and thanks to
all the contributors for making it better.

Cheers,

John

-- 
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/groups/opt_out.

[mezzanine-users] Re: Mezzanine 3.0.8 released

[Matt Mansour]

Thanks all!

On Wednesday, February 5, 2014 12:50:42 PM UTC-8, Stephen McDonald wrote:
>
> Hi all, 
>
> It's been a busy week since 3.0.7 and Mezzanine 3.0.8 is now out with a 
> handful of minor bugfixes and improvements:
>
> - Improved support for thumbnails on remove storage backends
> - Fixed conditional validation of content fields via their status in 
> Displayable models
> - More static proxy fixes (fixes many reported issues loading tinymce 
> dialogs etc)
> - More unicode fixes around page processor slugs
> - Initial support for using the latest upstream Grappelli/Filebrowser (via 
> https://github.com/sephii/mezzanine-grappelli)
> - urlpatterns for mezzanine.accounts now follow the convention of defaults 
> for Django's LOGIN_URL/LOGOUT_URL settings (/account/ becomes /accounts/, 
> with the former redirecting to the latter as a fallback)
> - Mezzanine's runserver will now serve files under STATIC_ROOT during 
> development
> - Fixes for unicode filenames in mezzanine.galleries
>
> Big thanks to everyone who helped out this week.
>
>
> -- 
> Stephen McDonald
> http://jupo.org 
>

-- 
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/groups/opt_out.

[mezzanine-users] Re: Mezzanine 3.0.8 released

[Dustin Nation]

Awesome, thanks!

-- 
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/groups/opt_out.

Re: [mezzanine-users] Re: Spam queries to DB table 'django_site' by mezzanine.core.managers.CurrentSiteManager

[Fernando Macedo]

I'm new to Mezzanine, trying to publish my first site using it 
(http://batistapeniel.org/).

I came here from a similar issue, when I realized that there are so many 
queries to 'django_site'. 

Since my site only have 1 domain and based on how current_site_id() works, I 
disabled all lookups by placing a simple middleware before all others that 
uses default settings.SITE_ID:


   1. from django.conf import settings
   2.  
   3. class FixedSiteID(object):
   4. def process_request(self, request):
   5. request.site_id = settings.SITE_ID
   

Best regards,

Em quinta-feira, 21 de março de 2013 23h57min53s UTC-3, Stephen McDonald 
escreveu:
>
> Well it would certainly break the case of people using multiple domains 
> against a single site record, so yeah I think this is some of the pain I 
> was thinking there might be.
>
> I guess all we can do is if a site can't be matched by domain, fall back 
> to the first site, or specifically the site defined by the SITE_ID setting, 
> which actually already happens here:
>
>
> https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/utils/sites.py#L54-L55
>
> The thing with that though is that it doesn't attach the site ID to the 
> request, so each site lookup continues to query the database. I guess we 
> could have the fallback to SITE_ID also attach the site ID to the request 
> so that there's still only a single DB query as is the case with a valid 
> domain.
>
> Can anyone think of any pitfalls this might trigger? I can't.
>
> On Fri, Mar 22, 2013 at 7:48 AM, Josh Cartmell 
> 
> > wrote:
>
>> Do you think that would be redundant with the new ALLOWED_HOSTS Django 
>> setting?  Your whole site will already not work if a domain isn't found in 
>> ALLOWED_HOSTS.  There also might be use cases where you have two domains 
>> pointing at a site but don't want them to have separate site records.  For 
>> example a lot of times I'll initially have a dev domain pointed at a site 
>> so that I can show the client progress on a site, while in reality the 
>> Django site record already contains their live domain.
>>
>>
>> On Thu, Mar 21, 2013 at 12:39 PM, Stephen McDonald 
>> 
>> > wrote:
>>
>>> That makes sense. You need to have a valid site record set up.
>>>
>>> I'm not sure if it would cause more pain than correctness, but it might 
>>> be worthwhile if we raise an exception if a valid domain isn't matched.
>>>
>>>
>>> On Fri, Mar 22, 2013 at 4:20 AM, irrelevance 
>>> 
>>> > wrote:
>>>
 I end up changing django_site table from this:

 id   domain   name
 1productionsite.com   SiteName

 to this:

 id   domainname
 1 1 27.0.0.1:8000SiteName

 And after that repeating query disappeared.

 On Saturday, March 2, 2013 5:37:37 PM UTC+4, irrelevance wrote:

> Hello!
>
> Im notices that one of my ORM queries produces queries like:
>
> SELECT `django_site`.`id`, `django_site`.`domain`, 
> `django_site`.`name` 
> FROM `django_site` WHERE `django_site`.`domain` LIKE '127.0.0.1:8000'
>
>
> Im figured it from django_debug_toolbar logs, and MySQL query logs, 
> using IDE debugger for executing suspicious query.
> Im running site from production server that I set up on Django 
> dev-server.
> Contents of 'django_site' table:
>
> id   domainname
> 1productionsite.comSiteNameAlias
>
> My m2m call is like item.categories.all(). And Im sure that problem 
> is just in that call code, because it cause spam queries in any 
> place, wherever it being called.
>
> Actual code that produce query is get_query_set() method of 
> CurrentSiteManager 
> class in mezanine.core.managers module:
>
> def get_query_set(self):
> if not self.__is_validated:
> self._validate_field_name()
> lookup = {self.__field_name + "__id__exact": current_site_id()}
> return super(DjangoCSM, self).get_query_set().filter(**lookup)
>
>
> on 'lookup ='  code exectuion goes in mezzanine.utils.sites module in 
> current_site_id() function:
>
> from mezzanine.utils.cache import cache_installed, cache_get, cache_set
> request = current_request()
> site_id = getattr(request, "site_id", None)
> if request and not site_id:
> site_id = request.session.get("site_id", None)
> if not site_id:
> domain = request.get_host().lower()
> if cache_installed():
> # Don't use Mezzanine's cache_key_prefix here, since it
> # uses this very function we're in right now to create 
> a
> # per-site cache key.
> cache_key = settings.CACHE_MIDDLEWARE_KEY_PREFIX + 
> ".site_id"
> site_id = cache_get(cache_key)

[mezzanine-users] Re: serve media files on my local development server

[Sebastian Clemens]

Now I made a local revert of

https://github.com/stephenmcd/mezzanine/commit/67aaae401fe47c55960236c8f3472f2d4c16e3d0

and everything works. Don't know what happened.

Am Donnerstag, 6. Februar 2014 12:32:30 UTC+1 schrieb Sebastian Clemens:
>
> Since Stephen's changes and my last git pull, the media files won't served 
> anymore on a default project. Can anyone confirm this?
>
> Am Donnerstag, 6. Februar 2014 00:02:33 UTC+1 schrieb Eduardo Rivas:
>>
>> As Stephen said, it is recommended you only use STATIC_ROOT to contain 
>> files rounded up by collectstatic when deploying. The directory "/static" 
>> is listed in .gitignore and .hgignore for this same reason. Just in case 
>> someone is wondering what to do with files that don't belong to any app, 
>> this is what I do:
>>
>>1. Create "assets/" (or whatever you want to name it) in your project 
>>root. Dump your general purpose static resources there.
>>2. In settings.py define STATICFILES_DIRS = 
>>(os.path.join(PROJECT_ROOT, "assets"),). This will tell Django to see 
>>"assets/" as a valid location for static files.
>>3. Access your files in the templates. For example, 
>>"assets/style.css" will be accessed by {% static "style.css" %}.
>>
>> Just my two cents :)
>>
>

-- 
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/groups/opt_out.

[mezzanine-users] Re: serve media files on my local development server

[Sebastian Clemens]

Since Stephen's changes and my last git pull, the media files won't served 
anymore on a default project. Can anyone confirm this?

Am Donnerstag, 6. Februar 2014 00:02:33 UTC+1 schrieb Eduardo Rivas:
>
> As Stephen said, it is recommended you only use STATIC_ROOT to contain 
> files rounded up by collectstatic when deploying. The directory "/static" 
> is listed in .gitignore and .hgignore for this same reason. Just in case 
> someone is wondering what to do with files that don't belong to any app, 
> this is what I do:
>
>1. Create "assets/" (or whatever you want to name it) in your project 
>root. Dump your general purpose static resources there.
>2. In settings.py define STATICFILES_DIRS = 
>(os.path.join(PROJECT_ROOT, "assets"),). This will tell Django to see 
>"assets/" as a valid location for static files.
>3. Access your files in the templates. For example, "assets/style.css" 
>will be accessed by {% static "style.css" %}.
>
> Just my two cents :)
>

-- 
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/groups/opt_out.