Request stylesheet function declared in libraries/src/html/HTMLHelper.php with no - array attribute "attribs".
No warnings thrown.
"Illegal string offset" plus "Cannot assign empty string to a string offset" thrown for lines 626 -629.
Joomla! 3.8.5 php v. 7.2.2 (same warning reproduced on 7.0 either).
"Else" statement in "stylesheet" function does not declare "options" array.
Status | New | ⇒ | Discussion |
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-03-01 15:33:45 |
Closed_By | ⇒ | Quy |
Closed_By | Quy | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/19801
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?
Are you able to debug and find the problem? Maybe error.log or by activating the debugging?
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.
Is this happening with a clean installation with no third party extensions?
Yes it is.
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
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.
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.
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 |
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!
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.
I just made further investigations because:
Question
Is this happening with a clean installation with no third party extensions?
Answer
Yes it is.
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.
Related to #19801. The verdict is to find where the warning's origins because there is code somewhere which calls this method wrong.