Media multifile #756
Media multifile #756
Conversation
There was a problem hiding this comment.
I generally agree with all this. There's some future improvement I'd like to see before releasing it, but I'm happy to bring this in sooner rather than later.
Other than the fact that this needs tests, I'd like to see us collapse those actions and use states to let folks choose between the three use cases we seem to have for derivatives
- Make a new file and make a new media to hold that file.
- Make a new file and reference it with a file field on an existing Media.
- Don't make a file and instead put the file's contents on a text based field.
I'm fine with making follow up issues for those once we get this in. For now though, I'd say fix up coding standards and we'll iterate.
modules/islandora_text_extraction/islandora_text_extraction.install
Outdated
Show resolved
Hide resolved
|
Following along with @ajstanley 's video, I am getting a WSOD and the following error whenever I access Drupall:
Strangely enough, I was able to select Islandora entity bundle when I created by reaction. |
|
Brand new vagrant, created using the ubuntu/bionic64 base box. I'm getting the same error as above after I switch to the media_multifile branch and rebuild my cache: |
|
Yeah - we changed *entity_bundle* to *islandora_entity_bundle* earlier this
year to avoid naming collisions with another module. Ctools, maybe?
I'm pretty swamped now, but I'll have a look at this over the next day or
two and bring it up to speed.
…On Tue, Aug 4, 2020 at 12:39 AM Mark Jordan ***@***.***> wrote:
Brand new vagrant, created using the ubuntu/bionic64 base box. I'm getting
the same error as above after I switch to the media_multifile branch and
rebuild my cache: Uncaught PHP Exception
Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: "The
"islandora_entity_bundle" plugin does not exist. Valid plugin IDs for
Drupal\\Core\\Condition\\ConditionManager are: request_path_exclusion,
entity_bundle, parent_node_has_term, node_had_namespace, node_is_published,
node_has_term, media_uses_filesystem, media_has_mimetype,
content_entity_type, media_is_islandora_media, node_has_parent,
media_has_term, node_is_islandora_object, file_uses_filesystem,
media_source_mimetype, language, node_type, request_path, current_theme,
user_role" at
/var/www/html/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php
line 53.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#756 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADY2JZ63CFFBA6QGWSV4X3R657HFANCNFSM4KLK3BDA>
.
--
Alan Stanley
Developer and Training Specialist
Agile Humanities
|
|
I'm going to be away from my computer until next Tuesday so no huge rush on my end. |
|
I remerged 8.x-1.x to get rid of the islandora_entity_bundle errors. |
|
@ajstanley tested with "Generate an Image Derivative for Media Attachment" action and works as described. Would be good to have some written docs on how to use this feature but we can do that later. Not sure if @dannylamb's review has been addressed, I'll turn it back to him. |
|
Thanks @mjordan. |
|
Also, just noticed that choosing the "Derive file For Existing Media" reaction category while creating a context is leaving warnings like these in the watchdog: |
|
@mjordan The scalar #ajax error seems to be unrelated - Other than spamming the logs it seems pretty harmless. |
|
Thanks for looking into that warning - I tried to narrow it down to your branch but I guess I didn't do a good enough job. Sorry for the flase alarm. |
ajstanley
force-pushed
the
media_multifile
branch
from
a57f131
to
b9fee73
Compare
|
Giving this another go. If it works good I'm happy to pull it in and iterate further. |
|
I've managed to get follow the steps and set up a media type and context to take advantage of this. Works as advertised. We'll need to iterate on this but it's good to get this in now so we can start taking advantage of it. I'm not super sure what's going on with Travis, but he appears a bit stuck. Also Github is still convinced there's a conflict. I bet if you can get that sorted out it'll kick Travis back into gear @ajstanley |
|
The conflict was with file delete having been added to .info and the
composer.json. Both have been accommodated, but github is having none of
it.
edit - tried again, and it liked it this time.
…On Wed, Sep 16, 2020 at 1:49 PM dannylamb ***@***.***> wrote:
I've managed to get follow the steps and set up a media type and context
to take advantage of this. Works as advertised. We'll need to iterate on
this but it's good to get this in now so we can start taking advantage of
it.
I'm not super sure what's going on with Travis, but he appears a bit
stuck. Also Github is still convinced there's a conflict. I bet if you can
get that sorted out it'll kick Travis back into gear @ajstanley
<https://github.com/ajstanley>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#756 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADY2J7LYNEOANR4GWMAU3DSGDUBDANCNFSM4KLK3BDA>
.
--
Alan Stanley
Developer and Training Specialist
Agile Humanities
|
|
This build is now failing on coder tests a: Passed a week ago and nothing has changed, and b: Involve files I haven't touched. |
|
Sniffs have changed under our feet in Travis. I just did it locally and everything passes coding standards. I'm loathe to let this sit any longer. I'll set up another ticket to deal with the travis issue or bite the bullet and update the sniffs. Let's get this in. Looks like I might have to close this one out via the command line to deal with the conflict. |
|
Oh... and now it's no longer complaining about the conflict? 🤷♂️ |
| } | ||
| } | ||
| } | ||
| return $this->isNegated(); |
There was a problem hiding this comment.
After some digging I was able to find out why my content blocks stopped appearing, was a bit tricky as the cache had mislead me to think it was other problems. Checks for isNegated should not be used in ConditionPlugins as it causes a double negation, since the ConditionManager does the negation.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Condition%21ConditionManager.php/8.9.x
public function execute(ExecutableInterface $condition) {
if ($condition instanceof ConditionInterface) {
$result = $condition
->evaluate();
return $condition
->isNegated() ? !$result : $result;
}
throw new ExecutableException("This manager object can only execute condition plugins");
}
What does this Pull Request do?
Adds the ability to create derivative files to attach to existing media.
What's new?
A MediaSourceHasMimetype condition to allow media-level behaviours based on a Media's sourcefile's mimetype.
A new Reaction to generate files with microservices, and have them attach to existing media.
A new Action to define which queue the file is sent to, and where the returned derivative is to be attached.
A new action to both attach an extracted text file to an existing media, and populate an editable text field with the contents of that file.
A modification to islandora_entity_view_mode_alter to allow media views to be altered as well as node views.
How should this be tested?
With this patch in place all current Islandora Actions, Reactions and Contexts should continue to function as they have in the past.
A user should be able to add a file field to an existing media type, create an Action to populate that field, and create a context to cause that Action to fire.
Demo here. (Rough cut full of typos and stumbling, but you'll get the idea)
Additional Notes:
I'll put a small features module together over the course of the next few days to make a quick evaluation a little easier
Example:
Interested parties
@Islandora-Devops/committers