in my current project i use doctrine and a listener, checking for certain changes to trigger cache-invalidation.
In my test, due to the use of $entityManager->getUnitOfWork()->getEntityChangeSet($entity) i get the following error:
Returning by reference not supported
The underlying code for this is inside the Doctrine class UnitOfWork:
public function & getEntityChangeSet($entity)
{
which i obviously won't/can't change.
The code that calls it already worked in production:
$args->getEntityManager()->getUnitOfWork()->getEntityChangeSet($entity)
I updated to the latest stable PHPUnit version that we support (4.8) and can't go higher since then i'd had to rewrite all tests (due to serveral methods that became deprecated).
How do i solve this problem?
I believe you may use doctrine/orm of version 2.5.
It has not this passing by reference, only master holds it
Related
In my Prestashop project, I have several modules. In one of them (let's call it "AWS") I installed AWS SDK using composer (in PHPStorm), as explained here. Composer has "required", among other libraries, "guzzlehttp", updated to its final version.
On the other hand, there is another module (let's call it "orangeConnect") with composer too, that has an earlier version of "guzzlehttp".
The problem lies when I am using AWS SDK in php, inside a php script in the first module. What happens is that it tries to call the URI Composer class and it crashes. Actually, because of the inexistence of one class "UriResolver". The thing is that if I remove "orangeConnect" then AWS SDK connect correctly, which means that the class Uri, in "AWS" is not taken correctly because of "orangeConnect" module. However, I need imperatively to support "orangeConnect" in the project.
How can I, in summary, solve this conflict between classes in PHP inside Prestashop and allow each module to include the corresponding valid version of guzzleHttp without conflicts of any kind?
Thank you.
If the official maintainer of orangeConnect module doesn't upgrade the code, there are only 3 methods you can take:
Method 1: You can maintain a copy of your own orangeConnect code, and upgrade to latest Guzzle. Usually it won't be to difficult because Guzzle's interface are well designed.
Method 2: Get the old Guzzle's code and put it into a new namespace (eg: OldGuzzle) and make orangeConnect use OldGuzzle namespace. You can achieve this by do a global regex replace simply.
Method 3: (Only for big systems) Divide your PHP application to micro-service modules, and isolate orangeConnect and AWS SDK and make them use different Guzzle.
I am using this package in my Laravel app (actually 5.5 isn't supported so I forked the repo and fixed the issues here).
I have enabled Searchable trait on my models, and when I'm reindexing I can see that models are actually being reindexed in batches.
On top of that I see that I have a larasearch:paths command available also.
Is there a way to actually see within Laravel what has been indexed, and what paths are made since the search I use doesn't work unless I specify for example a full name of the article I'm searching.
The code used to work, so I don't believe it is a search issue, but rather the indexing one.
I have a project containing, amongst others, the following composer.json dependencies:
"propel/propel1": "dev-master"`,
"halleck45/phpmetrics": "dev-master"
I recently did a composer update and found that a new version of a library required by PhpMetrics, called Hoa, introduces a new class \EngineException to emulate a new PHP7 class. Unfortunately Propel 1 also defines \EngineException, and so a conflict results.
The correct fix for this would be to upgrade to Propel 2, which uses namespaces. However this is still in alpha and is subject to BC breaks, so is not really workable for me.
My present fix is to lock Hoa to a specific version that does not have the new class:
"hoa/core": "2.15.04.*"
That's not a bad solution, but it isn't entirely satisfying to lock a library to an old version.
In the Hoa code, the only way for the new class not to be loaded is to be running PHP 7, which is again not feasible. However, it also occurs to me that Hoa only needs to be required when PhpMetrics runs. This is a stand-alone code analysis tool and only sits in the root of the project for convenience; the rest of the project does not use this library.
Thus, it would be great if I could call something in Composer to ask that this class is not (auto)loaded, or perhaps something to do the same in the composer.json. It is being needlessly loaded at present - I don't know whether it is being autoloaded incorrectly or whether it is being required manually by Composer.
It may help to know that Hoa classes have been added by Composer to the auto-generated autoload_psr4.php script. As far as I can understand the docs, this means it is autoloaded, and there is nothing in my project that would require any of the Hoa classes.
Fixed by https://github.com/hoaproject/Core/commit/8ed00fe9345c4f8b2679a256926d6d24994ea842.
The new exception architecture introduced in PHP7 [1] has been totally
redesigned [2]. This patch updates the retro-compatibility classes
according to this new architecture. Consequently, the BaseException
class has been removed, along with EngineException and
ParseException. While these latters could be implemented (not as
is), we prefer to, so far, only implement the Throwable interface.
Let see if we can implement (still for the retro-compatibility) the
Error, TypeError and ParseError class.
[1]: https://wiki.php.net/rfc/engine_exceptions_for_php7
[2]: rfc/throwable-interface
I was curious, so I looked it up. Hoa indeed has a broken approach, having the file Core.php always included, by a "file" autoload in composer which in turn includes Consistency.php. The latter defines your class.
You could raise an issue with the developers at Hoa, to use class_exists to check for the method rather than the currection version check they are using. This could cause the propel autoloader to load its own. Another way would be to define their autoloading correctly, but they prefer to load manually as it seems.
After updating to Symfony 2.7 I've got deprecated notification in my profiler. Here it is:
It looks like an internal Symfony stuff. Any ideas about how to fix it or it will be fixed in next Symfony patches?
It seems that the issue is located at the "AllowedMethodsRouterLoader" class. This might be an external bundle, so you might be able to update this bundle. If it's your own class, it's as easy as just changing it to using ->getPath() instead of using the ConfigCache instance as a string.
I'm using Laravel to create a versioned JSON API that I'll then access with AngularJS to populate my pages. Currently I'm returning the JSON using versioned controllers (eventually I plan to implement dependency injection & versioned repositories instead).
I've attempting to namespace my controllers in the format App\Controllers\API\v1.0 but when I visit localhost:800/api/1.0/companies in my browser, where the JSON is returned, I am notified that Class App\Controllers\API\v1.0\CompaniesController does not exist
. I'm guessing this is because the . is being interpreted like one of the backslashes? I can make the application function by changing the namespace to App\Controllers\API\v1 or App\Controllers\API\v1\v0 , but the former doesn't allow for proper versioning and the latter seems a bit ... inelegant.
What conventions should I use for my namespaces to adequately version my API? Any advice would be appreciated! :)
APIs should only use major versions externally. Following best practice semantic versioning, major versions change when you introduce backwards-incompatible changes to a project.
If you're just adding features, or modifying existing ones in backwards-compatible ways, then you just do it and your existing consumers are not affected (though, they can then make use of the new changes if they want). Your API can change versions from 1.0.0 to 1.1.0 internally, but the version as exposed to your consumers is still just "v1".
If you're just patching bugs, the same applies. Change from 1.0.1 to 1.0.2 internally, but the API should stay at "v1".
Now, if you rename/remove resources, or do some other drastic changes that will break existing clients, your internal version might go from 1.2.0 to 2.0.0, because breaking backwards compatibility requires a major version change. Because of this, the new major version has to be exposed to your API's consumers as "v2".
So, in keeping with this, both your namespaces and your URLs should reflect only the major version (e.g. "v1"), and you should make sure that you never break backwards-compatibility within a major version.