Bug 36152 - Allow to add jQuery directly in custom pages
Summary: Allow to add jQuery directly in custom pages
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Tools (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 15326
Blocks:
  Show dependency treegraph
 
Reported: 2024-02-22 16:17 UTC by Andrew Fuerste-Henry
Modified: 2024-04-11 13:25 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 36152: Tidy (4.45 KB, patch)
2024-04-11 13:25 UTC, Nick Clemens
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2024-02-22 16:17:25 UTC
Pages created via the additional contents tool should have the ability to contain their own jQuery. Currently, jQuery to be used on a custom page must be put into one of the UserJS system preferences. Those system preferences tend to include a lot of code saved as one long block. It'd be great to be able to keep custom page code separate.

For contrast, one can just put CSS straight into a page and have it work correctly.
Comment 1 David Cook 2024-02-22 22:10:09 UTC
Inline Javascript and CSS will be a problem for the eventual adoption of Content-Security-Policy. 

If it were to be done, I think it would need to be stored in separate database columns, so that a CSP nonce could be added to it in the templates.
Comment 2 Lucas Gass 2024-02-22 22:19:03 UTC
(In reply to David Cook from comment #1)
> Inline Javascript and CSS will be a problem for the eventual adoption of
> Content-Security-Policy. 
> 
> If it were to be done, I think it would need to be stored in separate
> database columns, so that a CSP nonce could be added to it in the templates.

Then this seems like it would be more trouble then it is worth when we already have a good place for the JS, the USerJS's.

I do sympathize with Andrew's problem. If you have a custom page that displays on the OPAC and staff interface you'll need to duplicate JS and put in both OPACJS and IntranetUserJS.
Comment 3 David Cook 2024-02-22 22:40:02 UTC
(In reply to Lucas Gass from comment #2)
> Then this seems like it would be more trouble then it is worth when we
> already have a good place for the JS, the USerJS's.
> 
> I do sympathize with Andrew's problem. If you have a custom page that
> displays on the OPAC and staff interface you'll need to duplicate JS and put
> in both OPACJS and IntranetUserJS.

That would be an annoying problem.

Overall, I'm unhappy with how we're doing HTML/CSS/JS content management in Koha. It is tough having Koha be all things to all people, and trying to maintain the balance of security and convenience...
Comment 4 Nick Clemens 2024-04-11 13:25:03 UTC
Created attachment 164691 [details] [review]
Bug 36152: Tidy