Assets Plugin

We want a plugin that can show a subdirectory of assets, offer links to those assets, and add more on drop.

Here are assets at the top level.

Here are assets from Soviet Control Panels

soviet

We filter out directories and dot files from lists. Thanks Paul for some help here. I was using async v1.5 code and v2.6 docs. Never a good idea.

We upload files as multi-part forms. I found better example code much closer to what I wanted to write. Example has progress bar which I have added. post

The server checks that the user is logged in before uploading. Upload errors are reported in the progress bar.

The client checks that the page is not remote before even offering to upload. This way one is surely seeing the files that the upload will join.

Would like to sort items by age with "since" logic.

Would like to add a delete button maybe on hover.

Issue: fork should refresh the list with files from the new site. It doesn't. An doing so is not simple.

# Semantics

Now with the most obvious behaviors coded if not debugged we think ahead to how this plugin should operate in wiki's sharing environment.

implemented

A configured Assets plugin provides two-way access to a subdirectory on a server. Exactly which subdirectory and exactly which server are yet to be defined.

For now we are selecting subdirectory based on markup. We could factor in page slug or item id to provide additional isolation should that prove desirable.

Reads should certainly go to the site hosting the page with the Assets plugin. This would change should one fork a page with such a plugin.

Writes are by upload button which is only visible for pages served from the origin.

Lists of assets for all sites within a context following some sequence like collaborative links: origin, page, and by sites forked from the journal.

considering

We could expect the fork to copy the visible files along with the page json but we might find a lazy approach more appropriate for large assets.

Writes go to the origin as is always our practice. This will remain true even if one drops files onto an Assets plugin from a remote page. We could insist that the remote page be forked as a consequence of the drop to guarantee that the file remains visible to the owner.

Lists of assets could be merged for all sites within the neighborhood. This is how Recent Changes views pages at least in the default configuration of the Activity plugin.

Merged lists should identify by flag where it found the assets it offers. We have many examples of dealing with twins already. The presentation should suggest the sharing semantic we choose. Some click sequence could be the signal that we want to acquire an asset. Plugmatic suggests how this might work by bringing up a list of alternatives.

# References

Sending multi-part forms with jQuery. stack overflow

Node.js middleware for `multipart/form-data`. github

A simple example of using Express and Multer, with or without Dropzone. github

Dangerous use of express body-parser. post

Tus is a new open protocol for resumable uploads built on HTTP. github

Uppy uploader integrates with any framework, fetches files from local disk, Google Drive, Dropbox, Instagram, remote URLs, cameras, etc. site

# Tools

Install the plugin.

wiki-plugin-assets

Find sites in the federation using the plugin.

SEARCH PLUGINS assets

Find use of an asset within origin's pages.

ITEM html TEXT 2017-09-15

We url-encode images dropped on the factory plugin. This captures the sharing dynamics expected of the federation but it doesn't match with current asset practices.

We can now store pitchers and other large assets and serve them from a wiki site.