Javascript Panel

TheEric · 2025-01-05 00:01:28

Why don’t we have a javascript panel similar to the CSS panel? That shouldn’t be too hard to implement. I would be willing to implement that if someone would give me keys to do so. Or, perhaps a toggle feature in the CSS panel that would define it as a CSS or Javascript page.

Last edited by TheEric (2025-01-05 00:03:02)

Bloke · 2025-01-05 00:59:44

There was a plugin that added that. Latest incarnation (unmanaged) is spf_js.

There’s also a way to do it by misusing the CSS tag. And in 4.9.0 there’s also the new empty format="" attribute value that will output the stylesheet raw, which you can use with the UI library to inject inline CSS/JS that is cognisant of CSP rules.

TheEric · 2025-01-05 01:05:16

Bloke wrote #338657:

There’s also a way to do it by misusing the CSS tag.

That works, but it causes me some OCD issues. Perhaps a radio button that alternates between CSS or javascript and a txp:head-link?

Ideally, this would make it easier to share/sell/swap themes for CSS if it could all be done at the browser level.

Last edited by TheEric (2025-01-05 01:09:02)

TheEric · 2025-01-05 06:06:54

Created an interim solution that makes it better for me. Just save the files in the theme javascript directory, include this plugin tag and it outputs the links to the javascript files. I’m currently converting my Wordpress theme to Textpattern and I prefer things to be done a certain way.

My Solution

Last edited by TheEric (2025-01-05 06:07:17)

phiw13 · 2025-01-05 07:46:44

That JS panel already exist, at little hidden though:

Preferences panel:
Admin -> Advanced options: On
Advanced options -> Custom form template types

[js]
mediatype="application/javascript"
title="Javascript"

On the forms panel create a form name it my-script.js with form type “Javascript”. Write your script in the textarea

If you save it to disc anyway:

<script  defer src="/themes/theme-name/forms/js/my-script.js"></script>

There was/is some other way based on that form type but I can’t find it right now. Maybe Oleg nows?

Last edited by phiw13 (2025-01-05 07:49:32)

TheEric · 2025-01-05 08:06:21

phiw13 wrote #338667:

That JS panel already exist, at little hidden though:

I played around with it and it was a bit convoluted to get working. I’m working on a couple projects, and one of them is to make themes drop-dead easy for people accustomed to wordpress. I created the above just to brute force it and allow a neophyte to just install a plugin for theme javascript to suddenly work. The TL;DR – I’m trying to dumb down the process.

Last edited by TheEric (2025-01-05 08:08:19)

jakob · 2025-01-05 09:33:11

TheEric wrote #338668:

I’m working on a couple projects, and one of them is to make themes drop-dead easy for people accustomed to wordpress. I created the above just to brute force it and allow a neophyte to just install a plugin for theme javascript to suddenly work. The TL;DR – I’m trying to dumb down the process.

Yes, theme development works quite well, but it’s not plug-and-play for all aspects. One of those is installing plugins (and predefined site and plugin settings), so if your theme uses more than the core tags, installing a theme means you need to provide plugin installers and instructions on how to install them before the theme will work. It’s not a big deal to provide instructions, but describing which site and plugin settings to set is more long-winded (e.g. custom_fields, smd_thumbnail profiles…).

BTW: you can use if_plugin in your theme to provide a core-tag fallback when a plugin isn’t installed or activated. An example of this is to create an image+thumbnail fallback for the srcset attribute when smd_thumbnail is not available.

Bloke / Stef has worked on an ununofficial “bootstrapping” plugin to automate bundling some of that installation step, but it too requires installing itself.

Some alternatives that don’t require a plugin are:

Put your js libraries in forms and output them from there.
Provide your own js file … either as a ready-compiled / concatenated and minified single js file or as a main.js that loads your further libraries from within that (on demand if needed).

etc · 2025-01-05 13:38:12

TheEric wrote #338656:

Why don’t we have a javascript panel similar to the CSS panel?

I’d rather ask why do we still have a CSS panel? It’s just a form with eventual text/css mediatype. Is not making all custom types theme-exportable looking more natural?

phiw13 wrote #338667:

There was/is some other way based on that form type but I can’t find it right now. Maybe Oleg nows?

Possibly txp:output_form form="myscript.js" format="flat.url" />?

phiw13 · 2025-01-06 09:24:33

etc wrote #338672:

I’d rather ask why do we still have a CSS panel? It’s just a form with eventual text/css mediatype. Is not making all custom types theme-exportable looking more natural?

Amen to that. Would be nice to remove the Style panel…

Possibly txp:output_form form="myscript.js" format="flat.url" />?

Hmm… maybe ?

Bloke · 2025-01-06 10:23:02

phiw13 wrote #338679:

Would be nice to remove the Style panel…

Why is everyone hating on the Styles panel? As a not-too-confident CSSer, I love it. I often don’t have filesystem access to client sites, so it allows me to load up someone’s site in the browser, pop open the inspector, hack away at the CSS on the fly to make it do what they want, CTRL-A, CTRL-C, switch tab, CTRL-V, CTRL-S. Done.

If Styles and other assets were solely disk-bound, I’d be stuck. I actually relish more admin-side control (e.g. being able to import/upload themes from a .zip file) rather than having to demand SFTP access in order to install a theme, or be forced to create each asset by hand in a new theme created from the back-end.

etc · 2025-01-06 10:50:01

I don’t think the purpose is to remove the Styles panel, but rather handle it as any other mediatyped form. It would still be editable via txp interface and stored in db/fs. The interface might be reworked to simplify assets creation, but I see no reason to handle css separately from other types (js etc).

Bloke · 2025-01-06 10:56:36

etc wrote #338683:

I don’t think the purpose is to remove the Styles panel, but rather handle it as any other mediatyped form… I see no reason to handle css separately from other types (js etc).

No issues with this.

Textpattern CMS

Textpattern CMS support forum

#1 2025-01-05 00:01:28