Technical details
- YOURLS version: master (at e36ec69)
- PHP version: 5.6.30
- I’m running Yourls on shared hosting and they have php5-geoip installed
Bug Summary
After pulling recent changes (up to e36ec69) today, I’ve hit what appears to be a regression of issue #359: I get a blank page and a ”Cannot redeclare geoip_country_code_by_name()” (in includes/geo/geoip.inc on line 1602) error in my log.
I can work around the issue by checking out d5a5522, which is the last commit prior to ”Update GeoIP” (96a159b).
I make no guarantees this doesn’t break something else, but for me it seems to work correctly if I make Feediron_Json::format() skip carriage returns:
$ git diff
diff --git a/Json.php b/Json.php
index c988962..fc7f554 100644
--- a/Json.php
+++ b/Json.php
@@ -8,6 +8,7 @@ class Feediron_Json{
$strLen = strlen($json);
$indentStr = ' ';
$newLine = "\n";
+ $cReturn = "\r";
$prevChar = '';
$outOfQuotes = true;
$currentline = 0;
@@ -30,6 +31,9 @@ class Feediron_Json{
$currentline++;
continue;
}
+ if($char == $cReturn){
+ continue;
+ }
if($char == ' ' && $outOfQuotes){
continue;
}
(Using PHP 5.6.30 here.)
@davesteele Yup, installs without a hitch now. Much appreciated!
Was there a regression or is gtk-update-icon-cache now a hard dependency? I’m getting this in Ubuntu 16.04 (when using the PPA).
The following packages have unmet dependencies:
gnome-gmail : Depends: gtk-update-icon-cache but it is not installable
Steps to reproduce:
Select to download a file uploaded to a channel.
What happens:
A browser window/tab opens with a Slack redirect URL pointing to the file, and asks me to log in to Slack.
What I expect to happen:
I’d prefer it if Scudcloud just directly prompted me with the file saving dialogue, without having to log in to Slack again in the browser.
Other info:
I’m using version 1.22-2 from the PPA on Ubuntu 14.04. I have 2FV set up for the Slack team in question in case it matters.
Thanks @VicDeo, that indeed fixes it.
I’d argue that the comment above the setting in the sample makes this less than apparent — at least I would have been unlikely to have dared to set it to false on my own, and it still seems to me that in making this change I lose ”a crucial security check” for .htaccess. But that’s perhaps subject for another bug.
The README documents wontDeepEqual() as similar to willDeepEqual() but expecting a rejected promise. But a wontDeepEqual() function is not actually defined in the plugin code.
Upgraded to 8.2 today and the issue persists.
Just tested it and I can confirm that it works. Thanks a lot! I’ll post a review on AMO right after this.
All right, thanks for looking into this — whatever the outcome.