Hi John,

No, it can be done without any widgets. There's a content_selector
option under settings that takes a CSS selector of the element in
template where content should be inserted. It default to "body", but can
be any valid selector.

On my own site I use a <div id="content">, so I have it setup like this:
https://github.com/dmbaturin/baturin.org/blob/master/soupault.conf#L17-L18

For your template you will need:

[settings]
  content_selector = "div.container"

On 4/29/20 4:22 AM, Aoirthoir An Broc wrote:
> will the following create any operating system issues, such as with
> windows:
>
> addClass.lua being called with widget="addClass"
>
> vs
>
> add-class.kua being called with widget="add-class"

I used hyphenated names in part to make them OS-independent indeed.

Also, I somewhat intentionally use hyphens instead of underscores in my
plugin file names to make them visually different from built-in widgets

I've made a point to break compatibility as rarely as possible, but I
fear soon it will be time for a 2.0 release.

Some design decisions didn't pass the test of time, and changing the
config syntax and/or behaviour can make some thing more logical and
flexible.
If we are going to do it, it's a good idea to make as many incompatible
changes at once as possible so that people will only need one big migration.
Small incompatible changes in every release is a horrible practice.

My plan how to make that migration simpler: write a script for
converting old configs to the new format. That can even be a client-side
web app where you can paste your config.

On 4/27/20 6:02 AM, Aoirthoir An Broc wrote:
> I think the best option would be an is_element test... so we can just
> continue through our loops. knowing which kind of data we are dealing
> with gives us options that just altering the add_class would not give
> us. As that would only work on add_class. Whereas in my case i was
> doing something else entirely and only used the add_class since it was
> the example code.
>
Ok, making HTML.add_class etc. work as a no-op for non-element nodes
turned out a bit harder than I thought. It will still fail for document
and text nodes—with a better error message than before.
However, it now works correctly with element nodes returned by
HTML.children and friends.

On 4/27/20 6:02 AM, Aoirthoir An Broc wrote:
> I think the best option would be an is_element test... so we can just
> continue through our loops. knowing which kind of data we are dealing
> with gives us options that just altering the add_class would not give
> us. As that would only work on add_class. Whereas in my case i was
> doing something else entirely and only used the add_class since it was
> the example code.
>
> on the bright side i did finish my plugin which is called
> block-maker.lua despite the appearance of restrictions with lua, so
> far everything I have ever tried to do, i found a way to accomplish
> with lua-ml and soupault. next step is going to be a
> create_gallery.lua plugin.. that will search a directory and create
> img elements for all the images there. That, is for tomorrow...

>children = HTML.children(body)
>
>local i = 1
>while children[i] do
>  HTML.add_class(children[i], "silly-class")
>  i = i + 1
>end
>Running this code exactly on a new soupault setup, with no plugins
running, no libraries activated gives me this error:
>[ERROR] Could not process page site/index.html: Expected an element,
but found a document

This is a somewhat confusing error message indeed. What it really means:
"expected an element but found a thing that may not be one".

Hi everyone,

I've made an 1.11.0 preview release for everyone to test.

You can fine prebuilt binaries at
https://files.baturin.org/software/soupault/1.11.0/ or build from master.

New features:

Plugin functions to simplify working with element attributes (suggested
by Aoirthoir):

HTML.delete_attribute(elem, attr_name) -- deletes attribute
HTML.list_attributes(elem) -- lists names of all attributes an element has

There isn't a way to do it right now, but I think it may be a good idea.
Something like soupault --run-lua myfile.lua

I'll look into it.



On 4/22/20 10:43 AM, Aoirthoir An Broc wrote:
> And if there is, can it work with soupault so we can test things kinda
> live?
>
> What I mean by that is rather than running soupault.. just run the
> lua-ml and its interpreter with your soupault libraries like HTML.
> Regex. etc...

Hi Aoirthoir,

There is a function for adding attributes actually|, it's used in
site-url and quick-links plugins.||
|
|
|
|HTML.set_attribute(my_link, "rel", "me")|
|
|
|It will create the attribute if doesn't exist yet.
|
|
|

Ok, now it's possible to pass lists of strings to plugins natively.

So plugin writers will be able to use either your comma-separated or
"real" lists since the next release.