I'm trying to use the template from http://jenkins-php.org in my installation of Jenkins. As soon as I go in to configure the project I get a grey screen appearing and the words 'Loading'
If I look in the Browser error console I get TypeError: 'undefined' is not an object (evaluating 'registry.get')
Has anyone else experienced this problem? How can this be fixed?
We had this problem when upgraded to 1.528.
Digging further, we found out that the problem is originated from one of the client-side script files called "hudson-behavior.js" and is caused by the "Publish Over SSH" plugin. There have been other plugins that have caused this in the past, as well. We couldn't disable the plugin anyway. So we searched further.
Long story short, we ended up changing the script for the time being. If you, like us, install Jenkins using the war file, then the script file is probably extracted and cached in "/var/cache/jenkins/war/scripts/hudson-behavior.js".
The following change we made was in a function called "registerValidator":
if (depends==null) { // legacy behaviour where checkUrl is a JavaScript
try {
return eval(url); // need access to 'this', so no 'geval'
} catch (e) {
// set depends to an empty array.
depends = [];
}
}
var q = qs(this).addThis();
The URL may not always be valid. Thus, a try-catch is in order. Hope this helps!
I've just had the same issue, I'm using version 1.523 of Jenkins on an Ubuntu server.
The solution I found was to manually edit the project config.xml file.
sudo vim /var/lib/jenkins/jobs/yourProjectName/config.xml
I had images in the description and I removed those leaving the description tag empty.
I also had an empty plot section which I removed completely from the publishers section.
After saving the config and going back to 'manage Jenkins' and then 'Reload Configuration from Disk' I then reopend my project and the config opened normally again.
I wasn't getting quite the same error message as you in the browser console to start with, but I hope that helps.
I too downgraded to 1.523 and then it worked... So it's obviously some bug introduced after 1.524.
Upgrading from 1.530 to 1.531 fixed it for me.
Related
As stated by this solution, the workaround proposed works very well on dev and test SS environments.
The suggested one is to avoid the current bug related to auto-publish files managed via DataObject $owns property.
But since I uploaded my project in production - on live env - the workaround doesn't work anymore.
In my case I'm working on a DataExtension of User model. The rest of implementation follows exactly the above mentioned case - with UploadField.
In production, it seems that the snippet is ignored in its condition. In particular, this is my version:
UserExtension
// AllegatiDownload: many_many File type uploaded with UploadField
public function onAfterWrite()
{
if ($this->owner->AllegatiDownloadID) { // <- This is being ignored in live version
$this->owner->AllegatiDownload()->publishSingle();
}
parent::onAfterWrite();
}
If I try to replace
$this->owner->AllegatiDownloadID
with
$this->owner->AllegatiDownload()
The condition pass, but $this->owner->AllegatiDownload()->publishSingle() returns an untraced 500 exception. Just:
There was been an error
And, as I said, this happens only in production.
Thanks in advance for support.
Today I flushed the project DB in order to upgrade a custom front-end component that interacts with it. Seems that after that flush, the issue being solved. That's pretty strange, because I tried many /dev/build?flush=all before, and nothing happened. Server cache maybe? I don't know. But now the workaround works as expected.
Thanks anyway for the support.
I ran command
php artisan optimize
and changed debug settings in app.php file to be
'debug' => 'true',
and added 'everyone' to have full access over 'storage' folder. I don't know what else I can do to let debugger work in my Laravel 5 project.
I'm stuck with 'Whoops, looks like something went wrong' message.
Any Ideas??
The debug => true will just show you the full error stack when you hit an error with your app. It doesn't give metrics and statistics. If you are looking for that kind of information check out the article here:
https://laravel-news.com/2015/02/laravel-debugbar/
The error you are receiving is a general error, likely server-side configuration. Without any information on your setup it will be pretty hard to determine what your issue is. Based upon your question and comments to others responses I have a couple of things for you.
You stated "I don't know what else I can do to let debugger work in my Laravel 5 project". Laravel 5 doesn't have a native debugger any more which I imagine is why your page just shows "Whoops, looks like something went wrong". Your statement would indicate that you have a debugger, so which are you trying to use, or was that statement incorrect?
You stated that you changed the debug settings the app.php file. Is there a reason why you changed this in app.php? The debug setting by default is 'debug' => env('APP_DEBUG') which is sufficient in most cases. You should have a .env file in the root of your project (created automatically if you did a composer create-project, if not you need to copy .env.example to .env on your own). The .env file will enable debug for you as there is a line that states APP_DEBUG=true.
Jesse Schutt gave great information in his response above (which I recommend upvoting), including a link to a debug bar that is compatible with L5. Yet again you are stating that you are satisfied with your error stack which implies that you actually have one. If you were satisfied with it, you would have no need to have posted here as you would already have more information on your error. If you are assuming that the filp/whoops is in l5 still and that's what you want you'll have to re-enable it. Follow the instructions at http://mattstauffer.co/blog/bringing-whoops-back-to-laravel-5
Can anyone explain if there is a way to catch or log errors when the following code is executed?
//This has example has no semicolon.
Route::get('user/{id}', function($id)
{
return View::make('profile')
});
or
//This example has no dollar sign (part of a blade template).
Welcome {{ userName }}
I end up with an empty page for these and there have been a few other times this has happened where I can't remember the details.
I have debug set to true in app/config/app.php and I don't get any errors in the log files at app/storage/logs
Is this normal or do I have a problem with my setup?
Thanks
UPDATE
Laravel log commands aren't working for me. See the comment in reply to msturdy.
Sorted this now. I downloaded the latest Laravel and still had identical issues. Eventually I found out that Apache was pointing at a old version of php (5.3.0) that lived on a different drive (no idea how I've done that), anyway I had my command line pointed at the correct version of php, so that's why I've had no issues when installing/updating Laravel.
Small chance anyone would see similar issues as it was a bit of a random situation (my apologies). I now get the prettiest runtime exception page I've ever seen when running the examples :). Thanks msturdy
I really need your help. Actually, my journey begin with the installation Drupal and some modules. After a couple of days I suddenly get an issue "500 Internal Server Error".
I asked my hosting provider why this happened, he said "That because of the file .htaccess and you should add to this file php display error". So i did this and I get a new issue :
"Fatal error: Call to undefined function menu_load() in ...
/public_html/includes/menu.inc on line 579."
By the way, that's line 579
else {$return = $function($value);}
P.S: I am a beginner in PHP. I like Drupal a lot and want to study Drupal in further and create cool sites, but this problem...
need to figure out what function it's trying to call first.
change the line
else {$return = $function($value);}
to
else {echo $function;exit;$return = $function($value);}
Here are few tips:
make sure your Drupal core has all the files in the right place (especially menu module),
make sure your imported database is in UTF-8 format,
upgrade your Drupal core to the latest version (drush fr && drush up drupal)
clear all your caches (drush -y cc all), including your memcached (killall memcached),
rebuild your registry by using [Registry Rebuild][1],
if you're using modules which are implementing drupal_bootstrap() (such as Secure Site), disable them,
try disabling your PHP cache engines (such as XCache, Zend optimizer) to see if that's the problem,
test it on different environment/machine,
eventually restore your database from the point where it was working before
I have a Magento 1.6.2 site hosted on 1&1. Because of certain installed extensions I must have support for PHP version 5.3, but sadly the available options with 1&1 are PHP 5.2 or something they call PHP Dev. A quick phpinfo() shows that this is in fact PHP 5.4.
My problem is that when I'm set to 5.4, the Categories page of the backend throws a 500 error. Rolling back to 5.2 fixes the issue, but that breaks my product pages. In the short term I can handle having to swap between them, but this is obviously unacceptable for a long-term solution when the site is handed to the client.
Can anyone suggest where this incompatibility might lie, and what steps I might take to fix it? My biggest impediment is that the hosting is on a shared server, and so I am not allowed to look at the Apache logs.
Update:
As per CCBlackburn's suggestion in the comments, I have tried to track the point that the error originates from, but I have to admit that I don't really understand the results I'm getting. The URL of the categories page looks like this:
example.com/index.php/admin/catalog_category/index/key/blahblah
I presumed that Mage_Adminhtml_CatalogController would be the place to start looking, but a Mage::log() call as the first line in indexAction() failed to write to the log.
I decided to move up the inheritance and cut into the constructor, and so added the following to Mage_Adminhtml_Controller_Action:
function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array()) {
Mage::log('construct pre');
parent::__construct($request,$response,$invokeArgs);
Mage::log('construct post');
}
This was better, as the first log call wrote to the file, but the second did not.
Next I moved up the inheritance again, and modified the constructor of Mage_Core_Controller_Varien_Action as follows:
public function __construct(Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, array $invokeArgs = array())
{
Mage::log('request: '.$request);
$this->_request = $request;
Mage::log('response: '.$response);
$this->_response= $response;
Mage::log('pre set action');
Mage::app()->getFrontController()->setAction($this);
Mage::log('post set action');
$this->_construct();
}
The problem is that none of these log calls do anything. This has me stumped, as surely calling parent::__construct(); from Mage_Adminhtml_Controller_Action should execute at least one more log call before it does anything. Unless the issue exists with the incoming values, but I don't know how I can check/debug that?
I have faced the same problem under OSX Lion in Google Chrome and Apple Safari with Magento 1.7 and PHP 5.4. Suddenly Magento Category admin started giving 500 Errors and I had no clue what was happening. It seems it's a problem with PHP 5.4. At first I thought it was XDebug causing this error. Then I disabled XDebug and the problem was still there. It is weirder than weird that it works with Firefox!
My solution was to downgrade to the latest PHP 5.3, however this has now been fixed as of PHP 5.4.3.