Noggin support seems to be a bit broken, please see attached screen shot. I am pretty sure i tried all settings but as it is my first time with an adaptivetheme and noggin I won't rule out an error on my part (hence filing it as a support request).

CommentFileSizeAuthor
#10 left.PNG18.58 KBdddave
#10 righttop.PNG24.92 KBdddave
#10 firebug.PNG92.36 KBdddave
nogginbroken.PNG51.51 KBdddave
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jeff Burnz’s picture

Hmmm, I know we had to make some last minute changes to header rendering, I better check that out - thanks for the bug report.

Jeff Burnz’s picture

Assigned: Unassigned » Jeff Burnz
Category: support » bug
Priority: Normal » Critical

Bumping, this looks like it needs to be fixed asap.

Jeff Burnz’s picture

Status: Active » Fixed

This is fixed in head (I have committed the fix to GIT, it will be in the next release).

If you want to apply this fix immediately you will need to edit a couple of files:

1. In the Noggin settings use the selector: #header .header-inner

2. In pixture_reloaded.settings.style.css, down around line 641 (at the bottom), replace the selector there also, so search replace header#header with #header .header-inner

3. In theme-settings.php, right near the top there is a block of code that overrides noggin default selector, technically you don't need to change this, but if you want you can, again replace header#header with #header .header-inner.

dddave’s picture

Thanks for the quick response. This is definitely not meant to be demanding or such but do you have an ETA for the next version?

And how would it affect me if I am using a subtheme based on Footheme?

Jeff Burnz’s picture

I'm about to make a commit for Pixture Reloaded and then push out the new version, it has a number of small fixes such as this included, so its going to be today.

