More specific selector for site asset block

Don't accidentally get any other .selected-asset than the one in the asset-options sidebar.

(variation on the remaining bit of #1981)

Slight issue: we use the "binary" definition of megabyte when reporting the max filesize for upload in the UploadLimit helper. We might want to keep that consistent here.

The ThumbnailRenderer supports settings for where to direct the wrapping link. FallbackRenderer also uses a link and so should respect the same link setting.

Respect link option in fallback file renderer (#2018)

(fix #2016)

See #2016

The code attempts to do what I think is expected here: it just uses the label. The problem is that the non-custom label is there in the markup, hidden, so the code here is finding both the original and the alternate label. Something simple like calling .last() before getting the text may be sufficient.

Yeah, that's definitely a problem.

Your solution as written has an issue if the slug is string that's boolean false though, in particular if it's the string 0. (We have a separate problem of a similar plain boolean check on the slug in prepareAdmin in this same class that I noticed when checking on this.)

I think we're better off here with a check like !(is_string($siteSlug) && strlen($siteSlug)) for the quick return (=== null would work but I'd like to have it pick up empty-string also so I think the strlen option is clearer). With that in place (and the existing boolean check of the slug in prepareAdmin removed) we'd fix this issue and also correctly allow for the slug 0.

Worth noting that the versions are listed in System Information.

But having them on the theme page seems good too.

Hmm this certainly isn't generally the case with all installs: just as a data point on a local install on a laptop with ~30,000 items, the time of a 4-clause OR "contains" search isn't anywhere near 75 seconds here.

The version of Omeka S and of MySQL or MariaDB you're seeing this on would be relevant, probably. "contains" searches are never going to be particularly efficient by their nature, but if we're talking a minute-plus, that sounds like some sort of pathological mis-optimization going on somewhere.

Check required exec functions for disablement

PHP 8+ makes disabled functions act as if not defined at all. To account for this and the increased likelihood of hosts to disable functions associated with process execution, check for function existence before running mandatory calls to exec, shell_exec, or escapeshellarg. Other calls like those in the default ExternalImageMagick derivative creator can be avoided through configuration.

(#1001)

Pull from Transifex

(also update Transifex client config)

Set version 3.1.1

Update bundled addons

Images being separate links is an accessibility downgrade so that's probably not going to happen.

This is intended/expected. Uploaded files are stored and accessed directly by the server, so there's no step of checking permissions or anything like that. The randomized filenames on their own are going to prevent simple guessing of the filename, as the possible space of filenames is massive.

The storage system is pretty flexible, so if you want a system that more formally blocks access, that's possible as well, though it would have to be a module. Options we've seen people use before are storing on S3 and using pre-signed URLs to allow access (so all files are inaccessible unless viewed from a page that generates the proper link to them), or modules that store files somewhere not publicly accessible and link instead to a PHP view that checks permissions and serves the file only if the user is authorized.

A fix for the buggy aspects of this is in, though not anything relating to changing to an icon.

Consistently place "indirect" links after values

Old behavior meant that Direct Links set to off had the link in a different location, but reliably after the value. With Direct Links on, the link wrapped literals as intended, but values that are already links got an "indirect" link, except much closer in the markup to the actual value, and in fact actually appearing before it.

The resolution here is: whenever making an "indirect" link, it's now in the same place: immediately after the value content itself. This means that the links generated with Direct Links off will move somewhat from where they were before.

There's some small accompanying styling to account for this change: instead of trying to force itself onto a separate line, the link is styled to just put a small margin between itself and the value.

(#52)

First commit. Basics in place

Add scripting for opt-in/out

Also, fix some miscellaneous issues, notable ones are that the check for opt-in being enabled was wrong, and the current analytics tag would never load on the config form.

Update author info and readme.

Basic styles for testing

Style tweaks

Fix content placement and add styles

Use standard snippet for non-opt-out config

Maintains compatibility with previous uses that might expect the snippet to appear in the source

Use standard snippet for non-opt-out config

Maintains compatibility with previous uses that might expect the snippet to appear in the source

There is issue when we bulk edit selected items with some modules: the process breaks.

The fix I was talking about was just merged, it was #2031. Instead of using clear between runs of the batch edit, it alters the internals used for "clear property values" and one other action.

The merge also included some other aspects and small improvements addressed by your PR in a second commit.

Change IDs to entity references to avoid issues with strict Criteria matching

Batch edit fixes and improvements

Adapted from #2002

Merge pull request #2031 from omeka/fix-batch-update

Fix elusive batch edit bug; other batch edit fixes and improvements

If anything we'd probably recommend PHP's built-in error_log if logging is required but you can't use the normal configured Logger component.

The content of the forum post about updating modules to 2.0.0 is a perfect example of what should go there.

The reorganization branch is an attempt to reorganize the docs in a more logical and intuitive fashion. This breaks internal links, but mkdocs can help us find and correct them. This also breaks the flow of some of the content, which we'll need to correct by proofing each page to fit into the new structure. We'll eventually have to change the order of the navigation, but that will have to wait until we finish organization.

But before I continue I need some eyes on the new organization. Does it make sense from a developer's perspective? A module developer? A theme developer?

- Omeka S Developer Documentation
- Contributing to Omeka S
- Debugging Omeka S
- For Omeka Classic Developers
- Registering an Addon
- Api
    - Introduction to the API
    - API Reference
    - REST API
- Configuration
    - Configuring Omeka S
    - Configuration Reference
    - Services and Factories
- Controllers
    - Introduction to Controllers
    - Controller Plugins
    - Routes and Navigation
    - ViewModel
- Events
    - Client Event Reference
    - Client Events
    - Server Event Reference
    - Server Events
- Miscellaneous
    - Access Control Lists (ACL)
    - Doctrine ORM
    - Forms
    - Internationalization
- Modules
    - Introduction to Modules
    - Data Model
    - Data Types
    - Media Ingesters and Renderers
    - Page Blocks
- Themes
    - Introduction to Themes
    - Sass and CSS
    - Style Guide
    - Theme Modifications
    - Theme Settings
- Views
    - Introduction to Views
    - Representations
    - View Helpers

There are some new pages that need content:

• "Introduction to the API": an introduction to the API and documentation for the programmatic API
• "API Reference": a reference for search criteria and request options
• "Introduction to Controllers": an introduction to controllers
• "Controller Plugins": a list of controller plugins and how to create one
• "Introduction to Views": an introduction to views

@zerocrates This is a slight departure from where we left off yesterday. I've added back in the "Modules" section because "Themes" is a separate section and the contents of the (now deleted) "Extending" section are specific to modules. I moved the "Introduction to..." pages to their respective "Modules" and "Themes" sections. Also, I'm particularly interested in getting your help editing the page content to fit into the new "flow" that the organization imposes. I don't have the time to do this alone.

hi there,

we are using omeka s in our library and a requirement for uploaded files (or URLs) appeared.

in order to show the right file version for the user, after he chooses the front end language, we need to catalog the file/URL language

curent field types dont allow this metadata to be inserted, so, would ther be any plugin to fulffill this requisit?

if not, what part of omeka source code need to be changed to allow this aditional descriptio for uploaded files

thanks!