My issues at drupal.org

The form at user/[uid]/edit should use an email form element.
It seems, according to [#316886] that a form_alter won't cut it here.
Haven't worked it out yet, mabe somebody else wil have a pointer.

Small comment fix

The testing profile does not enable required modules like node but uses its permission 'access content'. This leads to a fatal error during testing_install() using drush. Attached patch adds one dependencies[] line to testing.info which is enough to kick in the dependency check and thus all required modules are enabled. Patch also adds a customary files[] = testing.profile like other profiles.

Although this module has been around for longer,
the momentum is currently behind
http://drupal.org/project/html5_tools.
Perhaps this module should be deprecated and efforts continued there.
Alan

Have not investigated why this happens as yet.

Coming from #769226-154: Optimize JS/CSS aggregation for front-end performance and DX and also identified the need for this in contrib just recently, we want to

1) make system_list('module_enabled') return full module records instead of just module names. system_list() is only invoked by module_list(), and hopefully/likely not in contrib yet, so this is an API change, but a small one.

2) due to 1), system_get_info() can re-use that information to build module/theme information. I've added a static cache, because of the unserializing of all the info data.

3) Ideally, I'd additionally like to change system_get_info()'s $type parameter to be consistent with system_list(), i.e., 'module_enabled' and 'theme', and eventually add 'module' as an option. That would be a giant help for #624848: Allow to retrieve a list of modules defining a certain .info file property

I can't bear to sit through another version of Drupal, while Front-end developers complain and propose to remove ALL CSS from core. There is a lot of work to do in this area, but as a whole, front-end developers (especially new ones) are so disgusted by Drupal's CSS, their first instinct is to remove it all and rewrite their own. This is reaction is understandable, but it's wrong. Until we do something about it core CSS is not going to have a shot of improving because no one wants to be associated with it. We need to stop the bleeding.

I'm also sad that work we have done in Drupal 7 to clean up CSS files has been completely reverted (unintentionally, but still) as the development cycle goes on. I realize it is late in the cycle, but I really think this is critical. I also think that it is the perfect time to work on some of this, because patching activity is down, which makes the task somewhat less at this point.

I'm not proposing that we change the CSS itself too much, that would be insane at this point, but I am proposing that we fix the organization of it as much as possible. What does that mean?

• Add more comments, and make them consistent.
• Ensure admin-only CSS is in admin.css
• Ensure generic defaults are in system.css

read more

, , ... how to we make IE *see* them. So we can write CSS to them, and have it work?

We use this js: http://remysharp.com/2009/01/07/html5-enabling-script/

I found this bug from an install of 7.0-alpha6. contrib modules being used: dialog, jquery-ui, skinr, devel.

Basically it appears that any module that is meant to append links to the node (comment, node, blog, statistics) instead of adding them to the links array and printing those out in one UL, prints them each out in its own UL...

What drupal is giving me is:
<ul class="links inline">
  <li class="node-readmore first last"><a href="/node/4" rel="tag" title="Magna Patria Iusto Wisi Loquor">Read more</a></li>
</ul>
<ul class="links inline">
  <li class="blog_usernames_blog first last"><a href="/blog/4" title="Read histenedad&#039;s latest blog entries.">histenedad&#039;s blog</a></li>
</ul>
<ul class="links inline">
  <li class="comment-comments first"><a href="/node/4#comments" title="Jump to the first comment of this posting." property="sioc:num_replies" content="4" datatype="xsd:integer" rel="">4 comments</a></li>
  <li class="comment-new-comments last"><a href="/node/4#new" title="Jump to the first new comment of this posting.">0 new comments</a></li>
</ul>
<ul class="links inline">
  <li class="statistics_counter first last"><span>236 reads</span></li>
</ul>

Hi - any statement on a Drupal 7 version?

Hi There
Trying to restore a DB created with backup migrate.
When getting a list of destinations, with
drush bam-destinations
I run into this error.
Initialized Drupal site runireland.com at sites/runireland.com                                                             [notice]
Warning: The command callback function backup_migrate_drush_destinations has a deprecated name.  It must begin with        [notice]
drush_backup_migrate_.  Skipping hook functions.

Any ideas?

The resources tab of the developer tool that comes with Chrome/Safari shows that all background images within the CSS file get downloaded, regardless of whether or not they are shown.
So the CSS sprites file overwrites rule is used to display the image, but the image file is still downloaded in the background.
I guess it's just being smart - the images might get used as some point, eg with a javsascript event.

This isn't an issue with Firefox or Internet Explorer.
I ran a network sniffer to confirm this.
It's only a minor issue

In a follow-up to #849356: Does this really need to work on non-aggregated files?,
The module doesn't currently work when CSS aggregation is enabled.

I've had a look through the code, but I can't see the issue that's causing it.

On a broader sense, In terms of a plan of attack, I would suggest hooking into the CSS aggregation process, and manipulating the CSS aggregated file before it is saved at all.
This post
http://www.phpied.com/data-uris-mhtml-ie7-win7-vista-blues/
is the most comprehensive guide I could find in terms of how to manage all the different scenarios.

