grav
grav copied to clipboard
getgrav
[add-resource] New Plugin Studioeditor
Hi there.
Please take a look at the Studioeditor plugin for GRAV, a complex one...
I would like to add the Studioeditor plugin to the Grav Repository. Here are the project details: Studioeditor
Thx.
u
This looks like an interseting plugin. However as it currently has an issue with Flex Objects, and Flex is a required plugin for admin, I cannot approve it.
The reaon is that people will enevitably come to the admin plugin and raise issues that the admin is broken. You need to find a way to resolve your issue so that it works without any manual modification to Grav and the standard required plugins.
NOTE: if it has an issue with some other non-standard plugin, I would let it slide, but as it stands is evectively saying it's not compatible with a base Grav install unless you do these manual steps. And you would only find that information if you went to your repo and read the README.
No problem at all, probably it's not even Studioeditor, smartypants shows a blueprint errror that may be the cause. Good job. Will keep you updated here about my findings. One question: Seems that you are the only person doing quality management, Grav needs a dedicated community manager and a team offering the quality checks... I exposed the problem, I'm quite sure you wouldn't have been aware of the problem without my hint... :-)
Community help appreciated, as stated by @rhukster, the plugin is worth the effort and the community will benefit. Anybody out there?
Whoever wants to be invited as a colloaborator, even as an owner of the plugin, hands up. I'm getting far too old and I'm doing clean up now... Studioeditor is more than 6 years old... and I'm not really working with computers anymore.... I'm doing a last effort to publish things to the wild I've done over the years...
@rhukster: in fact, this plugin (or something similar) should be part of Admin... Would help to open up Grav for many people that feel insecure offering GRAV as a solution to companies, etc. I'll invite you too.
Problem is a flex-objects issue already open: Blueprints that extend default cause a memory overflow.
I've tested this error creating a new plugin to see if I can reproduce the error, answer is yes.
Ok, found a fix. Probably it's documented somewhere, to extend default blueprint via a plugin the extending blueprint shouldn't be named default.yaml, in my case renaming it to studioeditor.yaml the problems gone away, or you can use default.yaml in your plugin but in needs to be full-fledged, no extending. There may be other solutions but that's what I've figured out, all related to Types.php for Page in my case in the system core of GRAV. Studioeditor needs a full-fledged default.yaml to work.
I will publish v1.1.4 later which includes a fix for the media resizer as well
v1.1.4 published. Including fixes for the issues formerly mentioned in README. Please check again.
Published right now v1.1.7 as there was still a mention to problems with Flex Objects in the README file.
v1.1.9 released with additional language sets, fixes for notices, an updated Markdown guide within the editor, etc. Would be nice to get some feedback these days. Thanks.
Finally found what's causing blueprint inheritance errors. Will update the issue for Flex Objects. v1.2.0 of StudioEditor will include the inheritence fix which allows that inheritance change won't break from system over admin/flex/plugins to themes... placing a non-inherited default.yaml like I did before fixed the problem partially as I found out now as this fix didn't make it to theme blueprints. What's working is exposed in the update for the corresponding flex-objects issue.
Summarized: You cannot approve before I publish v1.2.0 :-) (Doing a bit of quality management for myself...)
Testing again in a fresh install with Admin, and it's got problems.. No Editor in view and translations missing?
Also, you probably should use the onAdminListContentEditors() event to have the contet editor show up in the list of editors the user can pick from (rather than forcing it as the default):
example from nextgen editor:
public function onAdminListContentEditors($event)
{
$options = $event['options'];
$options['nextgen-editor'] = 'NextGen Content Editor (WYSIWYM Editor)';
$event['options'] = $options;
return $event;
}
here's some more logic from the onPluginsInitialize() method of the nextgen editor plugin:
if (method_exists($user, 'getContentEditor')) {
// Preferred 1.7+ FlexUsers approach
$markdown_editor = $user->getContentEditor();
} else {
// Grav 1.6 compatibility
$markdown_editor = $user->content_editor ?? 'default';
}
if (($this->configs['default_for_all'] && $markdown_editor === 'default') || $markdown_editor === 'nextgen-editor') {
// Enable the main event we are interested in
$this->enable([
'onAdminTwigTemplatePaths' => ['onAdminTwigTemplatePathsDefaultEditor', -10],
]);
}
...
This basically allows the plugin to override the forms/fields/markdown/markdown.html.twig file to use your own (by adding it to twig template path before admin plugin) only when the user has the editor selected OR if you have enabled for all in the plugin configuration.
If you save, editor shows perfectly. That's not even strange but I can add this behavior. Simply save as with any new page, that's it and you'll see the editor. Thx for your recommendations, will check/implement recommendations in 2.0 on which I started to work.
Right now the default blueprint approach is perfectly valid and at least for this version as I don't want to rewrite the whole plugin. The current implementation is perfectly possible and transparent extending blueprints. Will provide v1.2.1 which will include editor support for new files.
v1.2.1 released, includes fix for the editor display problem for newly created pages.
Please test again.
Now it’s me travelling 🤪Enviat des de el meu móvil...El 24 abr. 2024, a les 13:06, Andy Miller @.***> va escriure: Same problem for me in 1.2.1
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
@rhukster, the solution is pure js as the editor did not initialize given that there's no upload field available for new pages before they've been saved for the first time. This said, you may have to clear the cache of your browser and of the GRAV instance for this reason.