Type juggle settings?

How odd, I use this operator extensively because its faster to check equality and type, I assume this must be a string. No problems, easy fix.

I'm looking at this and wondering why my In Pace Editor looks nothing like yours - the screenshots show a nice styled editor with gradient and icons, mine looks like crap - its purple with budget styles all round. I have never used this, can you advise?

The breadcrumb being "yes" is an odd reversion, I know I updated that at some stage so its been reverted somewhere along the way.

Let me know if you have any other issues, I do not want to change all the comparison operators at this stage, I use equality + type all over the place and no one else has mentioned such issues. For example even if the default value is "yes" and you check the setting it will save as value 1 (an integer). Type checking seems problematic on your system, because I cannot reproduce either of the issues you have described - not with breadcrumb or the In Place Editor classes.

Maybe if there is a way for you to share your database and theme with me, either send it to my email using the contact form or skype me etc, jmburnz. Tell me what operating system you are using and version of PHP etc.

I asked to see your files and database, at this stage that is what I really need.

I have seen this issue with missing IPE editor icons in AT, however I can't seem to reproduce it now.

The IPE (vastly improved in panels-7.x-3.1) looks like this out of the box, as far as I know there's no custom Panopoly additions to it.

Baah, reverting changes, silly Dreditor.

I don't see this problem in my Panels in-place editor or breadcrumb (no Panopoly distribution, just normal Panels in a standard typical D7 installation). My guess is this looks like a conflict due to Panopoly distro customization or something else.

@Petemoss Yeah this certainly could be a conflict with Panopoly. However as I said I've seen this same issue without Panopoly. However as I can't replicate it now then it's an academic point really.

Well, prior to yesterday nuking the icons would have been entirely reproducible, simply by turning OFF the Extra Menu Classes in theme settings - that would have removed all classes/attributes from link items and killed the icons. However, I actually removed the entire theme_links override because, in short, it wasn't really doing much.

I think the main issue being asked about is the ubiquitous failure of the === operator, which I cannot reproduce, and certainly would have noticed over the last 4 months of development. I made the decision really early on to use equality + type checking because its faster (up to 25% faster than ==), and in places where this was not an option its not used. Yes this is micro-optimization but this theme strives for performance in every nook and cranny.

I have been very mindful of this operator and potential issues. The main problem for me in dealing with this particular issue is not being able to reproduce it.

Updating title, theme_links is not overridden in latest dev.

Awesome, thanks for the heads up sylus.

I wonder if for pure safety we might type juggle the checkbox settings, one way I think we could away with this is doing in at_get_settings(), which is AT's replacement for Drupal cores theme_get_setting().

I've dug right into this after more poking by sylus and to be honest, it is a bit baffling with regards to how and where the checkbox values are cast. The array_merge() in at_get_setting() is strait from theme_get_setting(), it works mostly the same, so I do not think this is a theme specific issue, other than using stricter comparison operators than most other themes.

      // Type juggle numeric strings, cast to integer
      foreach ($cache[$theme] as $setting_name => $setting_value) {
        if (is_numeric($setting_value) && strlen($setting_value) == 1) {
          $cache[$theme][$setting_name] = (int) $setting_value;
        }
      }

I had to release RC4 due to an issue with panels settings so I pushed this into the release. I tested this heavily and it shouldn't make any difference, at least theoretically speaking, since AT always tests checkbox settings as if they are type integer, and this implicitly casts any setting that is numeric and 1 char string to integer (I cant really think of safer way of testing for such settings than this, if you can, I am all ears).

Its possible we could get away with either of those function calls (I mean just one, either is_numeric() or strlen(), since I do not believe I have use any numeric settings other than these checkbox settings, and certainly I do not think I used a single char string anywhere.

Cleaning up.

Edit