No icons are showing - Add a check to see if it is necessary to fix anything before assigning a new object

Unfortunately, i have the same problem too, I just installed the module on my Drupal 7 - Goddady hosting account, and the error lines described above appeared in every visited page.
I'd just like to know if there is any chance of a fix anytime soon, if not, i'll have to go back to Drupal 6.20.
Thanks in advance,

Nino.

same here

I have the same problem. Block is not shown at all.
Icons near language names in node's links works.

Ok. I have found how to configure this module correctly.
I have used dev-version.
Open admin/config/regional/language/configure and check all methods of language determination.
Check if block is visible.
I can see it now.

I think information about module configuration should be described in README file.

Could you try applying the patch at #1005144-3: Doesn't differentiate between node and language switcher blocks and tell me if that fixes this for you?

I was contemplating over whether to set this to 'feature request' or 'task'. I went with task. This is surely not a bug, since it has to do with the user not properly configuring all required settings. I then thought that this belongs to documentation too, but since there is something that can be done through code, I chose to switch it to 'miscellaneous'.

I think it has to do with not configuring the 'Detection and selection' methods (../admin/config/regional/language/configure) as Vlad pointed out in #5. After setting these and saving them the block does come up. Perhaps there should be:

1. A check to see if more than one language is added (other than the site's default). If not, then trow a warning to the user linking to the 'Languages' page (../admin/config/regional/language), urging them to add at least one more.

2. A check to see if the 'Detection and selection' options are set. If not then trow a warning to the user linking to that page and urging them to configure them.

3. A check to see if the language switcher block is enabled for the current theme (IOW if the block is placed in the 'disabled' region). If not, then point the user to the block config page and ask them to place the switcher block to a region.

The message/warning could be like this:

To be able to use language icons you need to:
- Have more than one language enabled for your site (you currently have only 1). Please go to the Languages configuration page and add at least one more.
- Set the detection and selection options for your site.
- Place the Language switcher block in a visible region of the theme(s) you want it available in. You can do that in your site's Block configuration page.

This message should not be 'static'. If any of these requirements are met, the corresponding line should not show. If all requirements are met, then the message itself should not be displayed at all.

Thanx in advance for taking the time to read all this and for considering my suggestion.

...in the meantime, the solution/workaround for this to 'manually' go through the 3 steps mentioned in #7 and check if requirements are met. This should definitely go to the README.txt.

1. A check to see if more than one language is added (other than the site's default). If not, then trow a warning to the user linking to the 'Languages' page (../admin/config/regional/language), urging them to add at least one more.

This isn't really the job of this module. If they only have one language, they won't have any language to switch to either. I'm sure most users are smart enough to figure this out by themselves...

The rest... could be done in Language icons, but I'd prefer to just put it in the README.txt. Patches are welcome. :)

Point taken Frederik, but still (not trying to advertise the book or anything) most people fall under the "Don't make me think" category:

...When we’re creating sites, we act as though people are going to pore over each page, reading our finely crafted text, figuring out how we’ve organized things, and weighing their options before deciding which link to click.

What they actually do most of the time (if we’re lucky) is glance at each new page, scan some of the text, and click on the first link that catches their interest or vaguely resembles the thing they’re looking for. There are usually large parts of the page that they don’t even look at.

...

From a review of the book:

...The main premise of the book is that the most important thing you can do to make sure your web site is easy for people to use is not to make them think.

Now... I know it refers to websites, but in real life the same happens to README's. That's one of the main reasons that we have so many support requests or "false alerts" of bugs that never check out. Nobody reads the f**king manual. I confess that I read it only when I am faced with problems - not before installing/using as I am supposed to.

I've an issue probably not directly related with this module, but regarding the usage of the icons:
I've followed the 3 steps, and everything seems works in the proper way (icons appear, no error message, right language switch).
But after a while i noticed enabling "URL" method it breaks my breadcrumbs and they're not working anymore... it adds me a "language_code" in front of every content and the link have a wrong url.

Ex.
Home » it » Galleria » Test
Home » en » Gallery » Test

Also clicking "Gallery" or "Galleria" it gaves me http://www.mysite.it/it/it/galleria or http://www.mysite.it/en/en/node_transalted... that both url are gives "Content not found" page, caused by the doubled language code.
If I deactivates "url" in "Detection and selection" everything works as expected, except the language icons... the block appear, the links to switch language works properly, and my breadcrumbs are ok, but the icons are not visible, just a rectangle around. And the error message, of course.
Peraphs it's an i18n issue (currently i didn't find anything on drupal.org) but why this module can't work properly deactivating the "url"?
Do you have guys a solution for that?

@elgandoz: Please open a separate issue for separate issues, and I'll help you look into it.

I had the same problem, both with alpha and dev release, even following the instructions mentioned.

I tried to make some changes to the file languageicons.module in order to solve the error messages and now the flags are showing.

I am attaching a diff file for you to see the changes that I've made.

Thanks rofranco! I applied changes and icons appeared also for "Session" mode of "Detection and selection".

Unfortunatelly another errors apeared connected with this fix. I am new at php programming and I am not sure hot to fix it.
Now I have error:

Trying to get property of non-object in theme_links() (line 1452 of C:\wamp\www\drupal-7.0\drupal-7.0\includes\theme.inc).
Trying to get property of non-object in l() (line 2312 of C:\wamp\www\drupal-7.0\drupal-7.0\includes\common.inc).

...the problem is in line like this:

          && (empty($link['language']) || $link['language']->language == $language_url->language)) {

What is the best way to fix the problem? Should I modify theme.inc file? Is the right way?

You're right. I had disabled error displaying and wasn't aware of the problem.

I've made the changes in a different way and now there are no errors as far as I can see.

You don't need to touch anything but only to apply the changes to the file languageicons.module.

I'm attaching the diff file.

It works! Thank you.
I think this should be also fixed in release version.

@freso: what do you think about Rodolfo's approach to solving this issue Frederik?

@rofranco:

I get the following warning after applying your latest patch:

Strict warning: Creating default object from empty value in languageicons_language_switch_links_alter() (line 71 of /var/www/www.hseah.srsa.local/htdocs-secure/sites/all/modules/languageicons/langu...).

@jmbsvicetto:

The code that I made is just a workaround. Your warning message means that I am "implicitly" creating a default object.

I just saw that somewhere the system was expecting an object with a certain attribute, and I just "filled the gap". Right now I don't have the time to see which kind of object the system is expecting. Maybe someone in the development team can provide a permanent fix using my code as a hint.

If you write it like this instead:

$lang_obj['language'] = $langcode;
$links[$langcode]['language'] = (object) $lang_obj;

You wont get a strict error.

Made a patch from the code in #20

And same in a -p0 patch format, since drush_make don't understand the -p1 patch format, but the -p0

#21 works for me, thanks.

Hi!!

I've seen that there is a new version of the module available, but I would like to know if this issue has been fixed before installing it.

Regards.

Nope, this issue's state is "active". You'll know when it's fixed, because then the status will be "fixed" ;)

When using path prefix fix_object_language-f0-1027054-22.patch will trash an existing object which removes the path prefix. Just adding a check to see if it is necessary to fix anything before assigning a new object.

Thanks, chemical! That fixes the actual issue described in the topic.
I'm wondering why this fix has not been applied yet.

...perhaps because of this ;)

