You are not logged in.
Pages: 1
A few things I'm noticing after upgrading to 4.2:
1. When running "BigTreeAdmin::processField($field)" on a file upload, if I don't specify $field["options"]["crops"] as an array, I get an error: "Warning: Invalid argument supplied for foreach() in /home/uccms/public_html/core/inc/bigtree/admin.php on line 6077". Looking at line 6077 the code is:
// Handle Crops
foreach ($field["options"]["crops"] as $crop) {
if (is_array($crop)) {
And I think it should be reversed to:
// Handle Crops
if (is_array($crop)) {
foreach ($field["options"]["crops"] as $crop) {
To make sure it's an array first, before trying to loop through it.
2. When I specify a CSS file in settings.php, ex:
$bigtree["config"]["admin_css"] = array('custom.css');
It works just fine in the main admin areas, but if I go into my module (which is part of an extension I built), the URL of that file changes from:
<link rel="stylesheet" href="http://domain.com/admin/css/custom.css" type="text/css" media="screen" />
to
<link rel="stylesheet" href="http://domain.com/admin/*/com.extension.name/css/custom.css" type="text/css" media="screen" />
Even though it's specified as a global admin CSS file, and not an extension-specific CSS file using $bigtree['css'][].
Thanks!
Offline
Maybe not so much a bug persay, but something noticed. It looks like the URL for a file uploaded to a service (at least for S3 and Google) is hard-coded as "http://.." in cloud-storage.php. Consider changing to "https://.." for compatibility with SSL sites, or even better, just "//.." so http/https isn't forced and the browser can just pull the image accordingly.
Offline
For bug #1 I've added an additional is_array to prevent that warning. The one inside is to ensure that the crop data itself isn't corrupted. PHP is dumb and will still let you address strings as arrays so if $crop is a string it'll pull in weird data for prefix/width/height and cause failures when trying to process the crop.
Looking into bug #2 now, will have it fixed shortly.
#3 - Good call on the protocol agnostic cloud files URLs. I believe we had an issue with that recently on a site (architecture.org I believe) that we just got around by calling $cms->makeSecure() on every page, but obviously that's additional logic overhead that isn't needed with the // URLs. I'll push that change shortly!
Offline
Latest commit should have the CSS/JS extension issue sorted out. Thanks for the bug reports!
Offline
Awesome, thanks Tim! And good point on the is_array, I totally missed that it was checking to see if it was a sub-array, so yeah, need two checks!
Offline
Pages: 1