Hackpads are smart collaborative documents. .

Chandan Singh

835 days ago
Unfiled. Edited by Chandan Singh 835 days ago
  • $text = $essence->replace($text, function($media) {
  •   return theme('embed__' . $media->type . '__' . $media->provider, $media);
  • }
975 days ago
Unfiled. Edited by Janez Urevc , Chandan Singh 975 days ago
Difficulty: Intermediate
Difficulty: Intermediate
Mentors: slashrsm and ?
Difficulty: Intermediate
Pre-requisites: PHP, JS
Janez U Entity browser is a contrib module for Drupal 8 that tries to provide powerful and flexible framework for searching and selecting of entities. There are many possible use cases that entity browser wants to solve:
  • select an image to be embedded in WYSIWYG editor, 
  • select few related content items and "attach" them to another content, 
  • upload few images, then select few more from library of existing media and use all of them in a media slideshow,
  • search YouTube for videos and attach them to a piece of content,
  • ...
Basic implementation of entity browser is already in place, but we need to invest a lot of work to make it fully functional. As a GSoC student you'll work with other contributor to improve various pieces of the module. This will make the project very interesting and diverse (you will get to work with PHP, JS and even some UX design).
If you're interested in this project, have any issues or want to discuss any of the aspects, feel free to ping 'slashrsm' in '#drupal-google' or in '#drupal-media'.
You will, depending on your interests and experience, set the goals together with your mentors. You can expect to:
  • help improving look and feel of entity reference field widget for Entity browser,
  • write integration with entity_embed,
  • improve appearance of entity browser in iFrame and modal display modes,
  • implement tabs for selection between widgets in entity browser,
  • implement configuration UI,
  • integrate entity browser with one or more of the full-featured media solutions,
  • write test coverage,
  • ...
We are open for your suggestions too. If you see anything that could be added and/or improved in entity browser please let us know. We want to make the project interesting to you and we need your feedback in order to achieve that.
1143 days ago
Unfiled. Edited by Dave Reid , Chandan Singh 1143 days ago
Annotation plugin; Describes the categories of things that can be embedded. Should probably describe what type of root element the embed gets saved as in HTML? Should link to a default EmbedForm class?
Interface; A two-step form, first where you provide input or select something, and the second part where you configure how to display the item. Manages commonality of mapping data attributes to form elements, and serializing the elements back to the embed code.
  • Embed form (maybe use Routes instead) + options? 
Dave R
  • Should users be able to pick from a list of possible EmbedForm classes to use for the button? I'm guessing probably not out of the box since the embed form classes are not really "discoverable" in the current architecture.
  • I also wonder if the embed forms would have options. For example with the EntityBrowserEmbedForm the user should be able to pick from a list of pre-configured entity browser for that entity type.
Dave R
  • I think for now, it's ok to define a hard-coded 'form' handler in the embed type much like entity types.
Chandan S
  • I think we should ask users to specify a Route instead of Forms since the JS plugins work on routes instead of Form Classes. This will also eliminate the problem of choosing a Form. Also, we can ask for a preview route and then this module itself can implement all the JS plugins also. Thoughts?
Dave R
  • We could have the form specify its route in our embed form interface. I think asking users to input routes is not a wise idea. I'd rather them get a well-defined select list of forms that could be used, I'm not even sure if selecting a form is something we should expose either. I'd rather leave it out for now, and like entity types in D8, hard-code what class handles the form.
Chandan S
  • This will create a slight confusion since if this module provides the buttons for CKEditor, then those will be visible on the CKEditor configuration UI but not when the actual content is created since the responsibility for writing JS plugins will be of the the corresponding modules. So, I think writing plugins for CKEditor should altogether be the responsibility of individual modules. The embed module should just provide an interface for creating Embed buttons.
Dave R
  •  Trying to just figure out how we can start introducing this module, it seems easiest and less of a burden to *not* try and abstract the JS itself. I don't understand how the user could see a CKEditor button but not use it. That wouldn't happen regardless.
Chandan S
  • Just to clarify the last point, if we create a button whose JS plugin is not defined, it'll be visible on the configuration page only.
Dave R
  • The embed type (implemented by the individual modules) should map to where the JS plugin exists for that module. The button would use that definition, therefore it wouldn't be possible to have a button without a JS plugin.
Chandan S
  • OK, sounds good.

Contact Support

Please check out our How-to Guide and FAQ first to see if your question is already answered! :)

If you have a feature request, please add it to this pad. Thanks!

Log in