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.
Related
I have a long list of models in frontend. Some of these have functions that are required to be run in batch. For this console is fine.
I can include the models by copying over the code, however this is not a decent approach.
What Im looking for a way to import models from the frontend submodule in console command so I can make changes in one place.
To clarify,
the standard way of including
use app\models\Mymodelname;
in the console\model results in the following error
'Class 'app\models\Mymodelname' not found'
use app\models\Mymodelname;
Have not worked with this include statement before. I prefer to use the frontend/backend as is. If I had to make a wild guess though, this looks for models within console. #app is an alias for current application.
Usually, I keep anything used by more than 1 application under common. As you pointed out, maintaining two copies of the same code is not a good practice.
Try using frontend\models\Mymodelname directly if moving to common is not an option
I don't know if you have two separate applications, or could benefit from this, as you are already using submodules, but depending on your desire to separate concerns with some console commands this might be advantageous.
If you are using composer to manage your dependencies then you can create a separate repository in git, for example, and add a new dependency in your project which contains these common models.
Then, include your dependency in both projects. This introduces some troubles while developing since both apps share this dependency and it can be frustrating at times; I have shared common functionality between multiple interval laravel projects in this fashion with great success.
Currently you seem to be using submodules so this might require restructuring which could be difficult or impossible.
Another option if you want to keep to submodules is to keep common models at a higher level (not inside a submodule) so that you can import the models into both submodules and use them in both places. I shared common models between modules with yii 1.1.16 using this strategy over several years with much success.
Both options have their advantages so weigh carefully your desired outcomes. Feel free to ask for clarification.
How to add private github repository as Composer dependency
#app is an alias of current running application. It can be frontend or backend or console. If you want to access model across applications, add it to commen\models. Or change app\models to frontend\models. That way, you can access frontend models on console. Better way is moving it to common\models.
So I am working on two different applications using laravel and both of them need a lot of the migrations, seeds, models, controllers, routes and so on similar to each other. In fact in most cases, they are absolutely same. What is the best solution to avoid redundancy in such a case.
The best solution I came up with was to extract a package and then use that package in both the applications but there are drawbacks. Every time I need to add a new feature which needs to be added to both of the laravel application, the package needs to updated. Once the package is updated, the main applications are updated. Sometimes small syntactical changes make me change something in the package and then update the packages again to see if it is working. But soon it becomes painful like this.
I have also tried using symlinks in composer file so that the package gets updated as I am working inside an application which uses them, but I still have to update the other application. Moreover, I still have to remove the symlinks before I push because the symlinks break in CI. They need the direct cloud URL for the repository.
Has anyone else gone into a similar problem with laravel and has an idea of how to resolve it? Or the best solution regarding the same.
I started to get data from solr with curl but this is not the symfony way and I want to change that before is "to late".
There is most popular nelmio solr bundle (this is info I found from googling) i also found some other bundles, but wanted to pleased you to help me in choosing nelmio or suggest some better bundle that is fully support also and symfony 3.0
First off: Using NelmioSolarBundle and floriansemm/SolrBundle have very different use cases.
NelmioSolrBundle is just a symfony integration of the solarium library, which is nothing more than a wrapper around those direct curl requests.
The SolrBundle by floriansemm integrates solr deeper into the framework by making annotations available to declare which entity fields i.e. are stored or indexed in solr (done via dynamic fields). I found the options using normal schema.xml definitions are way more powerful since not everything is available there.
In my current project i first tried using SolrBundle but ran into some limitations which led me to switch to NelmioSolariumBundle. (so my solr config and schema are maintained directly in the solr and not through annotations and so on)
Once you get used to the solarium library (http://www.solarium-project.org/) the nelmio bundle works fine but in the end it's nothing more than a fancy way of executing those curl requests.
So if your implementation works, keep using it.
Hope this helps.
Let's assume we have a PHP project with dependencies A and B each depending on PHP library X, but in a different version.
Usually, one would use a PHP dependency manager such as composer which would either resolve this conflict by including X in a version compatible to both A and B or display an error if the conflict cannot be resolved.
Now, many PHP applications allow their users to install plugins simply by uploading pre-bundled packages and extracting them to a specific plugin directory.
If A and B were such pre-bundled plugins and both would bring their own version of library X, we might run into problems since no dependency manager is available to select a compatible X for us or display an error in case there is none.
To prevent any such conflicts caused by the inability of PHP to have library X being loaded twice with different version into the same namespace, we could put A's X and B's X into different namespaces (which might be hard to do automatically as we would need a PHP parser for that...).
My question is:
How would you solve this problem? Can you recommend this approach or is there a better solution?
There is no solution without changing the code. If two versions of ´\Vendor\AnyClass´ do exist in the filesystem, and code is executed to use them both, either an error appears because redeclaring that class is not allowed, or because the expected class is incompatible. It will only work if the interface of the class is implemented the same, i.e. the two codes are compatible. The problem of compatibility is complicated if it isn't only that one class, but an entire tree of objects that may react badly to mixing classes from different versions, even though they offer a compatible interface.
Changing the namespace is changing the code. Who's responsible for that? I can think of some automatic code parser that would be able to add a specific namespace prefix for each plugin, but that task hasn't been done to my knowledge in PHP. The Java guys in my company made some remarks that such a problem has been solved there, but I have no details.
Also, it doubles your code base, and the duplicated code has to share only the one opcode cache you have.
I know that the core developers of Wordpress are still struggling with this problem. There are some coded suggestions of how to use Composer for dependency management (i.e. plugins and their dependencies), but I don't think they made enough progress for now.
Essentially you have two choices: 1. Create a code namespace prefixer, parse all the files belonging to a plugin (so the plugin author has to include his dependencies somehow), change the code, live with the code duplication, and see what awaits you when it comes to debugging. The downside is that no code outside of that plugin will be easily able to use the plugin code directly because that would mean to know the created prefix. 2. Implement some form of dependency management, preferably using Composer, and don't change the namespaces.
Update: I consulted my Java co-workers again, and they basically made the same statement about Java that I made about PHP: You cannot have two different versions of a class under the same class name, and there is no "magic" even for Java but renaming the class to a different namespace.
This may look like a trivial question, but it isn't.
Being new to composer, I find myself wondering about how to pick a decent package for a common feature on its main repo packagist.
Say I am using Laravel 4 for a recent project and would like to add mongodb support for document storages and indexing. A simple search for mongodb on packagist will yield 8 pages of results, searching for mongodb laravel yield 24 pages.
But here comes my question: most packages have their target framework, should I pick the ones that are less popular but designed for Laravel, or should I go with the popular package in hope of future maintenance?
My assumption is that: composer, along with PHP-FIG standards, are attempting to reduce repeat development of common features across frameworks. So eventually there maybe only a handful of popular package left active for a certain common tasks.
But for now, how to choose the right package on packagist for framework X? Should we just search on github instead?
(I should note that Laravel already use a handful of Symfony/doctrine packages in core, but there are no guarantee that doctrine/mongodb will also work in Laravel without modification right?)
When I'm searching on Packagist, I try to avoid packages that depend on frameworks that are not Laravel or sometimes Symphony. Of course, no framework dependencies is okay.
When L4 was still in alpha, I wanted to play around with image manipulation. After some investigation, I chose sybio/image-workshop. At the time, there were no packages that interfaced with Laravel perfectly. After created a service provider and facade, all was good.
On packagist.org, try the search terms "mongodb AND laravel" without quotes. This narrows the search to one page, in this case.
Chris Fidao (#fideloper) tweeted on May 2nd about the following MongoDB package for Laravel. It looks interesting as it uses Eloquent.
https://github.com/jenssegers/Laravel-MongoDB
For package specific for laravel framework, please check packalyst. Packalyst is a directory of Packages for Laravel projects, It pulls package names from Packagist that have a "laravel" tag (composer package that have 'laravel' in the keyword array in composer.json).