i18n prefix in logo path creates non-existent path

I think that part of the reason people used to have issues with defining their own paths is that they don't understand where their files *should* live. I've tried to make this simpler for the majority of users as they now don't have to specify full paths to their logos or even logo filenames with the matching config. The problem with this approach is migration... The update.php script only really copes with very basic/ simple style upgrades (which I believe/ hope (!) will be the vast majority of users) but well, it'll take a little extra thought from everyone else ;o)

...Anyways, hopefully your issue is as simple as that there are no longer leading slashes in the path configuration, so ensure your config looks like this;

Path to default/ main logo:
misc/druplicon.png

sites/default/files/logos
sites/default/files/logos

The matching works differently now as well, so as you were using the 6.1.x branch and not the 5.x branch you had to have been manually setting your path matching (as only 5.x supported locale), for 6.2.x proper logo matching is back. So e.g. you would set the locale dropdown for whatever country the logo is for and set the match to simply;

admin/*

NOTE: no other info is needed. If you're unsure, post some of your config here and I'll check over it.

Thanks,

Pobster

>warning: preg_match() expects parameter 2 to be string, array given in /var/www/web5/html/lunovis_v4/includes/bootstrap.inc on line 777.

That is from the drupal_validate_utf8 function, I'm unsure of whether this is an issue with logotool or not? Is it consistent with Logotool? If you disable the module does the error go away?? I don't get it with my test install...?

Pobster

I would very much like to have a db dump of your logotool configuration. A clean solution isn't falling back to a previous release... To avoid others running into similar issues I really need support from the community as I can't foresee every eventuality. If I can recreate the conditions you have, then I can fix things a lot easier.

Thanks,

Pobster

Okay I think I've figured out what happened with the upgrade... Maybe I should provide an UPGRADE.txt...

For a start, there's no real clever way I can parse the i18n part in your url as I can't just presume that anyone who uses a language prefix *is* actually using i18n... (i.e. en/..., es/..., etc who can tell if that's just a path alias?) Part of the reason I rewrote the module is that the new way the matching works means you shouldn't need to prefix with anything (see below!) not even the i18n prefix - you'd select that from the separate language dropdown. Hence this part will always need to be manually altered and this really should be documented.

As you pointed out, your logotool table was empty so you didn't even get that far... This puzzled me for a while but I've come to the conclusion it's because you ran the upgrade before you updated the settings (as I mentioned above the paths are different) the urls are different now as are some of the defined variables. Completely not your fault! There's no way you'd know... Bit of an oversight on my part... I really should have documented that you need to check your file paths as the new way the module works, the logo files are actually stored in the {files} table and linked to by {logotool}.fid I'm assuming that when the upgrade ran the file_scan_directory was probably pointing to an invalid directory and hence, empty. I guess I really should have looped that scan using the old directory path using the old method. Still you can always force the upgrade to run again after the settings have been updated?

...Could you let me know if there's anything peculiar about your installation? I mean, I haven't come to the conclusion above through testing using your settings as there's nothing different about them from my own. The only other different thing would be your set up which I haven't actually asked you about yet!

Pobster

I want to confirm the same error message and problems as blecheimer. I upgraded a copy of a web site to logotool 6.x-2.0 as soon as that version came out. However, since logos were not displaying even afer a few hour of work, I put this aside.

Now today I try it again to no avail.

I deinstalled the module using the desinstall function. Installed it again.

the “...bootstrap.inc on line 777” error is still there.

In the logos page (/admin/settings/logotool/logos), logos are displayed properly and localisation set. But logos fails to display in the web page header.

I am leaving the production site to Logo Tool (6.x-1.x-dev (2008-nov.-11)) since that one works perfectly.

I suspect that errors are not in the update code since files are properly displayed in the admin interface. So it must be somewhere else.

Yes, I am using two languages on the site using language prefix in for form http://www.example.com/fr/

Are either of you willing to send me a complete db dump of your site? Failing that, steps to reproduce this from scratch? I just can't seem to get these errors on my test site and tbh, I'm starting to wonder whether it's cache or install/ server related (perhaps php error related? Do you get anything come up in your php_error.log?)

The site logo change happens in a template preprocess hook which potentially doesn't get picked up unless the theme registry is rebuilt? Could someone check that...?

Obviously the most helpful thing I could have is command line access to one of your servers but I understand completely why you may not wish for me to have this! ;o)

Thanks,

Pobster
edit: My contact form is enabled btw (and always is!) if you are particularly trusting!

Before sending any database of files, I will take time to setup a new install from scratch and use only demo content. But it might not happen anytime soon. :-)

No worries, thank you! Any help is appreciated, as obviously if I can't seem to reproduce the issue I can't really fix it!

Thanks,

Pobster

[Drupal 6.15. LogoTool 6.x-2.0. Internationalization 6.x-1.3.]

LogoTool is injecting an i18n prefix for the language into the path for the logo and this path does not exist. All logo files are in:

sites/default/files/logos/

but for French pages the page source shows the logo as having a path of:

fr/sites/default/files/logos/

I have LogoTool set to display logos randomly on all pages. No locale is specified for any individual logo. No page is specified for any individual logo. There are no leading slashes within LT's paths.

How can I force the removal of an i18n prefix from the logo’s path?

Ah excellent, that'll be it then = I've used url() in some places when I should have used file_create_url().

I'll change it, test it and roll out a new release.

Thanks for spotting this!

Pobster
Edit: oddly I've just notice that my D7.x dev version *does* use file_create_url() - so I'd obviously noticed this somewhere along the way, apologies!

Actually I am supposed to be working... Could you test this patch for me?

Thanks,

Pobster

I tested the patch to no avail.

I still get the warning: preg_match() expects parameter 2 to be string, array given in /Sites/dbn/boutique/includes/bootstrap.inc on line 777.

And logos won't display neither.

I did not have time to set a new install with i18n yet, though.

In place of the proper logo display, I have this img source:

<img alt="Home" src="http://www.example.com/sites/default/files/misc/druplicon.png">

With the results that the Home alt text is displayed instead of the logo.

Now why your module would look for misc inside the files folder! :-)

Heh, that's actually correct, it's where the default icon lives - it just seems that I was too heavy handed with my file_create_urls (which append the file directory path if it's not already present) seems a search and replace is NOT sufficient! ;o) Guess I'll need to use $base_path to prefix? Although I'm not entirely sure if that'll also contain an i18n prefix... Will test (later)...

I'll repatch a bit later but just one question regarding the preg_match error, did you truncate your cache tables (especially the one in devel which rebuilds the theme registry)? That's easy to fix if this is required... I'm just slightly puzzled as I don't get this error myself??? I really could use a db dump and/ or instructions of how to consistently reproduce this!

Thanks,

Pobster

Your patch of 22.3.2010 appears to work. LogoTool is no longer injecting an i18n prefix for the language into the path for the logo and, as a consequence, all logo files are now being found.

The module's good. Many thanks indeed.

@pobster - Thanks. Devel was disabled on my dev site. preg_match error now gone to oblivion.

Yes, now the module works with the patch.

I had to make the page paths to "*" to have the logos display on each page. So now the proper logo in English appears in all English page and the logo in French appears in all French pages.

Many thanks!

One small bug, though: adding a new logo does not always refresh the page properly. With Devel activated, it reported an haha issue.

Awesome, I'll roll out a new release when I get home then. With regards that ahah error though, is there any indication of exactly what the error is (I know the ahah ones can be a little vague...) perhaps even something in your php error log?

Thanks,

Pobster

preg_match error now gone to oblivion.

I mean, it's gone. No more errors. :-)

Done and committed, thanks everyone. If you can recreate the ahah error consistently please would you open a (separate) new bug ticket.

Thanks,

Pobster

...Just to mention there's a new release which is 6.x-2.01.

Thanks,

Pobster

I remember, the "haha" error came by only when Devel was enabled and showed in a JavaScript alert(). If I get the warning again I will create a new issue. Thanks.

Awesome, thanks. BTW, I've just (by pure chance) fixed the bootstrap error as well! Just put out a 6.x-2.02 release, hopefully it should be fairly robust now!

Thanks for the tip with devel, I'll test - thanks again!

Pobster

I just updated a web site to 2.0.1 successfully -> dbn.ca

I'll try out 2.0.2 in the next few minutes.

Thanks.

Are you using the latest code? I thought all this had been cleared up now?

Thanks,

Pobster

This issue is closed. :-)

Thank you for this module.