Actually this is pretty straight-forward and it works for me for some months now in a few installations without any issues. So, marking as RTBC.

...actually changing the issue's title to better reflect the code change in the patch from #26.

@chemical: Hey Michael, I've updated the issue's summary to conform to the issue summary standards. Could you please update the issue's summary (the "Proposed resolution" section, "The patch solves the issue by" part) explaining the proposed solution in detail so that the maintainer doesn't have to go through the whole issue in order to figure this out. This way we'll hopefully get this in sooner. Thanx in advance and thanx for providing the patch ;)

...marked #1159124: No icons are showing, getting errors as a duplicate of this. Which gives me the opportunity to change priority for the issue to "major". If you look at it from a broader point of view, this could be classified as "normal" (since the users can still change their sites' language), but if you look at it from the perspective of this module's purpose, it is rather "major" since its functionality (adding language icons) is completely lost.

Also, Frederik (the maintainer of this project) seems to not have enough time for this project (he still seems to be pretty active with other projects lately though). You can also tell this by the project's status that is set to "Minimally maintained". So, I've kindly asked him to update the project's page with a request for (co)maintainers: #1423572: Seeking co-maintainers for the Language icons project.

Lets hope someone steps up soon ...and that I have not offended Frederik in any way :/

Alright guys, I'm finally looking into this again. Sorry about the long wait!

