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.
Related
I'm trying to get a TYPO3 v8 system updated to TYPO3 v9, but when it comes to unit-testing, I got some errors. I was able to fix some of them on my own but this one here's a very difficult one for me, because unit-testing is somewhat new to me in general.
I already searched the web, the TYPO3 documentation (which seems like the important parts are missing?), asked some friends and tried some things on my own, but nothing helped.
$this->environmentMock = $this->createMock(Environment::class);
$this->environmentMock->expects($this->once())
->method("::isCli")
->will($this->returnValue(TRUE));
I'm expecting to manually override the static function ::isCli() that comes with the Environment class. If that's not possible, is there any other "workaround", like setting a protected variable or something like that?
Currently this is my error message:
Trying to configure method "::isCli" which cannot be configured because it does not exist, has not been specified, is final, or is static
Thanks in advance!
Update 1:
After using #susis tip, I get the following error when appending the code:
TypeError: Return value of TYPO3\CMS\Core\Core\Environment::getContext() must be an instance of TYPO3\CMS\Core\Core\ApplicationContext, null returned
Additional information: My project is just an extension folder with TYPO3 v9 sources required in its own composer.json. No web, no htdocs, just the extension folder.
Update 2:
Here's a full gist of my test file.
Update 3:
Even the debugger isn't helping me in this case, see attached screenshot:
xdebug phpstorm applicationcontext environment screenshot
Update 4:
I updated the gist, added the environment vars to the phpunit.xml file and added parent::setUp() to the top of the setUp() method but the error is still the same:
TypeError : Return value of TYPO3\CMS\Core\Core\Environment::getContext() must be an instance of TYPO3\CMS\Core\Core\ApplicationContext, null returned
/Users/xyz/my_redirect/public/typo3/sysext/core/Classes/Core/Environment.php:97
/Users/xyz/my_redirect/Tests/Unit/Hooks/RequestHandlerHookTest.php:41
Update 5:
I updated the gist and removed the environment settings from the phpunit.xml due to what I've seen that they didn't work either. At this moment, the test is working but I'm still not sure if it's done the right way. Thanks for your help!
You can initialize the Environment you want in your tests, for example with:
Environment::initialize(
Environment::getContext(),
true,
false,
Environment::getProjectPath(),
Environment::getPublicPath(),
Environment::getVarPath(),
Environment::getConfigPath(),
Environment::getBackendPath() . '/index.php',
Environment::isWindows() ? 'WINDOWS' : 'UNIX'
);
This is the same way as it is done in TYPO3 Core tests and allows you to customize the complete environment. If you are using the TYPO3 testing framework / UnitTestCase base classes, you can use the property protected $backupEnvironment = true; to make sure the environment is reset after your test.
For an example, you can have a look at the ResourceCompressorIntegrationTest
hope you're good
I was trying to add a profile table to my Laravel 5.6 project, and I'm also using the spatie\Laravel-Permission package. It was working fine, but after I ran some migrations (that have nothing to do with users), it started failing on the login. The curious thing is that, if I register a new user, it gets logged in properly, but never with the /login route (I'm using the Laravel's Auth scaffolding).
After debugging the project, I came up with the method that's failing, it's something reading the sessions:
MyProject\vendor\laravel\framework\src\Illuminate\Filesystem\Filesystem.php
<?php
namespace Illuminate\Filesystem;
use ErrorException;
use FilesystemIterator;
use Symfony\Component\Finder\Finder;
use Illuminate\Support\Traits\Macroable;
use Illuminate\Contracts\Filesystem\FileNotFoundException;
class Filesystem{
// ...
public function get($path, $lock = false)
{
if ($this->isFile($path)) {
return $lock ? $this->sharedGet($path) : file_get_contents($path); // <-- The failing line
}
throw new FileNotFoundException("File does not exist at path {$path}");
}
// ...
}
Once it gets to that line, the debugger stops, the browser doesnt get a response, the dd() function does not get triggered... I also tried to debug the sharedGet($path) method, and it returns the value, but back to the method above, it stops.
Also, the php_error.log file gets absurdly increased on every request (up to 500MB/request), so much that none of the editors I use can open it (SublimeText, NetBeans).
My thoughts are that apache may be running out of memory when reading the files, but the session file barely weights 1k, so it wouldn't make much sense.
Can someone throw any clue? Thanks
--EDIT:
I tried installing a fresh laravel proyect with only the Auth module and the spatie/laravel-permission package, and I noticed the same behaviour: it registers and logs users, but after logging it out, I'm no longer able to log in with any user.
In case someonw gets to the same error:
I could manage to solve this by backing up all my projects/databases and reinstalling wampserver with the last version of php (by the moment of this answer, it is 7.2.4) and reinstalling Laravel (luckily the proyect was barely starting), which only updated vlucas/phpdotenv package from 2.4.0 to 2.5.0 and phpunittest.
Whith this update now I can log in users normally, now let's see if it works as it should with spatie/laravel-permission package and the profile table I need to add.
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.
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.
The following exception is thrown on my server:
Fatal error: Class 'My_Model_Bo_User_Agenda_Doctors' not found in...
Though in localhost everything is working fine.
I checked that everything was correctly uploaded; all the files are present and not corrupted. I also tried to upload several times. So this doesn't seem to be the problem.
Any idea why a class couldn't be found on the server ?
You don't say so in your question, but I suspect that you are developing on windows and hosting on Linux.
Windows is not case sensitive to path names, but Linux is! Check that:-
Doctors.php is not doctors.php
Agenda/ is not agenda/ .etc
Lastly check the class name in the class declaration is correct and correctly cased.
Do not just think to yourself, yes I've done that, go and check them carefully. Believe me, bitter experience has taught me this problem is always due to a trivial oversight like this.