[mezzanine-users] Re: Changing Blog List Images Sizes
This is relatively straightforward. You will just need to modify the
blog_post_list.html template (for the list), and/or the
blog_post_detail.html template (for an individual post).
Here is a bit of code that I use in blog_post_list.html to show
thumbnail-type images on my own blog list page, which is here:
http://rosslaird.com/blog/
{% editable post.title post.publish_date
post.content %}
{{ post.title }}
By {{
post.user.get_full_name|default:post.user.username }} | {{
post.publish_date }}
{{
post.description_from_content|safe|truncatewords_html:"50" }}
Read more
{% endeditable %}
{% if forloop.counter|divisibleby:"3" %}
{% endif %}
Then, on the page for each individual post, the image is used as the
background for the header. That code lives in blog_post_detail.html, and
looks like this:
{{ blog_post.title
}}
You can see how the above code renders the page by clicking on any post
from the listing page.
Hope this helps.
Ross
On Friday, 16 October 2015 13:59:23 UTC-7, Tommy Long wrote:
>
> This is probably a simple question so forgive me. I'm trying to find out a
> why to change the images that appear on my blog list page to show
> thumbnails and not full size images, when a user clicks on them they will
> be taken to the blog post page where the full size image will be shown. The
> page I'm talking about is here technelogos.com/blog. Thanks for your 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: Good approaches to doing graphics customization?
You might want to take a look at the section on Modifying the CSS in this tutorial (it's near the bottom): http://rosslaird.com/blog/customizing-mezzanine/ In general, I use a separate CSS file for my customizations (loaded after the bootstrap CSS), and I use either Emacs or Sublime Text (or Vim) to make the actual changes. All work very well. Also, typically the best way to identify elements to change is to use the web development features (or extensions) of your browser. In Chrome, the key for this is Ctrl-Shift-i (that's a letter i). Hope this helps. Ross On Monday, 4 May 2015 12:43:32 UTC-7, Brian Osborne wrote: All, Just starting out with Mezzanine, it's very impressive, and I'm happy that it's Python. Should add, I'm working on Mac OS. I'm more of a coder than a graphics designer. In fact I'm not a designer at all! I want to do some basic graphic customization (change some div or element to a different color, change a button color, and so on). I use Sublime Text, and if I go into Develop mode in Safari and use its Inspect button I'm able to figure out where most of the elements are in the CSS, and then I can modify them in the css/bootstrap.css file. But this is really clunky, and there are still visual elements that I can not find and modify. Can anyone give me advice on effective ways to do this? WYSIWYG or not, commercial or open source. Thank you in advance, Brian O. -- 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] Rendering the canvas tag?
Turns out that the tag is not being stripped out but the display of the tag
inside the editor is being changed.
When I add canvas ... /canvas within the editor, then save, then
re-open the HTML editing window, the canvas tag is changed to p ... /p.
I see the p tag, and no canvas tag, in the editor.
But when I add the canvas tag inside the editor, save it, then look at the
source code of the resulting page (on the site), the canvas tag is indeed
there (and there is no p tag at that location).
So, the canvas tag is being accepted properly; but it is being shown as a p
tag inside the text editor.
On Thursday, 30 October 2014 20:10:14 UTC-7, MattQ wrote:
Add this line to your view:
print( page.portfolioitem.content)
And see the results in the console. You'll see right away if the tags are
already stripped or not. If so, they were stripped upstream prior to
getting saved in the db. Otherwise, if the tags are there, then you can
focus on why the template is stripping them.
On Oct 30, 2014 7:58 PM, Ross Laird ro...@rosslaird.com javascript:
wrote:
But sadly, still no...
On Thursday, 30 October 2014 19:56:21 UTC-7, Ross Laird wrote:
Oh, silly, silly. I should try this:
{{ page.portfolioitem.content|safe }}
On Thursday, 30 October 2014 19:50:48 UTC-7, Ross Laird wrote:
Thanks for the reply. At least it sounds like there is a way to do
this. However --
I've tried this:
{{ page.portfolioitem.content|richtext_filters|safe }}
and this:
{{ page.portfolioitem.content|richtext_filters|var|safe }}
and this:
{{ page.portfolioitem.content||var|safe }}
None of these seem to work.
Am I missing something very simple?
On Thursday, 30 October 2014 19:29:19 UTC-7, MattQ wrote:
For me it was Django built-in templating system that was stripping my
tags. I solved this by using safe template filter.
{{ var | safe }}
here's the docs:
https://docs.djangoproject.com/en/dev/ref/templates/
builtins/#std:templatefilter-safe
Hope this helps.
-matt
On Thu, Oct 30, 2014 at 7:21 PM, Ross Laird ro...@rosslaird.com
wrote:
I'd like to render some charts, using Chart.js, but I can't seem to
get the canvas tag to be preserved when I enter it into a rich text
page. I
have tinyMCE set up to accept all tags, and I have also added canvas to
the
ALLOWED_TAGS in defaults.py (thinking that this might not actually be a
tinyMCE issue). But *something *continues to strip out these tags.
Anybody have an idea what's going on?
I suppose I might have to create a custom template for this, if I
can't get it working through the interface.
Ross
--
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-use...@googlegroups.com javascript:.
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] Rendering the canvas tag?
Oh, silly, silly. I should try this:
{{ page.portfolioitem.content|safe }}
On Thursday, 30 October 2014 19:50:48 UTC-7, Ross Laird wrote:
Thanks for the reply. At least it sounds like there is a way to do this.
However --
I've tried this:
{{ page.portfolioitem.content|richtext_filters|safe }}
and this:
{{ page.portfolioitem.content|richtext_filters|var|safe }}
and this:
{{ page.portfolioitem.content||var|safe }}
None of these seem to work.
Am I missing something very simple?
On Thursday, 30 October 2014 19:29:19 UTC-7, MattQ wrote:
For me it was Django built-in templating system that was stripping my
tags. I solved this by using safe template filter.
{{ var | safe }}
here's the docs:
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatefilter-safe
Hope this helps.
-matt
On Thu, Oct 30, 2014 at 7:21 PM, Ross Laird ro...@rosslaird.com wrote:
I'd like to render some charts, using Chart.js, but I can't seem to get
the canvas tag to be preserved when I enter it into a rich text page. I
have tinyMCE set up to accept all tags, and I have also added canvas to the
ALLOWED_TAGS in defaults.py (thinking that this might not actually be a
tinyMCE issue). But *something *continues to strip out these tags.
Anybody have an idea what's going on?
I suppose I might have to create a custom template for this, if I can't
get it working through the interface.
Ross
--
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] Rendering the canvas tag?
But sadly, still no...
On Thursday, 30 October 2014 19:56:21 UTC-7, Ross Laird wrote:
Oh, silly, silly. I should try this:
{{ page.portfolioitem.content|safe }}
On Thursday, 30 October 2014 19:50:48 UTC-7, Ross Laird wrote:
Thanks for the reply. At least it sounds like there is a way to do this.
However --
I've tried this:
{{ page.portfolioitem.content|richtext_filters|safe }}
and this:
{{ page.portfolioitem.content|richtext_filters|var|safe }}
and this:
{{ page.portfolioitem.content||var|safe }}
None of these seem to work.
Am I missing something very simple?
On Thursday, 30 October 2014 19:29:19 UTC-7, MattQ wrote:
For me it was Django built-in templating system that was stripping my
tags. I solved this by using safe template filter.
{{ var | safe }}
here's the docs:
https://docs.djangoproject.com/en/dev/ref/templates/builtins/#std:templatefilter-safe
Hope this helps.
-matt
On Thu, Oct 30, 2014 at 7:21 PM, Ross Laird ro...@rosslaird.com wrote:
I'd like to render some charts, using Chart.js, but I can't seem to get
the canvas tag to be preserved when I enter it into a rich text page. I
have tinyMCE set up to accept all tags, and I have also added canvas to
the
ALLOWED_TAGS in defaults.py (thinking that this might not actually be a
tinyMCE issue). But *something *continues to strip out these tags.
Anybody have an idea what's going on?
I suppose I might have to create a custom template for this, if I can't
get it working through the interface.
Ross
--
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: sirtrevor editor for Mezzanine
This looks really sweet. Thanks for putting it together. On Tuesday, 14 October 2014 05:35:52 UTC-7, sohania wrote: Hi All, Please checkout my first app/plugin mezzanine-sirtrevor https://github.com/thecodinghouse/mezzanine-sirtrevor for Mezzanine. It replaces the default editor with Sir Trevor editor http://madebymany.github.io/sir-trevor-js/. Thanks, Abhinav -- 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: DEBUG = False setting is messing up the Theme and all text shows up differently without any CSS
This is a very common problem having to do with the different locations that Mezzanine searches for files in testing and deployment. Look into the collectstatic and collecttemplates commands, and look here for a walk-through: http://rosslaird.com/blog/customizing-mezzanine/ Ross On Saturday, 26 July 2014 08:35:56 UTC-7, Srinivas Ganti wrote: When I set the DEBUG = False in local_settings.py, the site doesn't display the theme, but when I change it to True, the theme shows up fine. Any ideas? -- 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: Internal Server Error - could be due to static files?
I wonder if STATIC_ROOT is the source of your problem. Have you tried
different settings for that, including STATIC_ROOT = /static/ ? I don't
use nginx (I use Apache), but looking at your config, I wonder if the
webserver is looking for static files in a folder that Django appends with
another path. So, is it possible that the webserver is trying to find the
static files in /var/www/example.com/static/static? This is one of those
situations where, I bet, the solution is going to involve something very
small and very simple: a trailing slash, the treatment of a path setting,
and whatnot.
The default setting for STATIC_ROOT should be:
STATIC_ROOT = os.path.join(PROJECT_ROOT, STATIC_URL.strip(/))
The treatment of the trailing slash above, and the inclusion of
PROJECT_ROOT and STATIC_URL entail that those settings do not have extra
slashes or paths that go beyond what Django strictly requires.
I'm just guessing, but as I mentioned above, I bet this is a simple path
reference problem.
On Thursday, 20 March 2014 23:43:28 UTC-7, Jesse Carrigan wrote:
I made some progress on understanding this, but haven't quite gotten past
the problem. One thing I learned was that I mixed up the use of the
STATIC_ROOT and STATIC_URL, but fixing it didn't seem to do much.
Here are what appear to be the relevant configs.
local_settings.py:
STATIC_URL = http://www.example.com/static/;
STATIC_ROOT = /var/www/example.com/static/
example.conf:
location /static/ {
root/var/www/example.com;
access_log off;
log_not_found off;
}
location /robots.txt {
root/var/www/example.com/static;
access_log off;
log_not_found off;
}
location /favicon.ico {
root/var/www/example.com/static/img;
access_log off;
log_not_found off;
}
So it looks to me like the alias should be correctly set up for the static
folder. Running collectstatic copies the static files from the project into
the folder at STATIC_ROOT. The static folder has 755 permissions
recursively from the top-level, so clients should be able to read and
execute. There's a missing piece that I haven't been able to find. Locally,
things work fine, but it's after deploying onto the server that the trouble
starts.
--
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: Problems with trying to change theme
Yes, you are probably missing either a comma or a quotation mark in the INSTALLED_APPS listing. On Monday, 17 March 2014 00:42:01 UTC-7, Jesse Carrigan wrote: Could you post the exact contents of your INSTALLED_APPS list? I'm guessing, but it looks like there may be a typo either in what you posted here (ValueError: u'django.contrib.admin' is not in list) or your INSTALLED_APPS list. -- 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: Internal Server Error - could be due to static files?
What happens when you run collectstatic? If I recall correctly, one of the differences between DEBUG = False and DEBUG = True is that the former will use static files from Mezzanine's codebase and the latter will search for static files in your project folders. The collectstatic command will show you where the files are being pulled from and where they are being put. Then you can tell if your static files settings match up with what Mezzanine expects. That might at least give you more information. On Sunday, 16 March 2014 00:43:47 UTC-7, Jesse Carrigan wrote: I've been poking at static files on Mezzanine for several days trying to tease out what is wrong. Here's what I think I know: I am using Fabric to deploy Mezzanine onto a Vagrant VM. I have been getting an Internal Server Error message when setting DEBUG = False. When DEBUG = True, the site loads fine. Per the docs this appears to be due to the static files not being served in the first case. Initially, I found in the ngnix error logs that there was a problem with permissions on the projectname/project/static folder where all the static files had been copied during the Fabric deploy. The server was denied permission to the favicon.ico file. It looked like the ngnix user did not have the appropriate permissions to the top-level /home folder (700 with root:root), and thus couldn't access the project folder. After looking at the staticfiles docs in Django it looked like the best thing to do was to move the static files into a location like /var/www/ example.com/static and serve them from there. I created the directory, copied the static files, and changed the ngnix config file for the site to serve the static files from that location. I also set STATIC_ROOT in local_settings.py to that location. However, I continued to get the same Internal Server Error message with DEBUG = False. However, the ngnix errors are no longer coming up, and nothing is showing up in the console of the browser either. Any suggestions on the next step? -- 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: Do I have a basic flaw in my Mezzanine configuration?
Actually the site is not working with my S3 settings, so I'll think I'll
just move along until this pathway becomes more clear.
On Friday, 14 March 2014 15:51:15 UTC-7, Ross Laird wrote:
Well, my site is working now, with the S3 settings and with compression
on, but I'm not sure it's actually loading the files from S3. (The
Transfers list on S3 is empty.)
I'm not sure where to take this next, but for now I'm just going to leave
things alone. The site is working, at least.
On Friday, 14 March 2014 14:44:58 UTC-7, Ross Laird wrote:
Thanks for the tip. I have also seen the incompressible error due to
offsite files, but in my current situation I have not changed any templates
and the compression works without errors if I deactivate S3.
On Friday, 14 March 2014 14:38:57 UTC-7, Josh Cartmell wrote:
Hey Ross, I don't have experience with S3, so I don't know if this
applies, but in the past I have seen the incompressible file error if I
accidentally include something within the compress templatetags that isn't
on the same local filesystem as the site. Someone with more experience may
know how to get it working.
On Fri, Mar 14, 2014 at 2:24 PM, Ross Laird ro...@rosslaird.com wrote:
Without really knowing exactly how it happened, I got S3 file storage
working. I turned compression off, for now, and will try to debug that
next. As for the basic S3 setup, here are some of the things I did, in
case
it helps someone else:
1. I added the following two lines to my S3 settings:
from S3 import CallingFormat
AWS_CALLING_FORMAT = CallingFormat.SUBDOMAIN
I don't really understand the above line, so I can't comment on why it
might be useful. It is from the django-storages documentation.
2. I tweaked my wsgi file a bit. It now reads as follows:
from __future__ import unicode_literals
import os
import sys
import site
# Virtual environment on Python path
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
settings_module = %s.settings % PROJECT_ROOT.split(os.sep)[-1]
os.environ.setdefault(DJANGO_SETTINGS_MODULE, settings_module)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I did not change my Apache settings. So, the two changes above are
pretty much all I did.
Now onto the compression issues.
(I still don't know if my wsgi settings reflect some basic
configuration issue with Mezzanine, even with S3 now working.)
On Friday, 14 March 2014 09:59:16 UTC-7, Ross Laird wrote:
I have been trying for quite some time to get my static files onto
Amazon S3, and I just keep running into show-stopping issues. And I think
that my problems with S3 have revealed a flaw in my basic Mezzanine
configuration. Once I activate the S3 setup for static files, I get an
error like this:
UncompressableFileError: 'css/animate.css' could not be found in the
COMPRESS_ROOT '/home/rosslaird/static' or with staticfiles.
The folder 'rosslaird/static' does not exist and should not be part of
my Mezzanine configuration. On the other hand, my site runs just fine
(until I add the S3 configuration). I expect that 'static' is being
appended at runtime, and that '/home/rosslaird' is the offending part. It
does appear in my wsgi file:
from __future__ import unicode_literals
# Virtual environment on Python path
import site
site.addsitedir('/home/rosslaird/.virtualenvs/
mezzanine3/lib/python2.6/site-packages')
import os, sys
sys.path.insert(0, '/home/rosslaird/m3/zeni_core')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
os.environ['DJANGO_SETTINGS_MODULE'] = 'm3.settings'
import django.core.handlers.wsgi
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The offending folder also appears in my apache configuration, but I
think that the actual problem may be in the wsgi settings above. Or, at
least I should find out if the above is broken first, before looking at
Apache as the culprit.
Whatever the cause, this issue also results (with the S3 settings
activated) in django-compressor looking for files in one folder above the
place where the files actually are. For example, I've received various
error messages in which django-compressor looks for 'css/whatever.css'
rather than 'static/css/whatever.css'. But every way that I've tried to
change the paths for djangoo-compressor to search the proper path seems
not
to work. And my S3 paths and settings seem correct:
AWS_SECRET_ACCESS_KEY = 'my_key'
AWS_ACCESS_KEY_ID = 'my_other_key'
AWS_STORAGE_BUCKET_NAME = 'ral_mezzanine'
AWS_QUERYSTRING_AUTH = False
STATICFILES_STORAGE
[mezzanine-users] Do I have a basic flaw in my Mezzanine configuration?
I have been trying for quite some time to get my static files onto Amazon
S3, and I just keep running into show-stopping issues. And I think that my
problems with S3 have revealed a flaw in my basic Mezzanine configuration.
Once I activate the S3 setup for static files, I get an error like this:
UncompressableFileError: 'css/animate.css' could not be found in the
COMPRESS_ROOT '/home/rosslaird/static' or with staticfiles.
The folder 'rosslaird/static' does not exist and should not be part of my
Mezzanine configuration. On the other hand, my site runs just fine (until I
add the S3 configuration). I expect that 'static' is being appended at
runtime, and that '/home/rosslaird' is the offending part. It does appear
in my wsgi file:
from __future__ import unicode_literals
# Virtual environment on Python path
import site
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
import os, sys
sys.path.insert(0, '/home/rosslaird/m3/zeni_core')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
os.environ['DJANGO_SETTINGS_MODULE'] = 'm3.settings'
import django.core.handlers.wsgi
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The offending folder also appears in my apache configuration, but I think
that the actual problem may be in the wsgi settings above. Or, at least I
should find out if the above is broken first, before looking at Apache as
the culprit.
Whatever the cause, this issue also results (with the S3 settings
activated) in django-compressor looking for files in one folder above the
place where the files actually are. For example, I've received various
error messages in which django-compressor looks for 'css/whatever.css'
rather than 'static/css/whatever.css'. But every way that I've tried to
change the paths for djangoo-compressor to search the proper path seems not
to work. And my S3 paths and settings seem correct:
AWS_SECRET_ACCESS_KEY = 'my_key'
AWS_ACCESS_KEY_ID = 'my_other_key'
AWS_STORAGE_BUCKET_NAME = 'ral_mezzanine'
AWS_QUERYSTRING_AUTH = False
STATICFILES_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
STATIC_FILES_BUCKET = 'ral_mezzanine'
S3_URL = 'https://%s.s3.amazonaws.com/' % AWS_STORAGE_BUCKET_NAME
STATIC_ROOT = 'static'
COMPRESS_URL = S3_URL
STATIC_URL = COMPRESS_URL
MEDIA_URL = STATIC_URL + 'media/'
ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/'
COMPRESS_ENABLED = True
COMPRESS_ROOT = STATIC_ROOT
COMPRESS_STORAGE = STATICFILES_STORAGE
COMPRESS_OFFLINE = False
The above settings are in a separate file that is only imported when I
activate S3 (from a line in local_settings.py). So, normally, all of the
above settings that are also part of the default Mezzanine setup are set to
defaults in local_settings.py or settings.py.
I can access S3 just fine, from the django-shell, so it's not an access
problem. At this point, I've narrowed it down to what I think is the actual
issue: that folder reference.
Can anybody help me sort this out?
Thanks in advance.
Ross
--
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: Do I have a basic flaw in my Mezzanine configuration?
Without really knowing exactly how it happened, I got S3 file storage
working. I turned compression off, for now, and will try to debug that
next. As for the basic S3 setup, here are some of the things I did, in case
it helps someone else:
1. I added the following two lines to my S3 settings:
from S3 import CallingFormat
AWS_CALLING_FORMAT = CallingFormat.SUBDOMAIN
I don't really understand the above line, so I can't comment on why it
might be useful. It is from the django-storages documentation.
2. I tweaked my wsgi file a bit. It now reads as follows:
from __future__ import unicode_literals
import os
import sys
import site
# Virtual environment on Python path
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
settings_module = %s.settings % PROJECT_ROOT.split(os.sep)[-1]
os.environ.setdefault(DJANGO_SETTINGS_MODULE, settings_module)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I did not change my Apache settings. So, the two changes above are pretty
much all I did.
Now onto the compression issues.
(I still don't know if my wsgi settings reflect some basic configuration
issue with Mezzanine, even with S3 now working.)
On Friday, 14 March 2014 09:59:16 UTC-7, Ross Laird wrote:
I have been trying for quite some time to get my static files onto Amazon
S3, and I just keep running into show-stopping issues. And I think that my
problems with S3 have revealed a flaw in my basic Mezzanine configuration.
Once I activate the S3 setup for static files, I get an error like this:
UncompressableFileError: 'css/animate.css' could not be found in the
COMPRESS_ROOT '/home/rosslaird/static' or with staticfiles.
The folder 'rosslaird/static' does not exist and should not be part of my
Mezzanine configuration. On the other hand, my site runs just fine (until I
add the S3 configuration). I expect that 'static' is being appended at
runtime, and that '/home/rosslaird' is the offending part. It does appear
in my wsgi file:
from __future__ import unicode_literals
# Virtual environment on Python path
import site
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
import os, sys
sys.path.insert(0, '/home/rosslaird/m3/zeni_core')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
os.environ['DJANGO_SETTINGS_MODULE'] = 'm3.settings'
import django.core.handlers.wsgi
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The offending folder also appears in my apache configuration, but I think
that the actual problem may be in the wsgi settings above. Or, at least I
should find out if the above is broken first, before looking at Apache as
the culprit.
Whatever the cause, this issue also results (with the S3 settings
activated) in django-compressor looking for files in one folder above the
place where the files actually are. For example, I've received various
error messages in which django-compressor looks for 'css/whatever.css'
rather than 'static/css/whatever.css'. But every way that I've tried to
change the paths for djangoo-compressor to search the proper path seems not
to work. And my S3 paths and settings seem correct:
AWS_SECRET_ACCESS_KEY = 'my_key'
AWS_ACCESS_KEY_ID = 'my_other_key'
AWS_STORAGE_BUCKET_NAME = 'ral_mezzanine'
AWS_QUERYSTRING_AUTH = False
STATICFILES_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
STATIC_FILES_BUCKET = 'ral_mezzanine'
S3_URL = 'https://%s.s3.amazonaws.com/' % AWS_STORAGE_BUCKET_NAME
STATIC_ROOT = 'static'
COMPRESS_URL = S3_URL
STATIC_URL = COMPRESS_URL
MEDIA_URL = STATIC_URL + 'media/'
ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/'
COMPRESS_ENABLED = True
COMPRESS_ROOT = STATIC_ROOT
COMPRESS_STORAGE = STATICFILES_STORAGE
COMPRESS_OFFLINE = False
The above settings are in a separate file that is only imported when I
activate S3 (from a line in local_settings.py). So, normally, all of the
above settings that are also part of the default Mezzanine setup are set to
defaults in local_settings.py or settings.py.
I can access S3 just fine, from the django-shell, so it's not an access
problem. At this point, I've narrowed it down to what I think is the actual
issue: that folder reference.
Can anybody help me sort this out?
Thanks in advance.
Ross
--
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
Re: [mezzanine-users] Re: Do I have a basic flaw in my Mezzanine configuration?
Thanks for the tip. I have also seen the incompressible error due to
offsite files, but in my current situation I have not changed any templates
and the compression works without errors if I deactivate S3.
On Friday, 14 March 2014 14:38:57 UTC-7, Josh Cartmell wrote:
Hey Ross, I don't have experience with S3, so I don't know if this
applies, but in the past I have seen the incompressible file error if I
accidentally include something within the compress templatetags that isn't
on the same local filesystem as the site. Someone with more experience may
know how to get it working.
On Fri, Mar 14, 2014 at 2:24 PM, Ross Laird ro...@rosslaird.comjavascript:
wrote:
Without really knowing exactly how it happened, I got S3 file storage
working. I turned compression off, for now, and will try to debug that
next. As for the basic S3 setup, here are some of the things I did, in case
it helps someone else:
1. I added the following two lines to my S3 settings:
from S3 import CallingFormat
AWS_CALLING_FORMAT = CallingFormat.SUBDOMAIN
I don't really understand the above line, so I can't comment on why it
might be useful. It is from the django-storages documentation.
2. I tweaked my wsgi file a bit. It now reads as follows:
from __future__ import unicode_literals
import os
import sys
import site
# Virtual environment on Python path
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
settings_module = %s.settings % PROJECT_ROOT.split(os.sep)[-1]
os.environ.setdefault(DJANGO_SETTINGS_MODULE, settings_module)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I did not change my Apache settings. So, the two changes above are pretty
much all I did.
Now onto the compression issues.
(I still don't know if my wsgi settings reflect some basic configuration
issue with Mezzanine, even with S3 now working.)
On Friday, 14 March 2014 09:59:16 UTC-7, Ross Laird wrote:
I have been trying for quite some time to get my static files onto
Amazon S3, and I just keep running into show-stopping issues. And I think
that my problems with S3 have revealed a flaw in my basic Mezzanine
configuration. Once I activate the S3 setup for static files, I get an
error like this:
UncompressableFileError: 'css/animate.css' could not be found in the
COMPRESS_ROOT '/home/rosslaird/static' or with staticfiles.
The folder 'rosslaird/static' does not exist and should not be part of
my Mezzanine configuration. On the other hand, my site runs just fine
(until I add the S3 configuration). I expect that 'static' is being
appended at runtime, and that '/home/rosslaird' is the offending part. It
does appear in my wsgi file:
from __future__ import unicode_literals
# Virtual environment on Python path
import site
site.addsitedir('/home/rosslaird/.virtualenvs/
mezzanine3/lib/python2.6/site-packages')
import os, sys
sys.path.insert(0, '/home/rosslaird/m3/zeni_core')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
os.environ['DJANGO_SETTINGS_MODULE'] = 'm3.settings'
import django.core.handlers.wsgi
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The offending folder also appears in my apache configuration, but I
think that the actual problem may be in the wsgi settings above. Or, at
least I should find out if the above is broken first, before looking at
Apache as the culprit.
Whatever the cause, this issue also results (with the S3 settings
activated) in django-compressor looking for files in one folder above the
place where the files actually are. For example, I've received various
error messages in which django-compressor looks for 'css/whatever.css'
rather than 'static/css/whatever.css'. But every way that I've tried to
change the paths for djangoo-compressor to search the proper path seems not
to work. And my S3 paths and settings seem correct:
AWS_SECRET_ACCESS_KEY = 'my_key'
AWS_ACCESS_KEY_ID = 'my_other_key'
AWS_STORAGE_BUCKET_NAME = 'ral_mezzanine'
AWS_QUERYSTRING_AUTH = False
STATICFILES_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
STATIC_FILES_BUCKET = 'ral_mezzanine'
S3_URL = 'https://%s.s3.amazonaws.com/' % AWS_STORAGE_BUCKET_NAME
STATIC_ROOT = 'static'
COMPRESS_URL = S3_URL
STATIC_URL = COMPRESS_URL
MEDIA_URL = STATIC_URL + 'media/'
ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/'
COMPRESS_ENABLED = True
COMPRESS_ROOT = STATIC_ROOT
COMPRESS_STORAGE = STATICFILES_STORAGE
COMPRESS_OFFLINE = False
The above settings are in a separate file that is only imported when I
activate S3
Re: [mezzanine-users] Re: Do I have a basic flaw in my Mezzanine configuration?
Well, my site is working now, with the S3 settings and with compression on,
but I'm not sure it's actually loading the files from S3. (The Transfers
list on S3 is empty.)
I'm not sure where to take this next, but for now I'm just going to leave
things alone. The site is working, at least.
On Friday, 14 March 2014 14:44:58 UTC-7, Ross Laird wrote:
Thanks for the tip. I have also seen the incompressible error due to
offsite files, but in my current situation I have not changed any templates
and the compression works without errors if I deactivate S3.
On Friday, 14 March 2014 14:38:57 UTC-7, Josh Cartmell wrote:
Hey Ross, I don't have experience with S3, so I don't know if this
applies, but in the past I have seen the incompressible file error if I
accidentally include something within the compress templatetags that isn't
on the same local filesystem as the site. Someone with more experience may
know how to get it working.
On Fri, Mar 14, 2014 at 2:24 PM, Ross Laird ro...@rosslaird.com wrote:
Without really knowing exactly how it happened, I got S3 file storage
working. I turned compression off, for now, and will try to debug that
next. As for the basic S3 setup, here are some of the things I did, in case
it helps someone else:
1. I added the following two lines to my S3 settings:
from S3 import CallingFormat
AWS_CALLING_FORMAT = CallingFormat.SUBDOMAIN
I don't really understand the above line, so I can't comment on why it
might be useful. It is from the django-storages documentation.
2. I tweaked my wsgi file a bit. It now reads as follows:
from __future__ import unicode_literals
import os
import sys
import site
# Virtual environment on Python path
site.addsitedir('/home/rosslaird/.virtualenvs/mezzanine3/lib/python2.6/site-packages')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
settings_module = %s.settings % PROJECT_ROOT.split(os.sep)[-1]
os.environ.setdefault(DJANGO_SETTINGS_MODULE, settings_module)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
I did not change my Apache settings. So, the two changes above are
pretty much all I did.
Now onto the compression issues.
(I still don't know if my wsgi settings reflect some basic configuration
issue with Mezzanine, even with S3 now working.)
On Friday, 14 March 2014 09:59:16 UTC-7, Ross Laird wrote:
I have been trying for quite some time to get my static files onto
Amazon S3, and I just keep running into show-stopping issues. And I think
that my problems with S3 have revealed a flaw in my basic Mezzanine
configuration. Once I activate the S3 setup for static files, I get an
error like this:
UncompressableFileError: 'css/animate.css' could not be found in the
COMPRESS_ROOT '/home/rosslaird/static' or with staticfiles.
The folder 'rosslaird/static' does not exist and should not be part of
my Mezzanine configuration. On the other hand, my site runs just fine
(until I add the S3 configuration). I expect that 'static' is being
appended at runtime, and that '/home/rosslaird' is the offending part. It
does appear in my wsgi file:
from __future__ import unicode_literals
# Virtual environment on Python path
import site
site.addsitedir('/home/rosslaird/.virtualenvs/
mezzanine3/lib/python2.6/site-packages')
import os, sys
sys.path.insert(0, '/home/rosslaird/m3/zeni_core')
sys.path.insert(1, '/home/rosslaird/m3')
sys.path.append('/home/rosslaird')
os.environ['DJANGO_SETTINGS_MODULE'] = 'm3.settings'
import django.core.handlers.wsgi
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
The offending folder also appears in my apache configuration, but I
think that the actual problem may be in the wsgi settings above. Or, at
least I should find out if the above is broken first, before looking at
Apache as the culprit.
Whatever the cause, this issue also results (with the S3 settings
activated) in django-compressor looking for files in one folder above the
place where the files actually are. For example, I've received various
error messages in which django-compressor looks for 'css/whatever.css'
rather than 'static/css/whatever.css'. But every way that I've tried to
change the paths for djangoo-compressor to search the proper path seems
not
to work. And my S3 paths and settings seem correct:
AWS_SECRET_ACCESS_KEY = 'my_key'
AWS_ACCESS_KEY_ID = 'my_other_key'
AWS_STORAGE_BUCKET_NAME = 'ral_mezzanine'
AWS_QUERYSTRING_AUTH = False
STATICFILES_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
DEFAULT_FILE_STORAGE = 'storages.backends.s3boto.S3BotoStorage'
STATIC_FILES_BUCKET = 'ral_mezzanine'
S3_URL = 'https://%s.s3.amazonaws.com/' % AWS_STORAGE_BUCKET_NAME
STATIC_ROOT
[mezzanine-users] Keywords and other apps
I have read the
descriptionhttps://groups.google.com/forum/#!searchin/mezzanine-users/keywords/mezzanine-users/LGxEfHgxPok/AbsrnPlaIp4J
of
the changes to how Mezzanine handles generic relations, but I don't really
understand the programming aspects well enough to know if I'm going to have
trouble with my approach to removing generic references in other apps (such
as the events app https://github.com/stbarnabas/mezzanine-events). For
example, when I did the initial migration for the events app, I got the
error message about conflicts with South:
Your project contains migrations that include one of the fields
from mezzanine.generic in its Migration.model dict: possibly
KeywordsField, CommentsField or RatingField...
Josh had already given me a hint about that error message, with regard to
another app (my fantastic theme app http://mezzathe.me/, crafted by
Josh), so I just did the same thing as previously: I commented out the line
that referred to the keywords. Here's the line I commented out:
#'keywords': ('mezzanine.generic.fields.KeywordsField', [],
{'object_id_field': 'object_pk', 'to': orm['generic.AssignedKeyword'],\
'frozen_by_south': 'True'}),
After doing this, the events app migrates fine and works fine. But I
suppose I'd like to know if there are likely to be any unintended
(negative) consequences of just arbitrarily knocking out an entire line of
code from an app. I've now done this for two apps, and I expect I might
need to do it again, as I add new things. So, before I go too far down the
road of just blithely commenting out code blocks, I should know a bit about
what might happen.
Can anyone offer any insight about this?
Thanks in advance.
Ross
--
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: step by step mezzanine deployment
I don't actually use Fabric, so I have been a bit hesitant to make suggestions here. But my guess is that you have one problem and one problem only, and it just keeps changing how it looks depending on what you do. To step through a solution to this, I would take Fabric out of the equation and get the database connection running properly from the command line only (using pg_dump, pg_restore, and syncdb). If those commands work from the command line, then the problem is in the Fabric configuration. If those commands do not work from the command line, then you have a connection problem that sounds like it is related to permissions. In that case, try using psql from the command line to see who owns the database you are trying to connect to. Take as many things out of this equation as you can. Get right down to the core of it: who owns the database, what it's called, what its permissions are, and so on. Your problem lies in one of these areas, I think. Everything else that you try to do (using Fabric, Django, etc.) will fail -- and will give you different error messages -- until this one thing is resolved. Here's a working example. On my live system, if I type psql then \l (that's a backslash, then the lowercase letter L), I see this kind of thing: rosslaird=# \l List of databases Name| Owner | Encoding | Collate |Ctype| Access privileges ---+---+--+-+-+--- db_name | joe | UTF8 | en_US.UTF-8 | en_US.UTF-8 | other_db | mary | UTF8 | en_US.UTF-8 | en_US.UTF-8 | third_db | ed| UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | ... (8 rows) I can see, very easily, who owns what. Then I can look at the permissions of the user who owns the database in question, by typing \du (backslash, the lowercase letters D and U). Start there and see what you find. On Tuesday, 4 March 2014 00:05:31 UTC-8, Federico Bruni wrote: 2014-03-03 23:33 GMT+01:00 Ross Laird ro...@rosslaird.com javascript:: Postgresql authentication can be tricky. You may need to make changes to your pg_hba.conf file. Like so: # Database administrative login by Unix domain socket local all postgrespeer # TYPE DATABASEUSERADDRESS METHOD # local is for Unix domain socket connections only local all all peer # IPv4 local connections: hostall all 127.0.0.1/32md5 # IPv6 local connections: hostall all ::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. #local replication postgrespeer #hostreplication postgres127.0.0.1/32md5 Ross, thanks for the tips! My pg_hba.conf is exactly the same. Also, this tutorial might help: http://rosslaird.com/blog/building-a-project-with-mezzanine/ I realized that I was not using the correct owner of the database on the server I've tried changing listen_addresses to accept any using * (as in your tutorial) and now I get a different error, which I translate as: no entry in pg_hba.conf for host x.x.x.x, user project, database project, SSL disabled The host is my public IP. It's listening to any address but it needs a specific entry for my IP, so I've added: hostall all x.x.x.x/32md5 I've repeated the commands above to sync the databases and I got no messages in the terminal. However, the problem persists. I've also tried to repeat the deploy with 'fab remove fab create fab deploy', but it's not using my database. My last option is manually dumping the database. So I tried: 1. fab create 2. pg_dump -Fc dbname db.dump (on localhost and copied db.dump on the server) 3. pg_restore -d project db.dump (on the server) 4. fab deploy But I get some errors when I run pg_restore and when I run 'fab deploy' I get this error: django.db.utils.ProgrammingError: ERROR: permission denied for the relation django_content_type I'm starting running out of hope... Your tutorial about deployment is still on your TODO list? -- 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
Thanks for the great work, as usual. On Wednesday, 5 February 2014 12:50:42 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.
Re: [mezzanine-users] Re: Bootswatch Theme: Navbar doesn't display expected color
Same goes for this bit:
.navbar-inverse .nav .active a, .navbar-inverse .nav .active a:hover,
.navbar-inverse .nav .active a:focus {
color: #ff;
background-color: #11;}
On Tuesday, 28 January 2014 19:43:28 UTC-8, Ross Laird wrote:
This got me thinking. Here's the short answer:
Change the highlighted colors to your desired background color and
gradient colors:
.navbar-inverse .navbar-inner {
background-color: #1b1b1b;
background-image: -moz-linear-gradient(top, #22, #11);
background-image: -webkit-gradient(linear, 0 0, 0 100%, from(#22),
to(#11));
background-image: -webkit-linear-gradient(top, #22, #11);
background-image: -o-linear-gradient(top, #22, #11);
background-image: linear-gradient(to bottom, #22, #11);
background-repeat: repeat-x;
border-color: #252525;
filter:
progid:DXImageTransform.Microsoft.gradient(startColorstr='#ff22',
endColorstr='#ff11', GradientType=0);}
That will do it.
On Tuesday, 28 January 2014 19:33:34 UTC-8, Ross Laird wrote:
These kinds of things can be tough to assess, at a distance, without
actually diving into the CSS code. One way to debug this is to use a
customized CSS file that loads after the Mezzanine and Bootstrap CSS files.
Changing the Bootstrap CSS directly won't always yield the results you
desire, as various parts of the Bootstrap code are interconnected (through
cascading) in ways that can be hard to track. Generally, you will be better
off copying the CSS that applies to a given element, creating a new set of
rules for that element in your custom CSS file, and hacking away on your
own code. If this is an element issue (such CSS applied to a div), it
should be fairly easy to find. If it's a cascade issue, it can be messy.
(Use, with caution, temporarily, and only as a last resort, the !important
flag to make sure that your rules are loaded and not Bootstrap's).
Also, Bootstrap's use of background-image is discussed in threads like
this
onehttp://stackoverflow.com/questions/14729468/twitter-bootstrap-static-nav-bar,
which explores both options (changing Bootstrap, and creating custom css).
Also, background-color will always lie behind background-image. (The spec
is here http://www.w3.org/TR/css3-background/#the-background-color.)
So, this suggests that one line of action might first be to remove
background-image properties to get a look at what's behind everything. Then
you can selectively add things back in.
In the case of Bootstrap, most of the background-image rules do not
actually load images but rather specify gradients, which will override any
previously-declared background images (more
herehttp://www.heresonesolution.com/2010/09/using-a-css-gradient-and-a-background-image-on-the-same-element/).
So, these various interactions can be quite complex. Start with what you
can see when you take almost everything out, and go from there.
On Tuesday, 28 January 2014 18:49:47 UTC-8, Gordon Agress wrote:
No, a Chrome console search for #navbar-inverse comes up empty on the
page in question.
I think there is something in bootstrap-theme.css that introduces a
background-image: fixed-gradient, of a white color, that sits atop the
background color. When I edit base.html to comment out
bootstrap-theme.css, this issue goes away.
The footer background color issue seems to emerge because mezzanine.css
sets a value for the footer background-color, which is not overloaded by
the Cyborg theme. I patched with an additional piece of CSS to provide
that overload.
One other issue is that the 'Blog' title is overlapped by the navbar.
I'll tackle that in the morning.
I'm new to CSS, and so first suspect operator error, but it looks little
like there have been changes to the base Mezzanine layout and CSS that
haven't been accomodated by Cyborg.
I'm pretty sure my fixes can be incorporated into the CSS more smoothly.
On Tue, Jan 28, 2014 at 8:06 PM, Ross Laird ro...@rosslaird.com wrote:
Do you have the navbar-inverse class applied? That might play a role
here.
On Tuesday, 28 January 2014 12:24:39 UTC-8, Gordon Agress wrote:
I'm trying to use the Bootswatch theme 'Cyborg' with Mezzanine, but
the navbar is displaying as if its background color were white (rather
than
black). I've checked the computed CSS styles, the background seems set
properly, but there are items sets to white, and I suppose these could be
dominating the background color setting.
Still, the Bootswatch site has a nav bar, in black. So something
seems off here.
Has anyone else had similar issues with the Bootswatch templates?
--
You received this message because you are subscribed to a topic in the
Google Groups Mezzanine Users group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/mezzanine-users/wFraHvB4Sf0/unsubscribe
