?
avatar lrdw
lrdw
28 Feb 2018

Steps to reproduce the issue

Request stylesheet function declared in libraries/src/html/HTMLHelper.php with no - array attribute "attribs".

Expected result

No warnings thrown.

Actual result

"Illegal string offset" plus "Cannot assign empty string to a string offset" thrown for lines 626 -629.

System information (as much as possible)

Joomla! 3.8.5 php v. 7.2.2 (same warning reproduced on 7.0 either).

Additional comments

"Else" statement in "stylesheet" function does not declare "options" array.

avatar lrdw lrdw - open - 28 Feb 2018
avatar joomla-cms-bot joomla-cms-bot - labeled - 28 Feb 2018
avatar Quy
Quy - comment - 28 Feb 2018

Related to #19801. The verdict is to find where the warning's origins because there is code somewhere which calls this method wrong.

avatar franz-wohlkoenig franz-wohlkoenig - change - 28 Feb 2018
Status New Discussion
avatar joomla-cms-bot joomla-cms-bot - edited - 28 Feb 2018
avatar Quy Quy - change - 1 Mar 2018
Status Discussion Closed
Closed_Date 0000-00-00 00:00:00 2018-03-01 15:33:45
Closed_By Quy
avatar joomla-cms-bot joomla-cms-bot - change - 1 Mar 2018
Closed_By Quy joomla-cms-bot
avatar joomla-cms-bot joomla-cms-bot - close - 1 Mar 2018
avatar joomla-cms-bot
joomla-cms-bot - comment - 1 Mar 2018

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/19801

avatar ghardin26
ghardin26 - comment - 12 Mar 2020

I have encountered this error while working on my local machine. Using Joomla 3.9.16, it occurs with the Isis template in the admin back end when using PHP 7.1.33 and 7.4.0. It does NOT occur with PHP 7.2.27 or 7.3.12.
The same issue occurs in the Hathor template. Both happen in various places in the backend on a NEW installation running on WAMP 3.2.0 64 bit using the PHP version(s) as described above. In reading several other posts on this topic and doing this testing, it seems to be a Joomla admin template issue, OR a setting in the PHP setups in WAMP that conflicts with the template codes. If the code in the HTMLHelper.php is going to be maintained in Joomla 4 then should we expect the error to reoccur when using PHP7.4?


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19801.

avatar HLeithner
HLeithner - comment - 13 Mar 2020

Are you able to debug and find the problem? Maybe error.log or by activating the debugging?

avatar ghardin26
ghardin26 - comment - 16 Mar 2020

I can debug and see the errors, but as it is a problem with a Joomla file and is affected by various PHP versions, I would say it is a Joomla problem to fix. I have made a couple of changes to the file in question as suggested by some others here and they have had some limited success. But if a new update comes in, those changes are likely to get overridden.

avatar Quy
Quy - comment - 16 Mar 2020

Is this happening with a clean installation with no third party extensions?

avatar ghardin26
ghardin26 - comment - 16 Mar 2020

Yes it is.

avatar brianteeman
brianteeman - comment - 16 Mar 2020

I can debug and see the errors, but as it is a problem with a Joomla file and is affected by various PHP versions, I would say it is a Joomla problem to fix.

And what are they? If you want/expect joomla to fix them then it would be nice to share your findings

avatar ghardin26
ghardin26 - comment - 16 Mar 2020

Brian, I posted the question/problem here because there was already a discussion here regarding the problem and I guess I thought that in doing so I was contributing to the discussion and possible solution. I would hope that everyone that read this would follow thru with reading the rest of the discussion. I am not asking for someone to solve MY problem, particularly, but to highlight that the issue occurs with Joomla core files and various PHP versions so that someone with Joomla influence could find a solution, other than hacking the core files. I know that if I run my development platform on PHP 7.4 that I can avoid the issue, but there are a number of hosting sites that run on other versions of PHP and that causes problems there. Maybe my experience can help someone else.

avatar ReLater
ReLater - comment - 16 Mar 2020

I posted the question/problem here because there was already a discussion here regarding the problem and I guess I thought that in doing so I was contributing to the discussion and possible solution.

Where was the discussion? Could you please post a link.

but to highlight that the issue occurs with Joomla core files and various PHP versions

