special directives for beginning of a document (not category)

[rojenzaman]

I wanna to show an extra information for the document. But I don't wanna to write this info to #notes section. It'll be like as a directive.

example:

#title Title
#autho Author
#lastmodified 01.05.1968

These un-categorized directives are not enough for me: #isbn #rights #seriesname #seriesnumber

I wanna to create a special document info, how I can do it?

[melmothx]

Rojen Zaman @.***> writes:

I wanna to show an extra information for the document. But I don't wanna to write this info to #notes section. It'll be like as a directive.

example:

#title Title
#autho Author
#lastmodified 01.05.1968

These un-categorized directives are not enough for me: #isbn #rights #seriesname #seriesnumber

I wanna to create a special document info, how I can do it?

The header info are available at /text-url/json, e.g. https://amusewiki.org/library/amw-version-24/json

So you could do something like this in local.js:

var api = $('#page').data('text-json-header-api');
if (api) {
    // console.log("Api is " + api);
    $.ajax({
        url: api,
        dataType: 'json',
        success: function(response) {
            console.log(response); // and inject into the infobox
        }
    });
}

However, I think it would make it a reasonable feature to make the list customizable like for additional category types. So if you can wait a bit, that would be available in the near future.

-- Marco

[rojenzaman]

Thanks! It helped me.

I will use this:

var api = $('#page').data('text-json-header-api');
if (api) {
    $.ajax({
        url: api,
        dataType: 'json',
        success: function(response) {
            var lastmodified = response.lastmodified;
            if (lastmodified) {
                $('#preamble').append('<p><b>Last Edit:</b>&#160;' + lastmodified + '</p>')
            }
        }
    });
}

[melmothx]

Rojen Zaman @.***> writes:

Thanks! It helped me.

I will use this:

