What is the best way to override default controller?
Closed this issue · 4 comments
Is there a good way to override the default upload controller with a custom one?
At the moment there is no way to override the default controller. It would, theoretically, be possible to monkeypatch DinandMentink\Markdown\Http\Controllers\UploadController
.
Is there a specific reason you would want to override the controller? Theoretically I could make this configurable, but it would require some refactoring and maybe there's a better way for your usecase.
@dinandmentink I'm currently using Easy Markdown Editor on it's own and have some custom logic around the uploads. Instead of just dropping the file in a disk and returning a link, I save it to a model using the Laravel Media Library by Spatie and then return a url with a random hash. This decouples the url from the actual location on the disk.
This is what my current controller looks like.
public function upload(Request $request)
{
/** @var User $user */
$user = auth()->user();
$site = $user->activeSite;
$this->authorize('upload', $site);
$name = $request->all()['image']->hashName();
$file = $site->addMedia($request->all()['image']->path())->usingFileName($name)->toMediaCollection('uploads');
$data = ['data' => ['filePath' => Upload::getUrl($user->activeSite, $file->uuid)]];
return response()->json($data);
}
Ok. This makes sense. I think I could make this. I'll make a note to add this in a future release. However, I'm quite swamped at the moment so this may take a while.
There may also be a nicer way than overriding the controller. Some kind of contract which specifies how to handle the upload itself.
Note that some of this behaviour could already be done by overriding the directory
config item with a function (see readme). I use this myself for quite similar behaviour, minus the authorization.
Feel free to submit a PR if you want to have a go at it.
Closing; added to internal list of feature requests.
@dinandmentink The reason I cannot use a function in the config is because my config is cached on deploy, but good thought.