@TheLionKing you shouldn't really have two separate apps that use code (i.e. Models) from one of the two apps, this is why @nWidart is suggesting you use an API, so that one of your app is the central source of all of your data, and the other app simply consumes it.
@armababy - Thanks for the very useful explaination!
This is something I've often felt like I wanted to have but never could argument (towards myself) that it justifies a class of it's own. But obviously - I was completely wrong ^^
And yay, I got what I expected: the translated articles with its matching related media
Another alternative I thought (and I think that would be the straight way to go), would be to create a couple of methods in the TestimonialEloquentRepository, so with a single call within the controller you get similar results.
@LaravelDev For media module linkMedia() you would need Entity to link to.
Depends on what context you are allowing upload. If it's something like User Profile then you should have User Profile frontend module, then you can follow documentation or do your own design and submit required data via ajax/post to media module.
The current documentation, despite it's been useful for me, is now pretty scarce and needs more improvement and detailed cases, as well as examples and a full API documentation. An explanation about how is the CMS integrated within the Laravel base app (how is routing done, more details about the "Repositories", etc), would be great too.
About the screencasts, some of them are a bit hard to follow, especially the front end one (), in which you have to guess the view files in the first minutes of the video are placed in the theme and not in the module itself [and those "pre-made" views in the video, most people get lost there, because it's confusing from where are you taking it].
About the IDE... It's up to any user to use whatever they fit their needs, but PHPStorm, being proprietary, it's not available to the whole public. Anyway I don't care about the IDE or whatever text editor you use. The only thing I'd suggest, is keep to a minimum the use of boilerplate generators in the screencasts (e.g. creating Classes), or at least, give more details about what the boilerplate includes. I use Emmet for instance, and yay, it saves you time and typing, but in a screencast/tutorial that's not the whole point.
Having said that, I would like this lines to be understood as a positive critic. I know making documentation and screencasts is very time consuming, and requires time and effort. So I'm thankful for the efforts the AsgardCMS team has done, and I'm up to collaborate to the improvement if needed, not just demanding.