Regarding Footheme - it will inherit most of the updates, however there is one small addition we made which requires you to add one line to your Footheme info file (if you want to, you don't have to), its a new theme setting to position the Menu Bar menu left, center or right.

So really its just a matter of updating Pixture Reloaded, and probably Adpativetheme as well because we need to release some fixes for that also (mainly to do with Gmap module) - then clear your sites caches and probably save your theme settings to be safe and that's it - pretty painless.

dddave’s picture

Awesome. Worked with Fusion (saddly stalling atm) and tried Omega (guess awesome for someone who wants total design freedom) and I find your themes to be a really good middleground for "lite"designers. Thanks!

Jeff Burnz’s picture

I wouldn't say Omega has total design freedom - pretty flexible layout options if you want to do that by settings, but its heavy reliance on grids makes it kind of tricky to break out of that grid, or do things like ribbon designs a bit of pita.

To be honest if you want total layout control via the user interface I would use Panels Everywhere since that is quite a bit more powerful approach (Flexible Panels, pluggable layouts, full power of CTools, Page Manager and Views etc), not to mention the drag and drop UI of Panels - a much more intuitive approach.

We'll be updating our Adaptivetheme Panels Everywhere theme to Drupal 7 around the end of this month, I'm just working up some responsive layout plugins at the moment.

Please don't confuse "easy" with "lite" - that's what we're going for here - ease of use with total design freedom - which is not easy to achieve I might add, many "other" base-themes simply resort to pushing in tonnes of crappy markup. Since we use our theme to build commercial themes the last thing we want is a base theme that actually restricts us in terms of design - or at least makes it hard, or require time consuming workarounds. It has to be fast, easy, stable and very flexible, which I think we achieved to a high degree, and it took years of development to get to this, so we know its good ;)

Anyway, I' am rambling a bit, thanks ddave, the new version of PR is out, so have a great time with it!

dddave’s picture

Version: 7.x-2.1 » 7.x-2.2
Status: Fixed » Active

Playing around with it and it doesn't seem to work well. It think I tried all settings and combinations but to no good avail.
Looking at the css with firebug shows that the custom settings like repeat etc. are applied but only to the default image via colors.css (line 64). If I deactivate this background with firebug the correct background image can be seen. So it seems to me that colors.css places its background image over the custom one.

Am I something missing here? Of course I flushed caches and installed p_r cleanly...

Jeff Burnz’s picture

Assigned: Jeff Burnz » Unassigned
Category: bug » support
Priority: Critical » Normal

What is the CSS header selector in the Noggin settings? It should be #header .header-inner

If you have CSS aggregation on you will need to clear the sites cache also.

dddave’s picture

FileSize
92.36 KB
24.92 KB
18.58 KB

Am I missing settings apart those at admin/appearance/settings/(pixture_reloaded)? I flushed chaches relentlessly and tried with aggregation on and off.

I have attached some pics where you can see the effect. First with the header image left-aligned, the second right and top aligned.

Thirdly I attached a screenshot from firebug. The one thing that changed is that the correct image now is overwritten.

Jeff Burnz’s picture

Sorry, but I have no idea what I am looking at, either I need to see it online or I can't help you, sorry but this doesn't really tell me much apart from for some whacky crazy reason your browser is not doing what it should - the color image should be overridden, so you could try a more poweful selector, like

#page #header .header-inner

dedde’s picture

Title: Noggin support broken? » Noggin - Use a header image
Component: Code » User interface
Assigned: Unassigned » dedde
dedde’s picture

Assigned: dedde » Unassigned
jgaray’s picture

This solution (comment #11, by Jeff Burnz) worked for me! I also had colors.css placing its own background image instead of my chosen one...

lagadoo’s picture

Hi,

I have Pixture reloaded as a theme and noggin module and would love to be able to add an image but everything i try does not work. Does the image have to be a certain size or type before i upload it and what settings could i change to get this working all the code seems to be correct from what i read above.

My site is Sydney Harbour bridge Climb

Thanks

Jeff Burnz’s picture

@ lagadoo - I can only see Bartik installed on your site.

lagadoo’s picture

Hi,

Yes sorry i have changed it whilst trying things out. Visit http://www.climbsydneyharbourbridge.com/ or Jorvik Centre and i had same issue of not being able to upload header to these sites.

deadanykey’s picture

Open the file "noggin.module".
Find the line 139:
drupal_add_css("$selector { background: url('$public_uri') $extra_attributes}", 'inline');

Change the line:
drupal_add_css("$selector { background: url('$public_uri') $extra_attributes} !important", 'inline');

lagadoo’s picture

Hi deadanykey,

http://climbsydneyharbourbridge.com,

I made changes to this website as suggested and nothing appears still. How is this module so difficult to get to work?

Any other ideas?

vb’s picture

Please fix changes in last nogging dev around the line 62 template.php
if (variable_get('noggin:use_header', FALSE)) {

hound’s picture

re: #20 - vb - can you, or somebody associated with this project, put the correction into a .patch file instead of making comments that are somewhat ambiguous as to what is to be changed (eg, before and after) - also, the -dev version of this module has a .patch file in the package - is that supposed to be applied? It has the same date and time as the module file. If it has already been applied then it should be removed from the package.

FYI there is no file "template.php" in the noggin 7.x-1.x-dev package, so your comment can't be applied. Perhaps you meant the Pixture_reloaded theme? Although I do not see that line mentioned above (#20) in the theme either.

Making ANY attempt to modify ANY setting on ANY Adaptive Theme (Foo, Pix_reloaded, Corolla, etc) nowpins one of the 8 cores on my server and hangs this Apache thread for 70 seconds, after which the administrative (eg theme settings interface) control returns as if nothing ever happened. Does not matter if Noggin is loaded or not. (Problem began when I ran update.php after updating to new 'dev' Noggin.)

FYI I revisited the InnoDB settings on the MySQL engine (this server has 8GB) and maxed everything out. NO CHANGE IN PERFORMANCE, it is NOT a database problem, it is some sort of race condition.

Uploading a header image file (from the Noggin upload browse box) with an embedded space in the file name (eg "My Picture.png") is a BIG NONO - because the upload works fine, but the file is NEVER FOUND OR DISPLAYED. It took me 2 hours before I finally realized that I should try with a regular file, which does in fact display. Why?

Just my $.02.

Thanks for doing this module, but it doesn't work at all at present for me, even with all the comments above this one tested.

Theme: Pix_reloaded current version (7-x.2.2)
Noggin module version -dev, .info file dated internally 5 Feb 2012

Jeff Burnz’s picture

hound, stop spamming my issue queues with your rants, its not very helpful. You are choosing to use DEV version software, expect a few problems, OK? Its your choice, you made it, not me, no one is holding your arm behind your back and forcing you to use it. Right?

You've been around Drupal for 7 years, you of all people should know this is NOT THE WAY to approach a developer, nor post in an issue queue, especially when using DEV versions.

There have been a lot of changes to Noggin and it will take time to update all the themes to work with the new versions, but I am NOT going to do that until Noggin dev is stable and ready - new changes are happening right now. So be patient and pull your head in, your behaviour is atrocious.

Jeff Burnz’s picture

OK people, I have been working on Noggin today (many hours...) and have updated the DEV version and Pixture Reloaded as well (DEV), and tested them so they are working together.

Remember, Noggin dev has database updates if you are "up grading" from the 7.x-1.0 version.

The code won't be available until Drupal.org rebuilds the DEV releases, so sometime over the next 24 hours that will happen.

What I have done is remove all the custom noggin settings from PR, instead these are now built into Noggin itself, there are other goodies and extras going into Noggin also, I need to update the README also, not done yet...

One causualty of the recent updates is that PR will no longer automatically set the correct selector for you, you will have to do this manually until such time I get that working again, the selector you must use is:

#header .header-inner

hound’s picture

A) The embedded-space issue. That seems like a helpful problem report, and I specified the versions in use. Is it a real issue? It was 100% repeatable to me, but perhaps you have changed it in the soon-to-be-released versions of your various contributions.

B) The database issue. Question. Have you seen anything like it? Have you tried using MyISAM tables instead of InnoDB? (I mean not have you experimented because of my report; rather, have you noticed a difference in behavior or performance generally - maybe not even with regard to Noggin or any ot the Adaptive Theme stuff, just generally in re: Drupal?)

C) Comments are never aimed at the developer. Developers work hard without pay, and no good deed goes unpunished. I am a dev myself. Thanks for your contributions!

