Been using the PHP Soundcloud API for some time now, and it's been working fine. The code I use to create the track array is (and has always been):
$track = json_decode($client->post('tracks', array(
'track[title]' => $title,
'track[asset_data]' => $filename,
'track[description]' => $desc,
'track[genre]' => "Podcast",
'track[artwork_data]' => $image
)));
And it's always been working just fine - until this morning, when I got this error message when uploading a track using my home-made PHP tool:
Fatal error: Uncaught exception 'Services_Soundcloud_Invalid_Http_Response_Code_Exception' with message 'The requested URL responded with HTTP code 422.' in /home/csicon/public_html/PodcastAuthor/lib/Soundcloud.php:943 Stack trace: #0 /home/csicon/public_html/PodcastAuthor/lib/Soundcloud.php(621): Services_Soundcloud->_request('https://api.sou...', Array) #1 /home/csicon/public_html/PodcastAuthor/2-publish.php(52): Services_Soundcloud->post('tracks', Array) #2 {main} thrown in /home/csicon/public_html/PodcastAuthor/lib/Soundcloud.php on line 943
Now, I'm no newb, and know what HTTP code 422 is all about, so I checked the contents of $title, $filename, $desc and $image. They are, in order:
Geekdays #274: 2015-11-17
#/home/csicon/public_html/PodcastAuthor/uploads/g274.mp3
Snowden, the FBI and the Oxford Dictionary are getting blamed for things that they may or may not have done. Also; the air you're breathing might be killing you. This, and so much more, on today's episode of Geekdays.
#/home/csicon/public_html/wp-content/uploads/2014/10/geekdays-600x600.png
All paths (to the mp3 and the image) check out, there's nothing wonky in the character set being used, and it's all worked before. What might have happened here? I'm stumped.
UPDATE! Turns out my webhost has upgraded their PHP environment from 5.4 to 5.6, and this is what broke it. What's changed between 5.4 and 5.6 that might have caused this, in that case?
Turns out my webhost has upgraded their PHP environment from 5.4 to 5.6, and this is what broke it. What's changed between 5.4 and 5.6 that might have caused this, in that case?
How cURL file uploads are handled has changed.
CURLOPT_SAFE_UPLOAD is set to true by default from PHP 5.6 on, and that means file uploads are not possible any more using the #-file path syntax, but CURLFile should be used for file uploads instead.
Try setting CURLOPT_SAFE_UPLOAD to false, using the setCurlOptions method.
Magically started working when I changed to the sebdesign/php-soundcloud version of the curl-file branch. Not sure why the "normal" curl-file branch didn't work, however.
Related
Cross post from https://github.com/getgrav/grav/issues/3523
(don't kill me, I didn't know that it's frowned upon)
I am not sure if this is the place to ask for help, so tell me if it's not (and maybe where to ask).
I am trying to update to the latest Grav release 1.7.29 from (originally 1.6.24, while troubleshooting today updated to) 1.6.31 (using direct-install.
I tried updating with self-upgrade and direct-install <latestVersionURL>.
But, while trying to install, it gives me the following error:
Installing upgrade... [30-Jan-2022 17:04:37 Europe/Cityxy] PHP Fatal
error: Uncaught Error: Call to undefined method
Grav\Common\Utils::basename() in
/var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdate.php:29
Stack trace:
#0 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdater.php(126):
Grav\Installer\VersionUpdate->__construct('/var/www/virtua...',
Object(Grav\Installer\VersionUpdater))
#1 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdater.php(38):
Grav\Installer\VersionUpdater->loadUpdates()
#2 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/Install.php(239):
Grav\Installer\VersionUpdater->__construct('core/grav',
'/var/www/virtua...', '1.7.29', Object(Grav\Installer\Versions))
#3 /var/www/virtual/name/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/Install.php(184):
Grav\Installer\Install->prepare()
#4 /var/www/virtual/name/html/system/src/Gra in /var/www/virtual/eduref/html/tmp/Grav-61f6b713f0bb9/zip/grav-update/system/src/Grav/Installer/VersionUpdate.php
on line 29
From my understanding the files between versions have been changed, and looking at the Grav documentation, the called method basenames() is now in Grav/Common/URI, not in Grav/Common/Utils.
So I assume I located the problem, but have no idea on fixing it. Since I am not very well versed on this whole topic of managing websites (never set up the site, only maintaining it), I would really appreciate a safe answer on how to update Grav to the newest version which doesn't risk me destroying the functioning of the website.
Thank you for helping! :)
Tried with:
PHP: 7.3 & 7.4
Grav: 1.6.24 & 1.6.31
Admin: 1.9.10
Host: Uberspace
via SSH
Particular issue fixed:
https://github.com/getgrav/grav/issues/3523
following issue open:
https://github.com/getgrav/grav/issues/3532
I'm maintaining to exist project which migrated from another host.
I'm facing this issue where the image from app/media/tf/img/ are broken whereas from other path are working fine. Below are stack trace from error.log
2020-12-04 16:44:47 Error: [MissingControllerException] Controller class TransferController could not be found.
Exception Attributes: array (
'class' => 'TransferController',
'plugin' => 'Media',
)
Request URL: /xy/media/tf/img/123.jpg
Stack Trace:
#0 E:\www\xy\xy\app\webroot\index.php(92): Dispatcher->dispatch(Object(CakeRequest), Object(CakeResponse))
#1 E:\www\xy\xy\index.php(41): require('E:\\www\\xy...')
#2 {main}
Actually, from old server everything's are working fine using the exact same source code. Also, I did tried for the same workaround here but still not working.Glad if someone could help as I'm new to CakePHP.
UPDATE
Just tried to change the path app/img , it is working. It's kind of weird since media/transfer/img are in the same webroot.
img--> tried direct path(app/img/..), working
media--> tried /transfer/img/.. path, not working
manual--> tried direct path(app/manual/..), also not working
But still I need to use the media path and if any explanation for this would be highly appreciated.
Check imageBaseUrl in app.php , here we assign the folder for
$this->Html->image();
I am a user not a developer. The developer is not available.
This is the Google API library used in Google Shopping Products submission scripts.
The scripts worked successfully, every 20 minutes, for 2 years + the first 5 hours of yesterday.
Then the following error:
[18-Apr-2020 06:20:03 Europe/London] PHP Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 2: easy handle already used in multi handle (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:162
Stack trace:
#0 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(129): GuzzleHttp\Handler\CurlFactory::createRejection(Object(GuzzleHttp\Handler\EasyHandle), Array)
#1 ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php(89): GuzzleHttp\Handler\CurlFactory::finishError(Object(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#2 ../vendor/guzzlehttp/guzzle/src/Handler/CurlHandler.php(43): GuzzleHttp\Handler\CurlFactory::finish(ThObject(GuzzleHttp\Handler\CurlHandler), Object(GuzzleHttp\Handler\EasyHandle), Object(GuzzleHttp\Handler\CurlFactory))
#3 ../vendor/guzzlehttp/guzzle/src/Handl in ../vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 162
The only server change at around the time the scripts stopped working was a security patch applied to the physical host and a server reboot.
PHP v7.3.16
I believe the Google library in use is v2.0
I can follow instructions although will probably not understand them!
TIA
Just in case anyone reading this is using Laravel. We suddenly started having the same problem a few days ago, tried installing different cURL versions and setting cURL options, nothing worked. I fixed it by changing the vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php file. Look for the line that says
if (count($this->handles) >= $this->maxHandles) {
curl_close($resource);
} else {
...
}
Comment this all out, and instead of the if/else just write
curl_close($resource);
In other words no matter what the handles count is you always close the cURL connection. This worked instantly for us!
Hope it helps :)
We solved this problem together with Stripe engineers yesterday (that's not to say your problem is Stripe-related, it isn't, but the problem/solution should be the same)
(These findings are not 100% confirmed, but appear to be the pattern): It's caused when making 2+ requests via cURL and appears to happen since one of the most recent versions of cURL or at least some other software (which may have updated automatically or been done by your hosting provider)
The solution we were provided is to disable persistent connections in cURL. There are different ways of how you could do that, depending on your implementation. But for inspiration, this is how we did it with Stripe:
$curl = new \Stripe\HttpClient\CurlClient();
$curl->setEnablePersistentConnections(false);
\Stripe\ApiRequestor::setHttpClient($curl);
I imagine it would be something similar to this for your libraries. And for those looking to solve this for Stripe, here it is :)
Notice: This solution will theoretically have an impact on latency, we have however not experienced this in practice yet. But now it's mentioned :)
I have reverted to curl 7.69.1 and all is well again.
For now, I have removed curl + libcurl from yum so they will not update.
Thanks for your help and advice and apologies if my style has been incorrect.
public_html/vendor/guzzlehttp/guzzle/src/Handler/Proxy.php
please comment these lines from this fn
public static function wrapSync(
callable $default,
callable $sync
) {
// return function (RequestInterface $request, array $options) use ($default, $sync) {
// return empty($options[RequestOptions::SYNCHRONOUS])
// ? $default($request, $options)
// : $sync($request, $options);
// };
}
I am not using guzzle, but I had same problem with other library
php 7.4.6
curl 7.19.7
CentOS release 6.10 (Final)
package "mercadopago/dx-php": "2.0.0"
On my dev server and other server i tested it works fine
I am not 100% but I think that is a bug on curl library that doesn't allow to reuse same curl connection for more than one request (again I am not sure about it).
I solved it with a hotfix on mercadopago/dx-php I edited ./vendor/mercadopago/dx-php/src/MercadoPago/RestClient.php
replacing line 150
from
$connect = $this->getHttpRequest();
to
$connect = new Http\CurlRequest();
in other words, force to use new connection for next request. on your code look where connection is reused and try to create new connection instead.
I know, it sucks because:
- is a hotfix on Third-party
- cannot reuse same connection
but it worked. Hope it can help you.
I encountered strange error with my php-fpm 5.6.30 with OPcache v7.0.6-dev on ubuntu server. I got error at /vendor/monolog/monolog/src/Monolog/Logger.php file concerning array_keys(static::$levels) code in it:
array_keys() expects parameter 1 to be array, object given
The static::$levels property is defined in the top of Logger.php file as array:
protected static $levels = array(
self::DEBUG => 'DEBUG',
self::INFO => 'INFO',
self::NOTICE => 'NOTICE',
self::WARNING => 'WARNING',
self::ERROR => 'ERROR',
self::CRITICAL => 'CRITICAL',
self::ALERT => 'ALERT',
self::EMERGENCY => 'EMERGENCY',
);
This code was installed via composer and never edited manually, so there is no reasons for the file to be changed.
When I look at my laravel.log, I see that something has changed the code behaviour, so lines at the log changed their format:
[2018-05-16 00:19:22] production.INFO: blabla
[2018-05-16 00:20:04] production.[object] (DateTimeZone: {"timezone_type":3,"timezone":"UTC"}): blablabla
The key fact is that when I opened the file using nano, added a comment line into it and saved, the bug disappears. It means that the wrong code was in the opcache, not in the code of the framework.
To conclude, the bytecode of Logger.php was somehow changed and php saw object with DateTimeZone objects in it rather than an array of strings.
The question is - how could the cached bytecode be changed without being totally crashed? What on earth can do this? Can high memory consumption lead to such unexpected changes?
We had the same issue in our project (php 5.6.30, opcache v7.0.6-dev). To solve the problem we analyzed the opcache settings and found that interned_strings_buffer was 4Mb. Raising this value to 64 Mb we solved the problem.
I am attempting to get Text To Speech and Speech Recognition to work in PHP using Microsoft's SAPI through COM objects.
In the past, I already used this code to get TTS to work (Apache 2.1, PHP 5.5, on Windows 2003 Server)
// Instantiate the object
$VoiceObj = new COM("SAPI.SpVoice") or die("Unable to instantiate SAPI");
// Get the available voices
$VoicesToken=$VoiceObj->GetVoices();
$NumberofVoices=$VoicesToken->Count;
for($i=0;$i<$NumberofVoices;$i++)
{
$VoiceToken=$VoicesToken->Item($i);
$VoiceName[$i]=$VoiceToken->GetDescription();
}
// Get and print the id of the specified voice
$SelectedVoiceToken=$VoicesToken->Item(0);
$SelectedVoiceTokenid=$SelectedVoiceToken->id;
// Set the Voice
$VoiceObj->Voice=$SelectedVoiceToken;
$VoiceName=$VoiceObj->Voice->GetDescription();
$VoiceFile = new COM("SAPI.SpFileStream");
$VoiceFile->Open('./test.wav', 3, false);
// Speak to file
$VoiceObj->AudioOutputStream = $VoiceFile;
$VoiceObj->Speak("What an unbelievable test", 0);
$VoiceFile->Close();
On my new setup (IIS 7.5, PHP 7.0, Windows Server 2008R2) the same code fails at
$VoiceObj->Speak("What an unbelievable test", 0);
Fatal error: Uncaught com_exception: <b>Source:</b> Unknown<br/><b>Description:</b> Unknown in \\web\tts.php:30 Stack trace: #0 \\web\tts.php(30): com->Speak('this is a marve...', 0) #1 {main}
With such little detail (where to retrieve more?) I can't figure out what the problem may be.
Writing permissions checked.
PHP 7.0 replaced with 5.5, still not working.
Same code tested with a Win32 app, and it works flawlessly.
Any hints?
Two years later, I casually happen to find an answer to this problem.
PHP COM Objects can't perform file operations on network paths, even with all the required permissions
Once the development folders were moved on the same machine where IIS runs, a bunch of previously broken tests started working. They all had one thing in common: they were using COM interfaces to save files or something like that.