#1 April 8, 2015 2:25pm

mdewyer
Member
Registered: April 7, 2015
Posts: 7

4.2 Possible Bugs

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

#2 April 8, 2015 6:41pm

mdewyer
Member
Registered: April 7, 2015
Posts: 7

Re: 4.2 Possible Bugs

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

#3 April 9, 2015 10:14am

timbuckingham
Administrator
From: Baltimore, MD
Registered: April 2, 2012
Posts: 974

Re: 4.2 Possible Bugs

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

#4 April 9, 2015 10:20am

timbuckingham
Administrator
From: Baltimore, MD
Registered: April 2, 2012
Posts: 974

Re: 4.2 Possible Bugs

Latest commit should have the CSS/JS extension issue sorted out. Thanks for the bug reports!

Offline

#5 April 9, 2015 11:14am

mdewyer
Member
Registered: April 7, 2015
Posts: 7

Re: 4.2 Possible Bugs

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

Board footer

Powered by FluxBB

The Discussion Forum is not available on displays of this size.