I know that if I run my development platform on PHP 7.4 that I can avoid the issue, but there are a number of hosting sites that run on other versions of PHP and that causes problems there.

I've never seen a message in a newer clean installation of Joomla (pure core and others for development plus several extensions) with several PHP versions (at the moment PHP 7.4) where I always set Error Reporting to "Maximum" until my additional development has finished.

I've switched now to Hathor and clicked around for a while. No messages.
Thus it would be very welcome if you tell us on which page in which situation you see the message.
Post the administrator link.

I hope it's clear that we only discuss here the current version 3.9.16 or the current nightly build 3.9.17-dev.

Thank you for assistance to find the "bug".

I have made a couple of changes to the file in question

Perhaps that's the reason that you see the messages?

Both happen in various places in the backend on a NEW installation running on WAMP 3.2.0 64 bit using the PHP version(s) as described above

Means: We need somebody that has this platform installed. Perhaps I'll install it tomorrow (but Windows) and test it. Not guaranteed.

avatar ReLater
ReLater - comment - 17 Mar 2020

I can't confirm your finds.

Using Joomla 3.9.16, it occurs with the Isis template in the admin back end when using PHP 7.1.33 and 7.4.0.

Tested Isis and Hathor.
3.9.16 + Sample data. NEW installation running on WAMP 3.2.0 64

Setting Value
 
PHP Built On Windows NT DELL-M6800 10.0 build 18363 (Windows 10) AMD64
Database Version 5.5.5-10.4.10-MariaDB
Database Collation utf8_general_ci
PHP Version 7.4.0
Web Server Apache/2.4.41 (Win64) PHP/7.4.0
WebServer to PHP Interface apache2handler
Joomla! Version Joomla! 3.9.16 Stable [ Amani ] 10-March-2020 15:00 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Setting Value
 
PHP Built On Windows NT DELL-M6800 10.0 build 18363 (Windows 10) AMD64
Database Type mysql
Database Version 5.5.5-10.4.10-MariaDB
Database Collation utf8_general_ci
Database Connection Collation utf8mb4_general_ci
PHP Version 7.1.33
Web Server Apache/2.4.41 (Win64) PHP/7.1.33
WebServer to PHP Interface apache2handler
Joomla! Version Joomla! 3.9.16 Stable [ Amani ] 10-March-2020 15:00 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
avatar ReLater
ReLater - comment - 17 Mar 2020

Both happen in various places in the backend

Again: it would be very welcome if you tell us on which page in which situation you see the message.
Post the administrator links!

avatar mbabker
mbabker - comment - 17 Mar 2020

I can debug and see the errors, but as it is a problem with a Joomla file and is affected by various PHP versions, I would say it is a Joomla problem to fix.

Just because the error is coming from a file in Joomla's API does not necessarily mean that it is a bug in Joomla. The bug is, and always has been, callers to that method using incorrect data types. The second parameter ($options since the refactoring that occurred in 3.7, $attribs in 3.6 and earlier) has always been documented as requiring an array. To get the error this issue (and the numerous other issues with similar reports) has included means someone is not following the documented API and passing an incorrect parameter type into the method. The right fix is for people to fix their code and to stop passing incorrect data types into the Joomla API.

JHtml::_('stylesheet', 'file', null, true); // This is bad, stop doing it
JHtml::_('stylesheet', 'file', array(), true); // This is good, no more errors
JHtml::_('stylesheet', 'file', array('relative' => true)); // This is best, now you aren't even using the deprecated signature!

Can Joomla do something about this? Sure. Should it? IMO, no. Implicitly, that is an API change as that would change the allowed data types for that parameter if core were to start explicitly dealing with a null value, which is the most common reason for this error in the first place. And, since people like to say introducing new exceptions is a B/C break, adding type checks and raising errors is off the table.

avatar ReLater
ReLater - comment - 17 Mar 2020

I just made further investigations because:

Question

Is this happening with a clean installation with no third party extensions?

Answer

Yes it is.

avatar ghardin26
ghardin26 - comment - 17 Mar 2020

I thought I was posting this issue because it seemed like a problem to me. I did not expect to be given the 3rd degree and admonished for my attempts to be of some service to the community. Please forgive my ignorance and accept my apology for posting such a worthless and insignificant issue. I consider the matter closed and I hop I have not wasted anyone's valuable time.

Add a Comment

Login with GitHub to post a comment