All my comments are here to try to help other people - and 'other people' includes, as a class, the developer, plus any users, and any prospective users. If you are a user with an issue, it's better to be able to find out if others have similar issues. Ergo, my comments might possibly help someone else decide to wait until a module - not specifically this module or theme, but others I have commented on - is more mature. The 'heat index' on an issue queue is often enough to dissuade people with mission-critical needs from taking a chance on a '-dev' module. That's a good thing for them - and for the developer, too. Less complaints.

Have a great day.

Jeff Burnz’s picture

hound - you are about as likely to get any support from me as hell is to freeze over.

sodafox’s picture

I am generally having the same problem with not being able to see my custom header after uploading it using noggin. I really appreciate the hours of work and effort. Has anyone had any success with anything so far. I am getting confused with what to try at this point.

Jeff Burnz’s picture

sodafox - need more details and can you please open a new issue, this is getting pretty long and I think I will close it for now, need details such as what versions you are using of PR and Noggin.

danoguru’s picture

Title: Noggin - Use a header image » Noggin - Use a header image SOLVED #11

I had the same problem, that my custom header image was overwritten by the default PR header.

I use:
Pixture Reloaded 7.x-2.2
Noggin 7.x-1.0

replacing

#header .header-inner

with

#page #header .header-inner

as suggested by Jeff in comment #11 solved the issue for me.

Jeff Burnz’s picture

I really must make a new release for Noggin module, I keep trying to find the time, the dev version is actually pretty cool.

JimmyAx’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

david_garcia’s picture

After a more than 10 hour dealing with the compatiblity problem between noggin and Pixture Reloaded I have come to the following conclusion:

- The proposed solution (changing the css selector to point to the .header-inner) is not an acceptable fix as the original Pixture background managing is done in the #header div. Using the proposed fix leads to sizing problems because the original Pixture theme does harcoded header sizing (using max-height) to acommodate de default gradient background.

To me, this is more a bug in the Pixture reloaded theme than in the noggin module, but I have no experience whatsoever in contributing to drupal so I hope someone will read this post and make it useful for everyone.

The main problem with the Pixture module is that the gradient background is applied to the .header-inner div but the actual size of the header is set using the max-height property of the #header div, wich leads to overlaping objects when the header's contents are too big.

The "good" solution to replace the default Pixture header with a new one is:

- Clear the background of .inner-header (nogging will apply the background directly to the #header div)
- Do not change de fault #header selector in noggin
- Remove the max-height constraint from the #header div, so that the height established using the header-height option in the noggin module will work. As a consequence of this change, you must set the height property (or custom min-height) in the noggin module so that the header will not colapse when empty.

This can very easly be approached using the following custom css:

#header .header-inner { background: none !important; }
#header { max-height: none !important; }

By using this custom css, you will be able to insert a custom image as the header image without sizing or overlapping issues. Just remember to set the header's height (actually better to use custom css to set a min-height) in the noggin module because if the header is empty it will be fully collapsed because it has no content and no minimum height.

Greetings!

rikypalmer’s picture

Project: Pixture Reloaded » AT Commerce
Version: 7.x-2.2 » 7.x-3.x-dev
Priority: Normal » Critical
Status: Closed (fixed) » Active

Problem with Noggin and at commerce

roball’s picture

Project: AT Commerce » Pixture Reloaded
Version: 7.x-3.x-dev » 7.x-2.2
Priority: Critical » Normal
Status: Active » Closed (fixed)

Reverting.

The Noggin module 7.x-1.1 works fine together with the AT Commerce theme 7.x-3.0-rc1. Just tested it. The only problem I found is documented here: #2062319: adaptivetheme/at_commerce_files/* will be replaced by their default ones on every new save.