However, I don't like the browser sniffing employed in his example PHP class.
I think that the method used to satisfy IE on Vista would still work for all browsers [I still need to test this],
and that would be sufficient.
In this case, all background images are replaced by a single HTML file.
The original css is rewritten to point to this external css file.

Alternatively, we can do it 'properly' for normal browsers.
Rewrite the CSS file before saving the aggregated file.
And then add the 2 files in conditional stylesheets for IE7, IE6.
It does mean that they get the same information twice.

Its all a case of trade-off between satisfying different scenarios in any case.

Anyway, that's my 2c!

Alan

I ran the Coder module script through the module.
It picks up some syntax that doesn't comply with Drupal's coding standards.
Patch attached.

At the moment, this module works on non-aggregated CSS files.
I'm not sure that is really necessary.
It seem if you are concerned about reducing http requests [the aim of this module], then you'll have that enabled.

If that assumption is made, then coding could be a bit easier.
The work only need to happen when the aggregated css file is saved.

On the User interface, the setting to generate Data URIs could be disabled/hidden until the CSS aggregation box option was enabled.

Hi Dimitry
I'm continuing to test the module.
I have some thoughts on the interface.
If you agree with any of them, let me know, and I'll try to make some patches.

The overall principle I'm looking at is "Less is more".
Ideally a module should 'Just work'.
For example the jQuery Update modules simply needs to be enables in order to provide a new version of the jQuery Library.
No need for any configuration.
The pathauto module starts working straight away, but lets the user change the default settings.

So, with that in mind.

1. Settings page.
I don't know if there is a need for a separate settings page.
Ideally any configuration would be done directly on
admin/settings/performance
within the 'Bandwidth optimizations' section.

2. 32Kb per image limit
Is this setting really needed?
The reality is that IE7 and IE8 support is mandatory [from a practical point of view], so why would anyone uncheck that box?
The code could be written so as to make that available as an option if a future release [when usage of those browsers is lower], but not expose that setting to the user right now.
Is there was some extra work needed for IE6 only?
If so, then that could be an option, as many people [though not me just yet], choose not to support IE 6.

Regards
Alan

Hi there,
Just starting to use Sass, and found this module.
The Latest in the Drupal-6--1 branch is working well for me.

I've developed a theme without using the module,
so I'm just wondering what advantages the module might have over 'standard' development.
[Standard for me means one terminal for editing, one for watching ].

Thanks and Regards
Alan

Hi, Im hoping someone can shed some light on why this might be happening

This error has just started showing up after I finalise test card transactions.
"Your transaction has been successful but there was a problem connecting back to the merchant's web site. Please contact the merchant and advise them that you received this error message. Thank you."

Everything had been working fine up until two days ago. Processing the test card, sending back information about the order number, login details, etc...

I'm using Drupal 6.16, Ubercart 6.x-2.2 and UC_Realex 6.x-2.0-beta3
I have made no alterations to ubercart, drupal or this module for that mater that would/should of affected the processing.

I have been in contact with realex support and they send me back this log message and saying its something wrong with uc module.

Page logs just display the error msg : An error has occurred during payment. Please contact us to ensure your order has submitted.

Find below how the response is being handled on your page .

$VAR1 = bless( {
''_protocol'' => ''HTTP/1.1'',
''_content'' => ''An error has occurred during payment. Please contact us to ensure your order has submitted.'',
''_rc'' => ''206'',
''_headers'' => bless( {
''connection'' => ''close'',
''client-response-num'' => 1,
''cache-control'' => [
''store, no-cache, must-revalidate'',

read more

I want rip out the suggestion classes for one of my themes - at first I thought this looked strait forward and could do something like this in themename_process_html()

$classes = str_replace(theme_get_suggestions(arg(), 'page', '-'), '', $classes);

This removes the page-arg(0) bit but nothing after it, see the screen-shot as to what is left behind.

Could someone point out what I'm doing wrong here, since this is using the same function that is being used to build these classes.

The screen shot is taking when I am on node/1, so the classes added by Drupal are page-node, page-node-, page-node-1

I created this issue to focus on some small changes to ThemeAPI that will make
D7 theming much more flexible and consistent. This issue is related to #812796
and #364470. I know I'm late. But, as for D7 user I think that without small
improvement, D7 will look like incomplete.

My goal is to create D7 theme using only css and template.php files. For D6
themes I always changed following things:

- submitted message (both for nodes and comments)
- comment title (with number of comment included)

In current D7 ThemeAPI I cannot change this variables without using tpl files.
Comment title is hardcoded, submitted message is hardcoded. I think, creating
translation for submitted message to change how it looks, is not the way it
should be used. I cannot achieve my no-tpl-files goal with hardcoded variables.

What I propose is to:
- make comment title as variable (like I did in patch in #812796, for
comment-wrapper.tpl.php) - now I have to use comment-wrapper.tpl.php to add,
for example, number of comments
- do not hardcode submitted message (if not an old $submitted variable (see
#364470), then, maybe something like theme('links'), which is also quite
difficult for new Drupal themers, maybe something like a theme setting).

Any other variable can be adjusted in template.php, thus I think leaving those
I mentioned will make D7 ThemeAPI incomplete.