News:

Join the Facebook Fan Page.

Main Menu

"Undefined offset" errors

Started by m4z, April 11, 2019, 04:32:09 AM

Previous topic - Next topic

m4z

I'm seeing various "8: Undefined offset: [12]" errors in ManageSmileys.php and Themes.php in a fresh 2.1rc2 install (Debian 8, Postgresql 9.4):





BTW, is there a way to permanently "ignore" specific errors?
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Arantor

No, because they should be solved rather than ignored.

m4z

I assumed as much, and from a developer perspective I totally agree.
But from the user (admin) perspective it's kind of tedious to manually delete dozens of duplicate errors that I have already reported upstream.  :-X
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Arantor

Yes but if you ignore them, you have to track that and evaluate that which will take more effort and storage than just dealing with it. Also you'd have no way of knowing if it was fixed.

m4z

I don't speak PHP (well), so I can't "deal with it" on a code level anyway. From my perspective, my current error log workflow is as follows:

  • delete 95% duplicates that I have already reported, so I can even find the "unhandled" errors
  • report new errors upstream and wait to be notified of a fix

I would prefer to be able to skip the first step by ignoring/filtering the duplicates, or at least an option to group/collapse/summarize repeated errors.

(I assume a huge part of my problem is that I'm using a RC version; I haven't used anything else than 2.1rc2 and hope the situation is much better on released versions.)
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Arantor

The problem is that you have to work out what the ones you've seen are, so you have to log them somewhere and every error that comes up, you have to check if you already saw it, which is very quickly a performance drag.

And the minute you install any mod, or perform any change, the entire ignore list is probably invalid anyway.

And yes, the released situation is better though various addons can cause errors too.

live627

Can you run this query in pgadmin

SELECT * FROM smf_settings WHERE variable LIKE 'smiley_sets_%'

The newline character might not be encoded in smiley_sets_names

m4z


> select * from betasmf_settings where variable like 'smiley_sets_%';
      variable       |            value
---------------------+-----------------------------
smiley_sets_known   | fugue,alienine
smiley_sets_names   | Fugue's Set\nAlienine's Set
smiley_sets_default | fugue
(3 rows)


Can't tell if this is how it's supposed to be though.
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!


albertlast

To test this for you you could run this query:


update betasmf_settings set value = 'Fugue''s Set'||E'\n'||'Alienine''s Set' where variable = 'smiley_sets_names'

m4z

Thanks, I should have reloaded the thread earlier: I didn't see your last post, but I finally figured it out myself in a similar way:

beta-smf=> update betasmf_settings set value='Fugue''s Set'||chr(10)||'Alienine''s Set' where variable='smiley_sets_names';
UPDATE 1
beta-smf=> select * from betasmf_settings where variable = 'smiley_sets_names';
     variable      |     value
-------------------+----------------
smiley_sets_names | Fugue's Set   +
                   | Alienine's Set
(1 row)

beta-smf=>
"Faith is what you have in things that don't exist."
--Homer Simpson

Es gibt hier im Forum ein deutsches Support-Board!

Advertisement: