What?

curl "https://id.loc.gov/suggest/?q=philosophy&rdftype=Topic"

["philosophy",["Philosophy","Philosophy and aesthetics","Philosophy and civilization","Philosophy and cognitive science","Philosophy and religion","Philosophy and religion in literature","Philosophy and science","Philosophy and social sciences","Philosophy and the life sciences","Philosophy in literature"],["3 results","1 result","1 result","1 result","1 result","1 result","1 result","1 result","1 result","1 result"],["http://id.loc.gov/authorities/subjects/sh99005065","http://id.loc.gov/authorities/subjects/sh2014002232","http://id.loc.gov/authorities/subjects/sh85100998","http://id.loc.gov/authorities/subjects/sh91002431","http://id.loc.gov/authorities/subjects/sh85100999","http://id.loc.gov/authorities/subjects/sh94007815","http://id.loc.gov/authorities/subjects/sh85101000","http://id.loc.gov/authorities/subjects/sh85101001","http://id.loc.gov/authorities/subjects/sh2011000338","http://id.loc.gov/authorities/subjects/sh85101002"]]

LoC groups by LABEL! not by URL. which makes no sense for linked data

What is this?

Mostly a heads up for @giancarlobi and @mitchellkeaney. Webform keys since Drupal/Webform:5.9 now can be in any case. Means elements with mixed case can be loaded by our webforms too!

For some reason we managed/decided to use the old behavior in our advantage to hide elements, but now that won't be possible. We still have the : sintax (prefix) to aid in that. Not a big issue, but still good to know.

On the other side this opens semantic 1:1 options with defined formally defined schemas and ontologies. cool!

Some updates i got from moving to 5.10

[success] Cache rebuild complete.
 --------- ----------- --------------- ---------------------------------------- 
  Module    Update ID   Type            Description                             
 --------- ----------- --------------- ---------------------------------------- 
  webform   8170        hook_update_n   Issue #3064070: Split STATE_DRAFT into  
                                        STATE_DRAFT_CREATED and                 
                                        STATE_DRAFT_UPDATE.                     
  webform   8171        hook_update_n   Issue #3066994: Form elements keys      
                                        (machine name) to be in all cases not   
                                        just lowercase.                         
  webform   8172        hook_update_n   Issue #3073995: Setting to enable ajax  
                                        on all webforms.                        
  webform   8173        hook_update_n   Issue #3076086: Allow confirm email to  
                                        use flexbox.                            
  webform   8174        hook_update_n   Issue #3084531: Allow Email handler     
                                        add additional parameters.              
  webform   8175        hook_update_n   Issue #3087865: Webform email handler   
                                        default subject is missing title.       
  webform   8176        hook_update_n   Issue #3086507: Allow wizard pages      
                                        bar to be updated based on states API.  
                                                                                
  webform   8177        hook_update_n   Issue #3082822: Anonymous role view     
                                        submission via secure token.            
  webform   8178        hook_update_n   Issue #3095275: Allow webform           
                                        management filter by default category   
                                        and states to be customized             
  webform   8179        hook_update_n   Issue #3101300: Allow 'Save' (update)   
                                        action label to be customized.          
  webform   8180        hook_update_n   Issue #3103171: Move deprecated jQuery  
                                        UI buttons element into a sub-module.   
  webform   8181        hook_update_n   Issue #3103032: Move deprecated         
                                        location geocomplete element into a     
                                        sub-module                              
  webform   8182        hook_update_n   Issue #3102996: Move deprecated         
                                        toggles elements into a sub-module.     
  webform   8183        hook_update_n   Issue #3103571: Move deprecated icheck  
                                        support into a dedicated sub-module.    
  webform   8184        hook_update_n   Issue #3094270: Add webform variants    
                                        support.                                
  webform   8185        hook_update_n   Issue #3104049: Exclude attached files  
                                        from email submission values.           
  webform   8186        hook_update_n   Issue #3108150: Save numeric            
                                        properties as numbers instead of        
                                        strings.                                
  webform   8187        hook_update_n   Issue #3108266: Update external         
                                        libraries. Display warning about        
                                        InputMask.                              
  webform   8188        hook_update_n   Issue #3097101: Remote Post cast        
                                        boolean and numer values.               
  webform   8189        hook_update_n   Issue #3108433: Allow users to          
                                        personalize the submission list.        
  webform   8191        hook_update_n   Issue #3121814: Webform submission      
                                        check taking a long time.               

What legacy code in such a novel project?

We have. Initially most of the processing logic was in the webform handler. We moved in Beta2 and beta3 a lot into EventSubscribers. But we left for fear (because we care about your files) some code that did the same in the webform handler.

We can now get rid of that code and make processing faster. The associated pull will also include some other tiny housekeeping changes, mostly cosmetic and related to performance.

Thanks

What

http://api.geonames.org/postalCodeSearch?placename=New%20Paltz%20(NY)&maxRows=2&username=YOURUSERNAME based on http://www.geonames.org/export/web-services.html

Basically:
1.- We need a new element quite similar to Open Streetmaps nominatim
2.- A geonames endpoint (this one requires authentication so a form/setting for it)
3.- Add also to both (nominatim and this new one) autocompletes based on LoC Geographic names?
4.- A tiny map?
A simple design.. something slim that matches what the other LoD elements look like

@alliomeria
@jenpalmentiero @senyzspalding watch this one

What is this? Yet again another webform thing?

#41 and #26 are all ready a little bit high on feature requests so wanted to move this feature to its own ISSUE.

The work i have on #41 allows an orphan Metadata edit session to be recovered if the user followed all the steps and pressed 'Save Metadata' (which will change to a different name) but did not press 'Save' on the Node form. Basically no new Node/ADO was created.

But what if the user goes away in the second step or the form is huge and the user wants time inbetween or wants to come back next day because the huge IMAGE never uploaded but feels not OK with creating the ADO anyway without an image/or because the system admin made the IMAGE upload required for that webform? So many uses cases! 🤣

Well i want to have a 'Save Draft' or 'Keep my progress around' button that triggers something different. It will just save whatever current state the form is in. So if some step is missing, that is Ok. This 'Keep my Progress around' can not generate a new Node until retaken and all steps are finished and we end again with either situation that #41 is dealing with or the node is saved. In both cases the WIP is deleted/purged.

How?

This requires two things to happen

• Another entry in our Drupal private store (means only the same user can see it)
• I plan on having a single one per CMODEL/Webform combination (for new Objecs) or simply based on Webform/UUID for objects being edited and drafts should also auto expire so we don't have to be cleaning stuff around. They can not be edited/nor manually loaded.

Code

• On every Edit/Create (for every a submit process triggered by a special Keep my Progress around button, or even automatic means next/back/save? what do you think) take whatever values are already validated and save them there.
• Next time, on Create/Edit. See if an abandoned session is around (#41). If so, WIP/Draft is not even important and we won't load it. Actually (jajaja coding as i write) i should delete the draft if there is an abandoned session, since it will fulfill the same role! (good i thought of that!)
• If no abandoned session is around, load the draft, but! Here is the beauty. The Draft should also contain the last step the user was in (where they either pressed this Keep my Progress around or auto save happend. And i should be able to programatically move the user to that step.

And will also allow, same as in #41 a button that when a temp is loaded, any of both, you can of course also always start fresh and avoid this values.

@giancarlobi mentioning you here so it does not look like i'm talking to myself (which i am hahahaa)
Is my idea idea clear @mitchellkeaney?

Use case?

Connected/glued to See esmero/format_strawberryfield#20

Building Tours using Panoramas, adding hotspots and bind them together is every Developers dream..eh nightmare..well, still a dream.. second part. But, we can do this. Museums will love this.

How

New Webform Element with extra deep nesting and weird logic. That allows people to load a panorama Object, add hotspots, Load another one, connect them. Save. JSON. Bum.

When? Who?

I did it. Its mostly functional right now, but moving in the right direction. SO MUCH javascript and some much Form API mangling, its quite crazy. Too tired to explain the how. In the meantime i will push some Code and lets see tomorrow.

TODO:

• all fields, need more validation
• This needs a theme preprocessor and a template
• Needs conditional Options
• I need to remove DPM messages and error_log ones.
• This needs settings forms. Right now stuff like the autocomplete View name is hardcoded. BAD
• I found 2x bugs (more like a bad assumption) in the main Webform Module. Will see how i try to push changes upstream. Good luck with that Diego

What is needed?

Option to have a composite element that allows an initial data, a final date and checks if dates are actually a range.

I should built this

What is this?

Panorama Tour builder is working OK. But we need to make it stronger and more failsafe. This issue is to add better field validations, more config options to the webform element and also theme by default the App in a better way, but also to address some user facing issues like linking to Other Objects in the repository and allowing a full screen loading of those instead of a pop-up window like we do right now (Thanks @giancarlobi ).

Should also include the needed Views (we ship them in Archipelago-deployment) and a demo webform for people to test this out. Thinking also on sharing a screencast so people can WOW on how much these 1000 lines of code can do.

Work has already started and moving fast!

What is this?

Similar to the existing but too simplistic wikidata agent element, we need one that has selectable origins (sources), LoC, VIAF and also a preset list of Roles, and also type of Agent, so Personal, Corporate, Family Names.

This is a multi element compound. Good!

@jenpalmentiero @senyzspalding watch this one!

What is the issue?

Well, Safari Browser feels smarter than us when dealing with audio and video. See https://stackoverflow.com/questions/19107685/safari-input-type-file-accept-video-ignores-mp4-files

Right now webform adds only accept="video/*" to the file input and even if we add more extensions, mp4 can not be selected. Fix is in that stackoverflow.com question. We need to do this in our module. Not complex.

Also, another thing nobody has, we should allow Camera access for phones and tablets. Guerrilla digitalization!

What is this?

If a webform is not properly setup to use the SBF Harvester Handler and it is used in a Widget (e.g the inline one) to feed a SBF field during edit/create then it will allow you to follow all steps but fail at the end. The failure message also is not explicit enough and we can actually avoid the whole process because we know it will fail upfront. OR/ALSO we can act and give it automatically a default handler by modifying the form before it gets attached. That would allow any Web form to be used easier/directly out of the can and less navigating and mouse /trackpad overheating would happen because of how Drupal loves to nest deeply menu items.

@alliomeria thanks for listing and looking at my screen while a ramble.

What?

Show file upload progress bars for large uploads

See 👀 related issues:

• esmero/strawberryfield#76
• esmero/archipelago-deployment#70

What?

If no webform is associated for a Form Mode (in settings), show users a notification message instead of an error.

What is needed?

Webform widget based input (Form mode) has a placeholder to allow people to set a different than the field label title on the webform container. Sadly its not being used correctly. Its just a matter of forcing, if the setting is preset to be used as the element #title.

This is mostly cosmetic but helps a lot with making non admin users ingest process more verbose.

What is this and how many dad jokes about strawberries and planting can we all take?

Pretty sure you can all take a few more!

This is something i have been working on for a few days already and is coming into 1.0.0.RC1

We have now an XML file upload and processing Webform element which allows people (non devs) to upload a single XML file and get it processed and normalized into a given standard JSON structure so that the Strawberryfield can save it and hopefully do something cool with it. I even added a new branch, ISSUE-10c (pull to come when happy enough) inside Strawberryfield that does a quite smarter XML processing by making sure that independently of if there is a single subelement, or many, the way we/you/thing-that-this-pull-is-about access data is consistent. Consistent also means redundant, but cheap machinable v/s super smart(arbitrary data structure, not cheap to process)

Ok, don't get lost here: Imagine you imported an XML (EAD V3) and you got this now

 "ap:importeddata": {
        "content": {
            "ead": {
                "archdesc": [
                    {
                        "did": [
                            {
                                "abstract": [
                                    {
                                        "@value": "This collection contains the writings of Leonid Mikhailovich Savelov, an historian and genealogist. Included within this collection is a memoir penned by Savelov, and poetry written by his daughters."
                                    }
                                ],
                                "physdesc": [
                                    {
                                        "extent": [
                                            {
                                                "@value": "0.4 cubic feet (1 manuscript box)"
                                            }
                                        ]
                                    }
                                ],
..

So how do i allow people to see the quite nested "abstract" element as a simple Textfield Webform element and edit it? I need something that reads from this complex structure and brings it up, to the surface.

That is what the Transplanter is!
Its a Computed/Processing Webform element, that takes can read from all the data that is passed and uses a Twig template that can transform data between structures, from a given source (in this case ap:importeddata": { ) and via simple code outputting a new JSON. This JSON of course matches (or not) keys/values of user interacting webform elements and updates the current submission allowing the 'Imported and now editing' magic to happen in a quite customizable manner. And it can have some cool logic, like 'Well, not an EAD? Do nothing, or even, clear the source values (remove the imported XML) if a certain mapping was done perfectly, or not override values set manually by the user/previous submission, or the opposite!

Of course right now it does just a few, the most core things of this, and of course as any strange code we write will need docs and use cases, but this will even allow CSVs to be uploaded, Data packages to be preprocessed and some crazy archiving goodness to happen.

@giancarlobi @alliomeria any questions about this? Too surreal?

@TODO: I should make the processing as generic as possible so ingesting/mapping XML can happen via API too.

What? Override? Let people decide? What is this, democracy?

Well, yes. It is!

Now we have this default: "Thanks, you are all set! Please Save the content to persist the changes." but maybe people want their own, so we respect people's choices (also VOTE)

The website encountered an unexpected error. Please try again later. Error: Call to a member function getSetting() on null in Drupal\webform_strawberryfield\Plugin\Field\FieldWidget\StrawberryFieldWebFormInlineWidget->formElement() (line 212 of modules/contrib/webform_strawberryfield/src/Plugin/Field/FieldWidget/StrawberryFieldWebFormInlineWidget.php).

Not sure if is still valid on RC1 but we need to check. Also the fix is super simple

What?

If you are upgrading/changing your webforms and you want to move from a single valued key, e.g "contributor":"Diego Pino" to a multiple valued "contributor":["Diego Pino", "Allison Lund"] and you update your webform to allow more, the webform element does not know how to read the single valued and stored key. The opposite funny enough works. With the down side that if you have multiple values and you read them via a single valued webform element, on saving you loose the previous/not editable ones. But that is to be expected and can be documented.

What is needed.

We can check which webform elements are multivalued during our widget initialization. Either on the widget itself or via the Controller that allows Ajax/and inline rendering to happen. If a given webform element is setup to be multivalued we cast the corresponding keys to an array. And that is all

If we should inform (log) the operation or not is another topic. Informing the enduser will just lead to confusion but a metadata specialist/in charge of the repo would want to know about this.

This Bug/Feature need was detected by @alliomeria testing RC1 Burt exists since ever, it is the way Webform module deals with value loading for every element and most likely related to the fact that the internal webform submission entity is quite strict. This does never apply to File Upload elements, that logic is written correctly so does not need us to interfere.

what? how? when

I noticed exifinfo is showing unix file permissions -rw -r -r for uploaded files. Does really make no sense, files are temporary when we show that and also we don't want to expose that data. Basically we need a whilelist, graylist, blacklist of EXIF tags.

See esmero/archipelago-deployment#54

Basically fix the last deprecation notices and bump compatibility version to 8.8 | 9.x, remove (Gosh Drupal it was never deprecation i had an IF around!!) last conditional to make 8.7 work well. Not needed nor possible if we want to allow 9.x

What is this?

What the title of the issue says. The button does nothing if there is an ongoing session. Explicit

How to fix?

Clear button will have to clear the Temporary storage loading mechanism so when the form reloads it does not start from saved values again.

What?

Create a webform File Upload Element for Frictionless Data Packages

Why?

To enable the upload of complex (but not necessarily compound, hierarchically-structured) digital objects with multiple files of various file/media types as Frictionless Data Packages.

Example Use Cases

• Thesis submission that consists of a .pdf, a .csv, and a Tableau(.twbx) workbook file
• Project files for an educational video game that consist of multiple .pdf, .psd, .jpg, .mov, .html, and a .zip (containing even more files of various types such as .mb, .mel, etc.)

Problem

Our approach on having a single ADO (Archipelago Digital Object) Content Type by default has proven to be a good choice for flexibility and data management. Even when people can add more Content Types and extend this basic idea to many different Drupal Bundles, we need a good way, via the UI, when using Entity Reference Fields, to target not only a Bundle (in this case our ADO) but also those ADOs that have a certain JSON type key (or rdf type if you think about that in a semantic way.

Drupal's built in functionality to autocomplete and resolve entities for those fields is only Bundle based, means we can only target all ADOS of a single Content type, or, via a more complex mechanis using a Drupal View. Sadly all the code that is provided has issues and is, strangely, only capable of SQL queries for doing such tasks.

Need

Build a new type of EntityReference Views Display mode and also a new, better, @EntityReferenceSelection plugin capable of interacting natively with the searchAPI driven Views. This will allow us to target complex, JSON value driven selection of ADOs, useful to limit our semantics to only certain types, permitting interessting UI/UX choices like Compounds that are limited to only a certain Parent type and a few Children types. One specific use case is the Panorama Tour builder, where we want a certain aggregation to be built that uses other panorama ADO as source for the scenes, and hotspots restricted only to Audio, Video and Image.

I finished build that code in the few last days. Its not something fancy but i feel it is core for our next steps in Archipelago. This will allow us to build much better Webforms, better selection options and will also this functionality to be used on Admin Forms all over the place (even for Batch editing certain types). Also, this is something absent in the Drupal world right now, so feeling pretty confident we are, again, making some innovation that, even when humble (not fancy!) is very useful.

lastly, this code allows much faster execution and validation of Entity references, by exploding Solr as source instead of what others have via SQL.

@giancarlobi will ping you on the actual pull request to discuss code and how to test. Thanks!

Editing object by webform, I cannot upload a JP2 file by Chrome and Firefox because both don't show file with .jp2 extension into file system browser.
@DiegoPino investigate and found that the HTML call includes accept=“image/*" but both browsers don't have "image/jp2" into option list. In addition @DiegoPino checked that if we have an explicit request into HTMl as accept="image/jp2,image/*" (by Chrome Dev tools) then it works.
He suggests two solutions:

• allow upload of any file type without any HTML check and only validate file after upload
• when jp2 allowed into webform, make an alter and add an explicit ref as accept="image/jp2,image/*"

What in tarnation?

I recently created a new webform from scratch. To my own fault, I did not follow this documentation which, had I done so, could have evaded hours spent scratching my head and running the same test over and over.

However, in spite of negligence, something curious was uncovered. Before following the steps to get the new webform to talk to SBF - which was the entire section of this process that I had skipped - I would edit my existing content type (in this case, a Digital Object Collection) by adding some metadata via my new webform, save it, and then to my surprise a new Digital Collection Object would be created as a duplicate of the most recently edited (or created) Digital Object in my repository. This new Digital Object Collection would have all the same metadata and info as the Digital Object but when viewing this object, it looked the way a collection would be displayed (i.e. no images, no description, and a section for "Objects in this collection").

I'm not entirely sure exactly what this means, or why it was happening. @DiegoPino I know you probably have an answer or at least a better, logical understanding of why this would be. I'm guessing Archipelago, here, is trying to make sense of the new data given to it via a webform that is not configured to speak to SBF and therefore spits out a version of an existing object.

What are you trying to do here Diego?

A long time wish almost made reality. Self Deposit and Anonymous to logged in progressions. Allow the handler under certain scenarios (attached to Node, its own endpoint or via a deliberated State change) to ingest/update existing Node bearing a SBF.

To allow this our handler needs to be tiny bit smarter and act in a modal way depending on how the form is being used
1.- Current scenario/used as a widget nothing changes
2.- In a standalone scenario (its own URL) create a Node of a selected type of bundle using a pre-set mapping of Webform Element Values to Node Fields
3.- When already present as Webform Submission allow an extra Task/action and trigger a new node Ingest.

Why?

In an IR/Complex workflow setting we may have people submitting data as anonymous or even in a non widget/Node scenario. This can be even without Ajax enable and even in a case where certain Webform Element values will become part of the JSON and other will not (or will also) become part of a more complex Node/Entity Mapping.

What?

We have webform advance on the Progress Bar. WE need to make sure the autosave that is trigged on "Save" at the webform level triggers every time we move forward/back. And enable a Save Draft button that does the same respecting settings and permissions.

This also requires the long pending Settings Form for the permission

What is this?

A self reminder for me or anyone editing/coding/adding new composite Webform/Form elements for the Webform module.

If you check for such an element under

• Advanced -> Multiple Settings
  Display elements in table columns

This method, normally called and which i really need to use like a lot
https://github.com/esmero/webform_strawberryfield/blob/8.x-1.0-beta3/src/Element/WebformWikiData.php#L58
Gets never ever called.

Why?

Well someone thought it was fun to call a different method (and change getInfo #process callbacks) when Multiple wrappers element is enabled. To be honest, i spend hours trying to figure this out. Such a bad experience. Basically the process Multiple wins over the Process Composite killing all my hopes and dreams.

\Drupal\webform\Element\WebformMultiple::processWebformMultiple

As stated here
https://git.drupalcode.org/project/webform/-/blob/8.x-5.x/src/Plugin/WebformElement/WebformCompositeBase.php#L166-198

How did i find out?

By (frustrated attempts) adding and removing Wikidata Elements because my current one was not reacting to all my new cool code. Gosh

How do i fix this?

The fix is needed to allow (in case of multiple elements and composites like LoC or wikidata element) a part of it to be hidden (no access) but still get data saved. So i will need to implement a lot of extra code to wrap that around.

What?

This issue is related to #22 - currently we have a webform element that takes location input, resolves it using it the Open Street Maps/Nominatim API, and returns possible matches in GEOJSON.

We want to add a a method that uses the same API in reverse. This means:

• Add ::reverse method and modify NominatimController.php so we can call https://nominatim.openstreetmap.org/reverse?<query> as per these docs.

Why?

Don't ask me why(serious developer face here)

But it is needed.

How?

Direct input of a MARC21 text file and we process the data based on rules/fixed vocabulary/ twig template to fill up whatever the current webform has

What else?

A processor/post processor in case people are not ingesting via a webform but via batch

@alliomeria

What is the problem?

When ingesting an Object using Webforms and hitting at the of the multistep process the Preview button, some Webform Elements have not #type attributes, there is even an empty one. This was introduced on Webform 5.2+ and could not reproduced on our previous alpha. The effect of this is an invisible error to the user (because we are using Ajax) and the Webform Content is never submitted to the Private storage which is then the responsible to feed the Field itself on Node Save.

How to fix?

Simple, we need to check for the existence of the key before trying to generate all the Buttons that allow people to go back to some of the many Webform steps.

Still, i need to make more tests here, i'm blaming that error for everything but again, there could be some other obscure changes in the Webform Module that could be affecting us.

I will push a fix in a few minutes and update our open beta1 branch. We should also provide an update.sh script on our docker deployment branch so people can just upgrade to the latest hash of everything archipelago during testing without having to hit composer directly for each package.

This will be adding another vocabulary from Library of Congress that is specific to names

http://id.loc.gov/authorities/names.html

What?

Add a new Webform element for tagging files

What is wrong?

We have the following config errors related to webforms visible under http://localhost:8001/admin/reports/status:

• core.entity_form_display.metadatadisplay_entity.metadatadisplay_entity.default: 2 errors
• core.entity_form_display.node.digital_object.default: 2 errors
• core.entity_form_display.node.digital_object.super_admin_raw_json: 2 errors
• core.entity_form_display.node.digital_object_collection.default: 2 errors
• core.entity_form_display.node.webform.default: 1 error
• webform.settings: 3 errors
• webform.webform.descriptive_metadata: 2 errors

How to fix

Add a file to config/schema with the appropriate schemas.

What?

Instead of only allowing a single Webform to be accessed per Form Mode, add a "widget" that could be used to select/pair a particular Webform based on a JSON "type" key (e.g. Article).

Why?

To allow more fine-tuned configuration for what Webforms are being used for editing different types of objects, and/or are being accessed by different types of Users.

What?

For the Open Street Maps Location webform element:

• Configuration for Help is not available in the "Form Display" section of the element settings.

• Information entered into the Help section of "Element Description/Help/More" of the webform element settings does not display (to users) on the webform.

What is needed?

The ability to configure and display Help information for the Open Street Maps Location webform element.

Webform module in its most recent version does not persist element defaults in its YAML / ELEMENT definition and assumes developers will use internal methods to access those defaults if needed. Well, we depended on being able to fetch whatever value we needed (default or set by the user) from the element info in our LoC autocomplete element. Now that was broken for people building new webforms with custom needs.

Fixed via 26aa691 and
529a9cd
had really no time to make a pull and such and this is retroactive since #61 (ISSUE-60) contains the fix too.

Need

Now that the bookreader formatter is out we need a way to allowing people uploading individual pages to define the ordering of those, so the Manifest Templating system can avoid doing any logic at all.

How

The approaches are many:
1.- Generate an extra Form that deals just with this. Would allow to move Pages around without having to pass through Metadata validation on the main forms
2.- Incorporate a custom webform element that allows drag and drop for uploaded images
3.- Generate a TOC element that simply points to the pages in a defined order. (This is the lowest hanging fruit). This one would allow to just "add" a structure instead of affecting existing ones

Additional Issues

JSON encoding/decoding is not respecting Object ordering. So we need to check on that, maybe we need to just enforce a flag there or deal with the fact that the DB serialization applies some type of normalization.

The Problem

Our webforms integration works by dynamically loading a Webform, with a special Webform Handler from inside a Widget logic. Since Every widget is also loaded inside a wrapper, Node Entity Specific form, we have Basically Two different "Save" buttons.

• One to Preserve all the data input coming from the user while filling this webform, and handled by our custom handler on the final (or sometimes the only) Webform Step
• The Content Entity Form (a class initialized by the Content Entity Class) that takes our Widget input, but also any other Input and actually triggers the Node Save action.

What we want

We want a few things here, most related to the Issue at hand, but also a bit wider into the Webform integration thing (like Ajax used, what happens if they don't want ajax?) and this leads to different tasks and solutions:
1.- We want to research use cases/empiric workflows using the current code. Like what are the normal operation steps on ingesting an Object. Are we displaying/hidding enough functionality so Users don't get confused by the fact there is "Saving Metadata" action, and a "Save the whole Node" action and both are different buttons? Other ones

• what happens when people do things we have not expected, like preview, back, edit, preview again. etc.
• How do we deal with the fact that Users can customize their Webforms a lot? Can we enforce in our widget enough defaults so even when they do change per webform settings we are still operational and no data gets lots?
• Can the user go back to edit data once it pressed the "Webform" version of Save button?
• Are our Labels explicit enough?

So this first part is building use cases, building webforms and Form modes and testing them thoroughly, annotating issues, bugs, problems and in general worklow expectations v/s reality

2.- We want a more (as an Widget setting) seamless ingest experience, which in my opinion means:

• Single Save button. Which of the two buttons is the one triggering the metadata save and the node save is of course the question, and is directly related to how good we are dealing with Drupal's Form API which is not a simple tasks. Gist here is Buttons have Submit handlers, those get attached on Form build and take over functionality. Also there are Validation callbacks that run.
  • We could make sure that one of the buttons is able to call the other button's callback if its working in the context of a Widget (means the webform is used to fill metadata, not just testing or building it).
  • We could skip validation steps or do programatic validations on existing, loaded data so people can jump from one step to another. We need for that make sure in which context validations runs.
  • We can keep temporary values longer around, or write them every time someones passes a validation. That way people could, e.g change Page, come back to a new Object and they could continue filling Metadata without having to press "Webform Save" button.
    Note: we need to have language here to speak about the two save Buttons: Lets call the Webform one "Webform Save", and the other one "Node Save". Same goes with "Preview" buttons.
• It would be great to be able to operate without Ajax too. Which would imply we "We can keep temporary" values around, and when user finishes filling the webform, it gets redirected to the node edit form again and those temp values are loaded so they can fill out the rest

3.- As part of this task, we want Webform to "inform" data to other Fields and their Form widgets, in specific The Node Label. Because the Node Label displays its own widget (breaking the natural rendering order and making some people angry), but Node Label is required and a must for an ingest (If we plainly hide it?Ingest simply dies!) we need to add code to our Webform widget and settings so any Webform Element (our own internal Webform "title" input) can feed, on Node Save its value into the Node Label. This could be even done more generically for other Node Fields too.

This is a large and super-duper important Issue. I feel we have come pretty far with this but now we need to become Webform Pros and Form API wizards. No more time to loose and all this is needed. I would say from this one at least 4-5 Pulls can come out, but also a full set of Webform Research experience and long UI/UX driven conversations. I can share in the comments some Code pointers to get this started.

@marlo-longley @mitchellkeaney @giancarlobi

Problem

I have been exploring the build in options for converting Geographic names into Lat, Long or even Polygons and all what is shipped with drupal/webforms requires an API token (and money to pay), also the output is quite limited for our granular metadata needs.

Need

Borrowing work from myself past, i will build a https://wiki.openstreetmap.org/wiki/Nominatim webform element. I used that extensively to reconciliate Human readable locations against Lat/Long for Solr in my Biodiversity work and lot is written in PHP already. Also, thinking about standards, any hard feelings on using https://geojson.org inside strawberryfield to store the output?

@giancarlobi what do you think? I feel locating/pinpointing things in space is in human nature, and in metadata professional needs nature too, so why not.
Also, adding http://www.getty.edu/research/tools/vocabulary/tgn/ to our already existing Getty implementation for an element, could be an extra here. Let me know if this sounds feasible and we can add this to our roadmap.

For an EAD we are looking to have this group of fields repeatable. So for example for a person maybe they will do a date of birth, date of employments, and date of death. I can't think of a way in doing this on what is available.

This is an example of the group

Use case

This is actually an interesting one. I just had the idea that maybe i would want to have a Webform that is able to only affect, interact in the scope of a certain JSON Key hierarchy (e.g not the root metadata).

Our current Good-for-everything Widget can load a full JSON and affect it completely. But for things like, just adding a Label to an image, Or changing the sequence order of a Book, or adding Subtitles to a video, i would like to attach a particular Webform to the as:image or as:audio key (which we, on purpose named like that so webforms could never ever read them and also of course to distinguish them from user provided metadata v/s managed by us ones)

This widget could also allow certain level of compounding to be managed directly on a single SBF bearing node or even allow a full webform to act as a set of sub properties reader/writer of another key, when Webforms has issues dealing with too much nesting and we don't.

How

Same as our current one but with an extra configuration: Key to which to attach. Extra code would imply only working on those keys, means read the whole field value, get only that key, pass only that key values to the webform, on return, only update values inside the original passed key. Extra benefit is here we can allow a level of total isolation, in which users can be only working on certain hierarchies, but also, allows us to use Webforms as a way of interacting, in a controlled way, in our own managed keys. One good use case are image annotations!

When

between 1.0.0-beta and 1.0.0

This is:
1.- Date/ Metadata Date and Hierarchical Subjects/Authors, etc.

Fix this be generating a Pre Rendered Value

On Authors selecting: RAW as Submissions display.
But not on dates. Double check

The use case.

You want controlled vocabulary autocompletes from wikidata. We got you covered. You want to hide the URL from the user and don't even allow them to modify it. We have you covered now! Commit comming.

Next step: same for every other Vocab/LoD element

What?

We added skipping steps, not good for every use case.

Deal with this maybe as Access/Permission element in the Handler (Strawberry handler) that allows this option to be disabled/endabled

High urgency on this!

What

We are using (thank god) a lot of built-in Webform Elements. We try to deal with the most Metadata inclined ones ourselves by providing functionality the core Module can not and will never want to provide. That is good. But! We totally depend on the build in Webform File Upload Elements for all our UI driven media upload and delete needs. Sadly, that Field is little aware of our many peculiarities so we could need to enhance it, or maybe even totally replace it:

Which Peculiarities? (Our Snowflake Syndrome)

First some requests we already got

• Image Previews on Upload. Actually, it allows that. But sadly in a pretty limited/drupal-ish way. We use S3 or even Private Storage sometimes for uploading. And where a given File will be found is also different if it was recently (same Input session) uploaded or is being read from a Stored JSON/Digital Object. Since we use IIIF a lot, but for new Uploads, IIIF can NOT read the file yet, we need a flexible Preview Method, that can deal with both uses cases:
• Extra data: Some people want EXIF on upload. With @giancarlobi great work and some WIP own code (not that great) i'm adding, we do that on Node Save. If people want preprocessing of Files via some method, EXIF, PDFINFO, etc, and have instant feedback we need to allow a callback to happen on Upload. Good news is we have the code for that! (at least the where) but still we want that to be configurable and not fixed. (Many webforms, many type of users, many workflows, many uses cases)

Our own:

• File Ordering. Would it not be great that if People have N+1 Files uploaded they could drag and drop the order just there? Or select an ordering pattern? See #12, this would be complementary
• ZIP extraction. Someone needs to upload 1000 pages of a book. What is better than a ZIP? (well a PDF jajaja. but we can not be that strict). So, we could have a ZIP handling options, where the user can at least see what is in the ZIP, like a list, or a manifesto) But also option for force (flag) expansion so AP can do that once Object is saved.
• Tagging. Our Metadata Structure allows Tags per as:image.* to be set. Useful when coding Formatters that could act on that (like you have 2 Videos, but you want only the one that says.. "Small enough to be seen live.. i know that is not a tag, just an example people, lets call it access...)
• Select Image that is already in Some other Object
• Get the File from a URL.

I think that covers most of the use cases i can think of right now. You have more?

How? (one of the options or a mix, like JS would go into a mix)

• In the webform handler + Event Subscriber
• Webform Element Alters
• Form Alters
• JS
• New Webform Element

@giancarlobi @mitchellkeaney @marlo-longley who said i? 🙄

This issue is a placeholder to track devices like iPhones, galaxies, clamshell phones, etc and to document how they interact with forms but also how media is handled. Like does your fancy tablet removes EXIF or your panoramas have no GPS?

What?

1. For Webform 5.4
   https://www.drupal.org/node/3045851 adds two new arguments to

protected function buildCompositeElementsTable();

So now its:

protected function buildCompositeElementsTable(array $form, FormStateInterface $form_state);

2. For Webform 5.4
   https://www.drupal.org/node/3052600
   Changes ::preCreate argument to be passed by reference

How?

1. Just in case, check we use this (i could not find any entries.. but hey, i'm human)
2. Totally needed. We are using this methods!

Hi, its me with another "bothering" feeling.

Right now we allow Images to be previewed and exif extracted and display after upload via a webform (attaching screenshot with an example where realtime loading can not happen)

There are toooo many cases where that makes no sense

• HUGE file
• ENORMOURS EXIF
• EXIF not setup?
• HUGE amount of files
• FILE can not be displayed by a Browser nor IIIF
• IIIF can not yet access the file
  So many NO-NO-NOs

Basically its almost an exception.
So question. Should we just recode https://github.com/esmero/webform_strawberryfield/blob/1.0.0-RC1/webform_strawberryfield.module#L308 and make it simpler and less code-extensive?

The code actually acts on the theming layer and to do so needs a lot of 'non' OOP (Object Oriented programing) to do so. This was a request from the ESIE project and has never come up again by anyone else. Of course it can be disabled right now by changing the Preview option in the image element, but i feel it can be cleaner, better, simpler, smaller and with a LOT of limits

@giancarlobi @alliomeria what do you think???

What is this?

A bug 😢 I may have introduced when I coded the new feature where the URL can be put in a hidden field for webforms where the user should not be able to modify a URL coming from the endpoint (or said differently) does not even care.

Its a strange thing and I'm pretty sure its my Autocomplete JS extension. Basically the Label gets pushed into the URL and the URL into the label. Which means Drupal is overriding my action. Since this is new i will check what changes I did and fix! Sorry