Looking through the issue's history and the patches supplied, it seems that klonos actually points at the root of the problem in comment #7, while all the patches simply "hide" it. Does the recent patch (in #26) work properly (ie., not producing any unexpected behaviour) even in enviroments which are not correctly set up (as per #7)?

I've committed the patch from #26 to 7.x-1.x and 6.x-2.x (lots of Scandinavians involved, eh? :)) for now. I'd still like to have my questions in #32 answered before marking the bug "fixed".

I'm going to make an RC release shortly, which you can use to test this, if you do not want to use the -dev release.

...conforming to the issue summary standards and linking to the latest working patch.

Updated "Proposed resolution" section

Freso, IMO #7 is off-topic (no offense) . OP complaints about messages after (correctly?) installing this module.
#7 considers general installation guidelines.

First my case: My installation contains both disabled languages and user-defined languages (like 'nl-BE') for which -obviously- no icon exist. I installed/enabled (an old version of) languageicons (LI) on my site. Which resulted in OP's message. Updating to latest version (including #26) did NOT resolve this. Then I took a closer look at the path of the message. It appears the message is from a very old and disabled feature. Huh??? I removed the features altogether and all is fine..
So, #26 resolves OP's issue.

IMO the cases in #7 do not belong to LI. They belong to the Language Switcher blocks, no LI. This module contains a nice API which is a.o. used in Language field , for which you do not need Language Switcher.
Klonos is right, the settings of Language Switcher may be difficult. For example, I don't understand why you would need to enable DETECTION METHOD settings 'URL' or 'Session', and why (out of the box) 'User' wouldn't be enough??
But then again - it is not in scope of this module.

The only improvement I would make, is to add the [31626648]

@johnv
'User' detection is not changeable in the client area, is fixed value, is a value only changeable in the admin area. The user must go into his profile and change it.

'Browser' detection method is fixed too, the language provided by browser in http request headers. 'Default' is obviously fixed too, is the default language configured in admin area.

Only 'URL' and 'Session' are changeable on client area and for those makes sense to have a language switcher not for the rest of methods, not for the fixed ones.

You can use as many detection methods together as you want giving preference to one or another but if you want a language switcher you have to have at least enabled one of 'URL' or 'Session' language detection methods.

For example you can use 'Session', 'User', 'Default' with that order and the site will get User defined language on load (because still not a session value) and use the language switcher block to allow to change language for the current session (not to confuse with the user configured one in profile which won't be changed so next time the user comes to your site in a new session the loaded language would be the one configured in his profile again).

Language handle in drupal 7 core is very flexible and with that flexibility comes great complexity. For example it even has the ability to have different language for user interface and for content at same time which makes things even more difficult to understand. This happen for example when you install a module like "Entity Translation". After that you have two different configurable language negotiation types: "user interface text" for the interface language, "content" for the content language, under "admin/config/regional/language/configure". Most of the times you will want these two negotiation types sharing same detection method so when a language is changed (the language for the interface for example) the other is changed too (the language for the content). But there is the possibility to have different detection for each and different language switcher for each too.

#5 Worked for me!

...just wrapping code with proper tags ;)

@johnv: It's fine and dandy that you set it back to "needs review", but you didn't specify what needs to be reviewed. As I said in comment #33, I committed one fix for this issue a good while back. If people no longer experience the issue with latest 7.x-1.x or 6.x-2.x, then this issue should be "fixed", not "needs review". If there's still an issue, please actually post what the issue is and preferably also a suggested way forward (e.g., which comments/patches to re-consider).