var api = $('#page').data('text-json-header-api'); if (api) { $.ajax({ url: api, dataType: 'json', success: function(response) { var lastmodified = response.lastmodified; if (lastmodified) { $('#preamble').append('

Last Edit: ' + lastmodified + '

') } } }); }

Beware that this way you open the door to XSS. So do this instead:

$('#preamble').append($('

').append($('').text('Last Edit: '), $('').text(lastmodified)));

-- Marco

[rojenzaman]

Oh, thank you! I fixed it.

[rojenzaman]

It would be nice if custom categories could also be specified in the first text creation section. Is this also possible in the near future?

[melmothx]

Rojen Zaman @.***> writes:

It would be nice if custom categories could also be specified in the first text creation section. Is this also possible in the near future?

Yes, sounds reasonable.

-- Marco

[melmothx]

@rojenzaman do you have the chance to test the branch custom-directives-402 and see if it looks good to you? Beware that there's a database upgrade.

Thanks

[rojenzaman]

OK. I've tried on clean installation. Everything seems nice, thank you! I'm not sure if it's important but there are two feature that can be added:

• Show special directives also in preview mode.
• Show special directives also in PDF, HTML or EPUB files depending on user choice.
  • Is it possible to add an identifier specifying what the relevant information directive is, just like in the information section of a book? It should look like this in the PDF:

            PUBLISHER
              A publisher

            EDITOR
              An editor

            SERIES
              Dangerous Series, II 

            Year
              2020

or

Publisher: A publisher
Editor: An editor
Series: Dangerous Series, II
Year: 2020

[melmothx]

Well, as for the preview mode: yes, sure.

For the formats, it's tricky, especially because of the localization. Historically these pieces of infos where stuffed in the #notes field.

Will need to think about that. But please keep in mind that summer is traditionally a slow season for development, so be patient!

[melmothx]

Preview is implemented in the custom-directives-402 branch.

[rojenzaman]

When I run the custom-directives-402 branch I get this error:

2022/08/20 21:53:54 ERROR - AmuseWikiFarm.Log.Contextual.App - lib/AmuseWikiFarm/Log/Contextual/App.pm:21 - DBIx::Class::Storage::DBI::_prepare_sth(): DBI Exception: DBD::SQLite::db prepare_cached failed: no such column: me.muse_value_html [for Statement "SELECT "me"."title_id", "me"."muse_header", "me"."muse_value", "me"."muse_value_html" FROM "muse_header" "me" WHERE ( "me"."title_id" = ? )"] at lib/AmuseWikiFarm/Schema/Result/Title.pm line 1741

What I missed?

Note: It happened when running the old database, it doesn't happen if I run it on a new install.

[melmothx]

Rojen Zaman @.***> writes:

When I run the custom-directives-402 branch I get this error:

2022/08/20 21:53:54 ERROR - AmuseWikiFarm.Log.Contextual.App - lib/AmuseWikiFarm/Log/Contextual/App.pm:21 - DBIx::Class::Storage::DBI::_prepare_sth(): DBI Exception: DBD::SQLite::db prepare_cached failed: no such column: me.muse_value_html [for Statement "SELECT "me"."title_id", "me"."muse_header", "me"."muse_value", "me"."muse_value_html" FROM "muse_header" "me" WHERE ( "me"."title_id" = ? )"] at lib/AmuseWikiFarm/Schema/Result/Title.pm line 1741

Try script/amusewiki-upgrade-db

-- Marco

[rojenzaman]

Try script/amusewiki-upgrade-db

Okay, it is solved.

Preview is implemented in the custom-directives-402 branch.

I've tried. Preview, Noindex, Index and Fill-in-the-first-page works well. That's nice!

But there are few things can be solved in the search section:

• Amusewiki can't search/match words in "custom directives".
• Directives like "Author" and "Topic" are displayed as table/checkbox with class name "facet-box-filter_author" and "facet-box-filter_topic" on the left side of the search section. Can you give this feature to indexed "custom directives" as well?

Thank you,

[melmothx]

OK. I've tried on clean installation. Everything seems nice, thank you! I'm not sure if it's important but there are two feature that can be added:

* Show special directives also in preview mode.

* Show special directives also in PDF, HTML or EPUB files depending on user choice.
  
  * Is it possible to add an identifier specifying what the relevant information directive is, just like in the information section of a book? It should look like this in the PDF:

            PUBLISHER
              A publisher

            EDITOR
              An editor

            SERIES
              Dangerous Series, II 

            Year
              2020

or

Publisher: A publisher
Editor: An editor
Series: Dangerous Series, II
Year: 2020

This is kind of done in the current branch. There is a new "Add to colophon" option in the category settings. At the moment the #colophon gets populated upon creation, and after that is disconnected from the other fields. It's just a piece of information which gets passed to the generated files. Please note that publisher/series/dates already exist as "normal" fields, so this example is not very good.

If you're wondering why they are not fully connected: there is at very least a big localization problem, and the fact that the categories are dynamical (you can change them any time) while generated files are static. So this is the solution for now. Eventually there could be a filter in the editing to refresh the colophon header, but this is already something.

Please note that this requires an updated Text::Amuse::Compile module (or libtext-amuse-compile-perl).

[melmothx]

Try script/amusewiki-upgrade-db

Okay, it is solved.

Preview is implemented in the custom-directives-402 branch.

I've tried. Preview, Noindex, Index and Fill-in-the-first-page works well. That's nice!

But there are few things can be solved in the search section:

* Amusewiki can't search/match words in "custom directives".

* Directives like "Author" and "Topic" are displayed as table/checkbox with class name "facet-box-filter_author" and "facet-box-filter_topic" on the left side of the search section. Can you give this feature to indexed "custom directives" as well?

Thank you,

The request is legit for sure but the implementation could be not so quick....

[melmothx]

@rojenzaman Please try out the search on this branch.

Pull the branch.

Upgrade the db script/amusewiki-upgrade-db

Go to /settings/categories and read the notes at the end of the page.

Add new texts and/or reindex the site. script/amusewiki-bootstrap-archive --xapian SITE_CODE

Try the search and let me know.

Thanks

[rojenzaman]

Before try, I'm having trouble in my amusewiki environment.

What is the recommended way to run amusewiki git source and custom-directives-402 branch?

I applied two setup here which based: https://amusewiki.org/library/install#toc1 and https://raw.githubusercontent.com/melmothx/amusewiki/master/Vagrantfile

You can check my two setup:

• https://github.com/rojenzaman/amusewiki-docker/blob/master/github.com/Dockerfile (Vagrantfile based)
• https://github.com/rojenzaman/amusewiki-docker/tree/master/texlive-full/Dockerfile (General installation based)

What I missed?

I'm trying both setup but the wiki waits at "Status: pending" mode when publishing new text. (I ran upgrade db and bootstrap-archive before try)

amusewiki-jobber log:

amusewiki-jobber.service: Can't locate AmuseWikiFarm/Schema.pm in @INC (you may need to install the AmuseWikiFarm::Schema module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /var/lib/amusewiki/script/amusewiki-jobber line 8.
amusewiki-jobber.service: BEGIN failed--compilation aborted at /var/lib/amusewiki/script/amusewiki-jobber line 8.

Also when I run ./script/amusewiki-upgrade-db script, it says:

Can't locate Moose.pm in @INC (you may need to install the Moose module) (@INC contains: lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at lib/AmuseWikiFarm/Schema.pm line 7.
BEGIN failed--compilation aborted at lib/AmuseWikiFarm/Schema.pm line 7.
Compilation failed in require at ./script/amusewiki-upgrade-db line 84.
BEGIN failed--compilation aborted at ./script/amusewiki-upgrade-db line 84.

But it is solved when "carton exec" passed: carton exec ./script/amusewiki-upgrade-db

DDLs dir is /var/lib/amusewiki/dbicdh
Checking if database is up-to-date: YES

[melmothx]

Rojen Zaman @.***> writes:

Before try, I'm having trouble in my amusewiki environment.

What is the recommended way to run amusewiki git source and custom-directives-402 branch?

I applied two setup here which based: https://amusewiki.org/library/install#toc1 and https://raw.githubusercontent.com/melmothx/amusewiki/master/Vagrantfile

You can check my two setup:

• https://github.com/rojenzaman/amusewiki-docker/blob/master/github.com/Dockerfile (Vagrantfile based)
• https://github.com/rojenzaman/amusewiki-docker/tree/master/texlive-full/Dockerfile (General installation based)

What I missed?

From what I can see, the jobber is out of order. Can you post the amusewiki-jobber.service unit file which is getting produced?

Otherwise a "carton exec script/jobber.pl foreground" or "carton exec script/jobber.pl start" should do to have it started.

I'm trying both setup but the wiki waits at "Status: pending" mode when publishing new text. (I ran upgrade db and bootstrap-archive before try)

amusewiki-jobber log:

amusewiki-jobber.service: Can't locate AmuseWikiFarm/Schema.pm in @INC (you may need to install the AmuseWikiFarm::Schema module) ***@***.*** contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /var/lib/amusewiki/script/amusewiki-jobber line 8.
amusewiki-jobber.service: BEGIN failed--compilation aborted at /var/lib/amusewiki/script/amusewiki-jobber line 8.

Also when I run ./script/amusewiki-upgrade-db script, it says:

Can't locate Moose.pm in @INC (you may need to install the Moose module) ***@***.*** contains: lib /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at lib/AmuseWikiFarm/Schema.pm line 7.
BEGIN failed--compilation aborted at lib/AmuseWikiFarm/Schema.pm line 7.
Compilation failed in require at ./script/amusewiki-upgrade-db line 84.
BEGIN failed--compilation aborted at ./script/amusewiki-upgrade-db line 84.

But it is solved when "carton exec" passed: carton exec ./script/amusewiki-upgrade-db

DDLs dir is /var/lib/amusewiki/dbicdh
Checking if database is up-to-date: YES

-- Marco

[rojenzaman]

Sorry for the late reply, please excuse the delay. (I didn't have time to try)

From what I can see, the jobber is out of order. Can you post the amusewiki-jobber.service unit file which is getting produced?

Thanks for the warning, it was a problem caused by incorrect copying of amusewiki-jobber.service (Dockerfile side). I fixed it: https://github.com/rojenzaman/amusewiki-docker/commit/3098ba434c1cb342463d200461517367a6b51600

---

Try the search and let me know.

Everything works like a charm! Thank you for search-side updates. One question: the "Search Engine Slot" means priority for the table?

---

This is kind of done in the current branch. There is a new "Add to colophon" option in the category settings. At the moment the #colophon gets populated upon creation, and after that is disconnected from the other fields. It's just a piece of information which gets passed to the generated files. Please note that publisher/series/dates already exist as "normal" fields, so this example is not very good.

So the colophon will be formed as a piece, I understood. Nice solution.

If you're wondering why they are not fully connected: there is at very least a big localization problem, and the fact that the categories are dynamical (you can change them any time) while generated files are static. So this is the solution for now. Eventually there could be a filter in the editing to refresh the colophon header, but this is already something.

So why is colophon a problem for localization? I didn't fully understand this. And what is "filter" for colophon header?

Please note that this requires an updated Text::Amuse::Compile module (or libtext-amuse-compile-perl).

This module is exist, #colophon gets populated but still I don't see the colophon piece in generated files. Is there anything i missed? Or is it still under development?

thanks

[melmothx]

Rojen Zaman @.***> writes:

Try the search and let me know.

Everything works like a charm! Thank you for search-side updates. One question: the "Search Engine Slot" means priority for the table?

That's the awkward bit. It's just a slot identifier for the search engine, so does not have any meaning for the user. I'll need to polish that and hide that confusing piece of info from the user view.

This is kind of done in the current branch. There is a new "Add to colophon" option in the category settings. At the moment the #colophon gets populated upon creation, and after that is disconnected from the other fields. It's just a piece of information which gets passed to the generated files. Please note that publisher/series/dates already exist as "normal" fields, so this example is not very good.

So the colophon will be formed as a piece, I understood. Nice solution.

Cool.

If you're wondering why they are not fully connected: there is at very least a big localization problem, and the fact that the categories are dynamical (you can change them any time) while generated files are static. So this is the solution for now. Eventually there could be a filter in the editing to refresh the colophon header, but this is already something.

So why is colophon a problem for localization? I didn't fully understand this. And what is "filter" for colophon header?

A text hosted on a site may be in another language. So together with the custom categories, we would have to send the labels as well, which need translation. I believe some languages (e.g. CJK) don't even use the ":" as separator. That would complicate too much the matter for a too little gain.

The postulate here is that from the muse file, one should be able to generate the final formal without the need of the amusewiki site, and I'd like to keep it that way.

Hence the solution was to use a static #colophon in the muse.

At some point, past release, we could have a new "Refresh #colophon" in the edit screen which would replace it anew from the other fields. Again, this could be an overkill, considering there's a clear preview of what's going to be shown on the formats.

I hope this answers your question.

Please note that this requires an updated Text::Amuse::Compile module (or libtext-amuse-compile-perl).

This module is exist, #colophon gets populated but still I don't see the colophon piece in generated files. Is there anything i missed? Or is it still under development?

No, you're missing a piece. https://metacpan.org/pod/Text::Amuse::Compile

What's the output of:

perl -MText::Amuse::Compile -e 'print "$Text::Amuse::Compile::VERSION\n"'

carton exec perl -MText::Amuse::Compile -e 'print "$Text::Amuse::Compile::VERSION\n"'

It should say 1.87.

From the installation directory:

cpanm -L local --installdeps

And restart the services (web and jobber).

-- Marco

[melmothx]

@rojenzaman further comments or this can be released?

[rojenzaman]

No, you're missing a piece. https://metacpan.org/pod/Text::Amuse::Compile

OK. I added and have tried, Successful.

@rojenzaman further comments or this can be released?

Yes, it can be released. But there are a few things,

That's all I can see for now, can be deferred to the next version if my suggestions below aren't that important:

---

WARNINGS intercepted:
./repo/testing/d/da/dangerous-author-on-dangerous.muse: Overwriting directive 'publisher' Dangerous Publisher
 with #publisher Dangerous Publisher

It says the directive already exists (as a system side) and overwriting, To avoid this warning, can we warn the user when he adds a exist directive? It would also be nice if we could edit all existing directives (such as ISBN, Series and Publisher directives / system side).

Also, if the directive already exists and I add it anyway, the directive is printed twice in the colophon: (look Dangerous Publisher)

---

And another thing, It would be nice if we could place the note/warning we want on the special directive boxes that appear when the first page is created. Because sometimes users may not understand what directive is.

[melmothx]

Rojen Zaman @.***> writes:

WARNINGS intercepted: ./repo/testing/d/da/dangerous-author-on-dangerous.muse: Overwriting directive 'publisher' Dangerous Publisher with #publisher Dangerous Publisher

It says the directive already exists (as a system side) and overwriting, To avoid this warning, can we warn the user when he adds a exist directive? It would also be nice if we could edit all existing directives (such as ISBN, Series and Publisher directives / system side).

Also, if the directive already exists and I add it anyway, the directive is printed twice in the colophon: (look Dangerous Publisher)
![Screenshot from 2022-09-11 17-00-22](https://user-images.githubusercontent.com/46978479/189532435-3f3f1c9a-4edd-40a5-a409-32886c8acbb9.png)

The built-in directives are in the manual:

https://amusewiki.org/library/manual#toc12

so I guess you created a custom directive overwriting the built-in ones? And why?

And another thing, It would be nice if we could place the note/warning we want on the special directive boxes that appear when the first page is created. Because sometimes users may not understand what directive is.

Not sure what you mean here.

-- Marco

[rojenzaman]

The built-in directives are in the manual:

https://amusewiki.org/library/manual#toc12

I know them, but configurable system directives are #author and #subject only.

What should I do if I want to configure #isbn, #rights , #seriesname directives? It would be functional to be able to set them on the configuration page, as with the #author and #subject directives. Also, some of these directives are not shown in preview mode and do not have colons identifying themselves in the colophon section.

---

Not sure what you mean here.

Sorry, there are typo.

This is the first text creation page (/action/text/new), the Editors box is a custom directive, and the text "Comma or semicolon separated list" at the bottom of the box provides information about the directive. So can we edit this info/warning? Or can we add any information to the Last Modified directive that doesn't contain any information?

[melmothx]

The built-in directives are in the manual: https://amusewiki.org/library/manual#toc12

I know them, but configurable system directives are #author and #subject only.

What should I do if I want to configure #isbn, #rights , #seriesname directives? It would be functional to be able to set them on the configuration page, as with the #author and #subject directives. Also, some of these directives are not shown in preview mode and do not have colons identifying themselves in the colophon section.

Well, there is not much to configure there. Either you use them or not. They don't appear in the colophon, but they do appear in the format. The EPUB, for example, has even dedicated slots for ISBN and publisher, so they go there.

I'm going to improve that admin page to make it clear what's happening.

This is the first text creation page (/action/text/new), the Editors box is a custom directive, and the text "Comma or semicolon separated list" at the bottom of the box provides information about the directive. So can we edit this info/warning? Or can we add any information to the Last Modified directive that doesn't contain any information?

Ok, this sounds sensible.

[melmothx]

@rojenzaman Please pull the branch, update the db and let me know if there are still rough edges, thanks.

[rojenzaman]

@rojenzaman Please pull the branch, update the db and let me know if there are still rough edges, thanks.

Thanks so much. The new category configuration is so functional!

But maybe has a little rough edge:

These directives are on the text creation page by default. Would so many directives be confusing for new public users? Or is it not important? idk.

---

Maybe it's the subject of future releases, but it would be nice to be able to set whether certain functions are enabled on the text creation page. (functions are: main text, teaser, notes etc.)

I know I said a lot, sorry. But these are possible scenarios. I use Amusewiki for different purposes in a few projects. The first one I just use for text archives as normally, while the other project is an archive containing scanned book files. In the wiki where only scanned files are hosted, some functions on the first page -for example: Teaser, Main text- may be redundant. I think that the text creation page should be partially customizable so that people can use it for different purposes. So can I open a new issue about this?

[melmothx]

@rojenzaman see if the last commits address that.

I added the ids to the create forms. I think that the customization you're asking for is better done via a simple CSS rule in the local.css without further cluttering the settings.

Comments?

[rojenzaman]

Thank you so much, this is what I was looking for!

I will use:

#create-block-muse-body, #create-block-teaser, #create-block-notes {
    display: none;
}

@rojenzaman see if the last commits address that.

Comments?

Yes, they are well. I've no comment anymore.

[rojenzaman]

I added the ids to the create forms.

Can you give custom div ids to these functions as well? Is it possible?

sorry for bothering the main issue

1. 
2. 
3.