Search the Community

Tried to changing the "Content Type" setting on the fields "Text formatters" tab to "Markup/HTML" and everything went crazy, so i quickly changed it back to "Unknown/Text". And all is well. In the front end all the Markdown bunched up in a pile with no line endings or returns when i clicked saved. And in the front end when i went to check on what showed up there, the Markup was unchanged except for some HTML tags had been added. Very strange. But i think for the time being i am going to let Markdown and Front-End editing stay away from each other until we figure out this mystery.

It might be best to disable Frontend Editing on fields that are going to be handled with Markdown (or possibly any fields that have Textformatters that swap in/out content dynamically). I'm thinking that because Frontend Edit is not aware of the additional processing that a textformatter will do, it is only presenting and saving the data as it sees it based on the Fieldtype, and (in the case of textarea) Content type therein. @bernhard You have front-end editing in your Rockfrontend; does it use the core's frontend page editor, or did you use your own? I'm curious if you've run into any similar issues.

If you're intermingling this field with actual HTML on purpose, it would make sense that there are problems. As I mentioned earlier, Markdown should accept HTML, but due to how this all works together, I can see scenarios where there would be issues. I just manually typed in <strong>Test this</strong> into the Frontend Editable textarea for the body field, and saved. The text was bolded. OK. I went back to edit it and the text was still bolded, but there were no HTML tags for me to modify to un-bolden it. CTRL+B didn't work because that's a browser control to open my bookmarks. It would have to be modified in the backend, or I'd have to combine Markdown with a richtext editor (which I have not tested, and there are other modules for that, too). Therefore, any broken HTML would just be broken HTML. NOTE: I did not adjust any Input settings, so "Strip Tags" is not enabled. I don't believe HTMLPurifier is processing this input as it's currently configured, which is its own problem... See below (the "Edit this page" should not be bolded, it's hardcoded text, part of the page template, not part of the body field.)

I was curious, so setup a test environment. Blank profile. I created a `body` Textarea field and applied it to the `basic-page` template. I enabled the core's TextformatterMarkdownExtra module, and configured it as such: - Parsedown Extra - Safe mode: No (realistically this should be "yes", but setting it to yes caused HTML to be HTML encoded) For the body (Type: Textarea) field: - Text formatters: Markdown/Parsedown Extra (ONLY this; HTML Entity Encoder caused issues when combined with the Markdown formatter) - Inputfield type: Textarea - Content type: Markup/HTML - Markup/HTML (Content type) [options]: None selected, though this is only due to it being a test; these should be fine to adjust Choosing "Unknown/Text" for the Content Type while using Markdown seems to cause some issues when combined with Frontend Edit since the rendered text after being formatted is HTML, not text. I also had a strange scenario with Frontend Edit at one point where the text generated by Frontend Edit into the `body` field using contenteditable was "<div>Body text</div><div>More text</div>", but interestingly, ProcessWire only rendered "<div>Body text</dv>" into the HTML, though when I activated Frontend Edit to modify the field's value, the full text was displayed. I believe that may have to do with choosing "Unknown/Text" for the content type while using Frontend Edit due to how contenteditable works. That being said, once I configured things as it is configured above, I was unable to reproduce any extra newlines being produced in the final markup, no matter how many times I edited and saved.

I am still not sure it this is a weird glitch or bug or maybe even expected behaviour. Until this very thread here I never really noticed any issues and didn't find any messed up articles so far, yet to be frank I rarely use that feature on a daily basis. I mostly enabled frontend-editing for some fields to clean up formatting, adding a sentence, fixing a typo, and similar tasks while browsing through the site. On the other hand I'm in the process of migrating some client projects over to Markdown textareas as those clients feel more comfortable using plain-text than HTML editors - and they just can't really f**k up things that bad in there. So it could become a concern when I enable frontend-editing there. It's not planned, but could be the case. @ryan , maybe you could give us more insights here? Is this expected behaviour or a weird glitch/bug?

That appears to be a result of contenteditable being applied and used on an element; it creates newlines and <br> tags on each ENTER/RETURN press (or similar end-result with pasted content to render it similarly). FrontendEdit does take into consideration the difference between standard Textarea and Richtext fields...unfortunately, Markdown technically does validly accept HTML in its markup, so although it doesn't provide a WYSIWYG interface, I'm assuming it doesn't parse out and remove embedded HTML by design. I guess the problem here is that ... Actually, since the Markdown/Parsedown here is applied from a Textformatter and not a custom fieldtype, and the fieldtype is still a standard Textarea, I'm back to being confused. ? It might require a deeper dive into the code of that module than a cursory glance like I gave just now.

Changing the order results in chaos as the markdown will be shownas unrendered HTML - which is actually correct behaviour here and makes sense. I just removed HTML Entity Encoder, disabled Safe Mode, and played more. The result stays the same: at some point the textarea field or it's rendering becomes unstable and lots of <p> tags were added. Then I looked into the dev tools and saw that being in frontend-edit mode it outputs actually HTML and not real markdown - like it does in the admin. With CKEditor or TinyMCE fields it's fine and expected as those are WYSIWYG editor but here in Markdown it's not. Tested further and found that it is the same with real plain text textarea fields. It makes the rendered HTML editable and doesn't render the textarea as InputField like in the admin. Frontend: Backend: So... not perfect for plain text/markdown fields. I might be totally wrong here but it's either: Output Formatting or the fact frontend-editing doesn't load the real InputFields It's curious that I only ran into this problem because I tried to run into it. I use this for quite some time now, 3 months at least, and never noticed an issue. Maybe I should look into each and every page now. ??

My only issues with mixing HTML and Markdown came up when trying to edit with the Front-End textarea, never in the Admin side. But i only use HTML mixed with Markdown when i forget the syntax. (getting old i guess). Like you i have problems with the Front-end textarea adding linebreaks only if i change something, because if i leave it untouched the Front-end refuse to save because there is no need. I have safemode turned of for some reason, can´t remember why right now. I can manage without the Front-end stuff but it would be good to know what is causing this problem. A question for you @wbmnfktr, could the order of your textformatters change your outcome to your problems ?

Two things are different in our setups. HTML Entity Encoder is enabled Safe Mode in Markdown/Parsedown is enabled For both I can't tell why they are enabled. I guess it's the default setting. At least I can't remember changing that. Another thing is that I usually don't mix Markdown and HTML in my textareas. Just plain Markdown. This is important because the moment I try to fix the HTML in the code annotation that textarea starts become unstable. And only then. First it adds new lines to the code area, next it adds paragraphs everywhere - even in other list elements. Adding only Markdown without any HTML doesn't change the behaviour. And that's what I tried first. Something different but similar I noticed was that I can't set line-breaks/new lines from the frontend. Usually in the backend I add two spaces at the end of the line, hit enter and start a new line. That doesn't work in the frontend at all. It actually messes thinks up similar to your issue. Just an idea that came up: Could it be an issue with output formatting and that it is not working as expected in the frontend?

I thought i supply some screenshots of my settings on the "main_markdown_content" field that is using the "Markdown/Parsedown" textformatter. Included a screenshot on the Front-End Page Editor settings as well for comparing. First the fields Basics tab Then the Details tab Then the Markdown/Parsedown modules settings: And finaly the Front-End Page Editor settings: I find that if i involve the "HTML Entity Encoder" textformater trouble ensues. So i only use hte Markdown/Parsedown formatter alone. That seems to work the best and lets me mix Markdown and HTML in the same textarea. I don´t use any of the advanced editors for the Textarea. Thats just how i roll. Hope this will give some more information to solve this mystery.

Ok, so after more playing around with the frontend-editing I got it to throw up - kind of. I threw in a code comment: ```twig <li> asdads </li> ``` And I got a totally messed up textarea/markdown back. Everything in new lines/paragraphs. Totally unusable. Went back to the admin, pasted in the old content. Everything was fine again. Tried again and nothing happened. Besides the code block looked a bit off, went into edit-mode and saw this: ```twig asdads ``` the <li>s were missing, cleaned that up, and got it to throw up again. It takes some tries here but once in a while something goes wrong. Tried different HTML tags but those <li>s or code blocks seem to cause issues when added from the frontend. Tried the same in the admin and everything was fine.

I'm using a similar setup with markdown and frontend-edit. Copied your snippet, added demo content, wrote text... no new lines added here. I put some screenshots here to compare. If you want, drop me one of your .md files and I will test with that.

I wanted to add some more information in case it plays a difference in figuring this out. On the page/template that the Markdown field is used i also make use of the following JavaScript librarys: - Fontawsome - Google fonts

I did even some more testing after @BrendonKoz post gave me some ideas. And i am pretty confident that the culprit is the "Markdown/Parsedown" textformatter. Because i disabled the "Markdown/Parsedown" textformatter and had no formatter at all on the field. Then when i edit it on the frontend and save, no extra lines or endings is added. As soon i enabled the "Markdown/Parsedown" textformater the problem shows up again.

Hello @BrendonKoz i thank you for your reply. You had the same thought i had about the textformatters so i took an extra look, and it´s only the "Markdown/Parsedown" formatter that is enabled. Also i did some more experimenting with the frontend, and it seems something happens when i double click the part of the site i want to edit, in this case the Markdown and everytime the field is saved their is newlines added, even if i had not made any changes. This is so strange. But if i use your method to delete the \n and use shift-Enter for a \r\n and save the field no extra spaces are added. I can´t be expected to go through every line and delete the \n and replace with \r\n every time i want to edit it. Could it be some UTF-8 issue that i have failed to catch ? Update 2024-08-16 This time when i went through all the lines and used BrendonKoz method the newlines was visible in the admin side textarea form, but not renderd on the frontend side. Thanks in advance.

I haven't tried frontend editing yet, but since no one's yet replied, I have two possible thoughts: You said there's a Markdown/Parsedown TextFormatter. Is there, by chance, a Newlines to XHTML Linebreaks TextFormatter enabled too? That might do it. If you're manually typing this content in, just in case the interface is adding Windows' style line endings, try holding SHIFT when pressing ENTER/RETURN at the end of a line in order to remove the possibility of extra line-endings being included (ex: \r\n instead of just \n). If you're copying and pasting, similarly make sure the source text doesn't use those line-endings. ?

Hello There fellow PW users. I am writing to get your advice on how to figure this problem out. I have never used the Front-end Editing functions of PW before so i tought i try it out. Using Ryans Front-end Page Editor module version 0.0.6. And i am using option A (automatic editing) method described in the documentation together with: <?PHP /* In my setup 'main_markdown_content' is a textarea field with a 'Markdown/Parsedown' textformatter. and inputfieldtype 'Textarea' selected on details tab for the field. Also content type is 'Unknown/Text' is selected. I get a warning when editing this field: -"This field currently allows Markup/HTML in formatted output. If you do not intend to allow Markup/HTML, please select the “HTML Entity Encoder” for “Text formatters”. But the field is storing Markdown and not HTML, as i understand it, the markdown gets rendered into HTML by the textformatter at runtime when outputting the field in my template ? */ /* using Option A (automatic editing) */ echo($page->main_markdown_content); ?> So far so good, it works, the trouble comes when the field is saved when clicking "Save" button on the frontend. For some reason new line endings are added to every line in my Markdown. Lets say this is the markdown (sorry for the swedish): # Sommar 2024 Sommar och sol, värme och regn om vart annat, för att inte tala om pollen. /EyeDentify. ## Uppdateringar - **2024-07-13:** Har uppdaterat Bulma.JS och önskar glad sommar. - **2024-04-10:** Önskar en trevlig vår. - **2023-12-24:** Önskar God Jul och Gott nytt år. - **2023-01-11:** Det är ett nytt år och jag fortsätter jobba på siten. Har planer för att utveckla den. Mer om det senare. And that after saving the frontend field ends up looking like this when i check it in the Admin editor: # Sommar 2024 Sommar och sol, värme och regn om vart annat, för att inte tala om pollen. /EyeDentify ## Uppdateringar - **2024-07-13:** Har uppdaterat Bulma.JS och önskar glad sommar. - **2024-04-10:** Önskar en trevlig vår. - **2023-12-24:** Önskar God Jul och Gott nytt år. - **2023-01-11:** Det är ett nytt år och jag fortsätter jobba på siten. Har planer för att utveckla den. Mer om det senare. (data above is copied exactly from the field after a save and it adds extra spaces.) Which is not what i want, the textformatter outputs the HTML as expected but it has more line endings and spaces between rows. I have to edit out the extra spaces in the Admin backend editor to make it go back to my original Markdown. I can´t figure out what is happening so i turned the editing of for now. Would realy like to be able to use it. You PW gurus have any ideas to what is going on ? If you want any other info to help me, just say so and i will try to supply it. Thanks again! /EyeDentify

Seemingly quite similar to @ukyo's solution via Mystique. I have a local SQLite database that is a mirror of an external vendor's data for our event calendar (I use an API to sync their external with our local so that I can more easily integrate items into our website rather than constantly referring to their API). By parsing available data in the SQLite database (and making it available via a local REST URL) to determine options in the field, I can then use the chosen values as a filter to then query/display matching records in the SQLite database. This particular field was explicitly allowed as a RepeaterMatrix Fieldtype, and then added, in my case. My Mystique template: /site/templates/configs/Mystique.calendar.php <?php namespace ProcessWire; /** * Resource: Dynamic Calendar settings field */ return function ($page = null, $field = null, $value = null) { // Get the data to feed possible selection values $audiences = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/audiences.php?activeMerge=1'), true); $categories = json_decode(@file_get_contents(input()->httpHostUrl() . '/calendar/categories.php?activeMerge=1'), true); $fields = [ 'event_type' => [ 'label' => __('Event Type'), 'type' => 'InputfieldCheckboxes', 'options' => [ 'events' => 'Library Events', 'meetings' => 'Public Meetings' ], 'required' => true, 'columnWidth' => 33 ], 'limit_days' => [ 'label' => __('Upcoming Days to Check'), 'type' => Mystique::INTEGER, 'min' => 1, 'max' => 60, 'defaultValue' => 1, 'initValue' => 1, 'inputType' => 'number', 'required' => true, 'columnWidth' => 34 ], 'limit_events' => [ 'label' => __('Maximum Events to Display'), 'type' => Mystique::INTEGER, 'min' => 0, 'defaultValue' => 0, 'initValue' => 0, 'inputType' => 'number', 'required' => true, 'columnWidth' => 33, 'notes' => __('Per event type. Leave at 0 for no limit.') ], 'not_found_msg' => [ 'label' => __('Message if No Matches Found'), 'description' => __('This will be displayed if no events match the given criteria. Leave blank for no message.'), 'type' => Mystique::TEXT, 'columnWidth' => 100, 'notes' => __('HTML cannot be used here. Markdown is allowed.') ], 'private' => [ 'label' => __('Include Private (Calendar) Library Events'), 'type' => Mystique::CHECKBOX, 'value' => false, 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33, 'notes' => __('This is not recommended.') ], 'output_style' => [ 'label' => __('Output Styling'), 'description' => __('Choose the presentation style for any events that will be displayed.'), 'type' => 'InputfieldRadios', 'options' => [ 'list' => 'A Simple Bulleted List', 'grid' => 'A Grid-Like Display' ], 'showIf' => [ 'event_type' => '=events' ], 'columnWidth' => 33 ], 'show_images' => [ 'label' => __('Display associated event images?'), 'type' => Mystique::CHECKBOX, 'showIf' => [ 'output_style' => '=grid' ], 'columnWidth' => 34, 'notes' => __('Images are always taken directly from the calendar and cannot be properly optimized.') ], 'fieldset' => [ 'label' => __('Filters for Library Events'), 'type' => Mystique::FIELDSET, 'collapsed' => true, 'showIf' => [ 'event_type' => '=events' ], 'children' => [ 'audiences' => [ 'label' => __('Audiences'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $audiences, 'defaultValue' => '', 'columnWidth' => 20, 'notes' => __('Leave blank to show all.') ], 'categories' => [ 'label' => __('Categories'), 'description' => __('Only show:'), 'type' => 'InputfieldCheckboxes', 'options' => $categories, 'defaultValue' => '', 'optionColumns' => 3, 'columnWidth' => 80, 'notes' => __('Leave blank to show all.') ] ] ] ]; return [ 'name' => 'calendar_events', 'title' => 'Calendar of Events', 'fields' => $fields ]; }; Which then renders: I could've looped the field generation instead of the values generation, similarly to what Ryan did above, but that wasn't my use case here. Regardless of solution, it's a very handy way to generate fields, options, and values.

What @da² mentioned above is kind of what I was thinking too, so I don't think he meant harm by it. You pointed out your comfort with HTML and confusion on multiline PHP, so the points are there for us to create an assumption. Apologies if it's wrong! ProcessWire is a content management framework, so it does require some level of understanding of development on both a higher and lower level, or at least the ability to read through code - it took me until just this year to realize that a lot of the documentation are actually in comments in the code, or in Markdown files that developers provide with their modules. I felt (partially) silly for only ever trying to look at written documentation. Like you, I love examples too; much of which exists in the forums, honestly. Anyhow, that being said, I may not be the best person to provide a response, but I do want to try to help you out here. The problem with these questions though are that each and every one can begin the response of the answer with: "It depends." Typically each template is not an entire HTML document, as you'll have one (or two) main layout file(s) that then get merged with your template in one way or another. This would depend on your output strategy as linked above. Since you're just starting out, it might make the most sense to give Direct output a try so that you can start to understand how ProcessWire works. I'm assuming though, since you read through the documentation, you'd also read the last part on the direct output page that mentions its drawbacks (I assume this based on question #3 above). Part of the solution to this, with direct output, is understanding the ProcessWire API. You can retrieve any "page" or page content within the system from pretty much anywhere by using the API. It's extremely powerful. Depending on your needs, you'd likely need to do some manipulation on the returned data prior to rendering it as HTML, but the point is that it's accessible to retrieve. This will depend on your own imagination on how you want to build your site profile out. If you've got some time, you might want to setup some test ProcessWire sites, and install some pre-made site profiles that you can examine and look through to understand how each developer decided how to set things up. There's no real right way to do things, and a lot of it will depend on the project's needs and requirements. Sure there are better ways to do things, but a lot of us don't figure that out until after we've made the not-better solution first. ? As a partial example to this question though - let's say you have a very simple blog. You have two system templates (thus far) - one that lists all blog posts, and one that views a specific blog entry (post). You have four template files: (1)header.php, (2)footer.php, (3)blog.php, (4)post.php. Posts are children of Blog, and Blog is the parent of Posts. (You could consider "Blog" as the homepage I guess in this very simple example.) Your header and footer contain your site's template, split up as expected. The blog.php and post.php files include the header and footer. (We won't worry about navigation at this point, this is a simple example.) The Blog template file uses the API to find and retrieve all Posts, or its children. It then outputs the title, as a hyperlink, to the blog post itself. (This could be adjusted to make sure entries are chronological - normally it would likely retrieve them that way, but depending on how you develop the system that might not always be the case.) if ($page->hasChildren()) { echo "<ul>"; foreach($page->children() as $post) { echo "<li><a href='$post->url'>$post->title</a></li>"; } echo "</ul>"; } The Post template file wouldn't need to know about any other pages; its purpose is to display the content contained for its own page. Surely it can though - it could display next, previous, or related posts. Again: The API can help with those scenarios (related would likely use tags or categorization of some sort). So when someone visits the post, as linked to from the Blog, the post.php file would use fairly simple PHP to output its own content. Let's assume the post system template has 3 fields: Title, Summary, and Body. The Blog excerpt above only shows how to loop through its child pages to output links, the Post excerpt below will have a bit more HTML just to hopefully provide more context. <h1><?= page()->title ?></h1> <div class="blog-summary"><?= page()->summary ?></div> <div class="blog-story"><?= page()->body ?></div> Remember, content above and below are handled by the header.php and footer.php files that are included in the post.php file, in this simple example. I could've added it above, but, well...oops. ? Are you asking about an HTML region, or a ProcessWire markup region? Verbiage with ProcessWire can get a little confusing, so I just want to be sure. Assuming you're just asking about some random area of HTML content on a page getting dynamically loaded from other areas of the system - you'd use the PW API. So let's say you want to get the title of the current page from the header.php file, which is a template file, not a (PW) system "template", so it doesn't have its own PW "page" fields, it's just a file. But you can still use the PW API to query all pages, get a resultset, and then process that data to output what you want. You've seen the children() method above. You can also use the pages()->get() method to retrieve the site's root homepage, which can be referred to either as "/", or 1...so that would be $homepage = pages()->get('/'); or $homepage = pages()->get(1);. From there, you can use the return value in $homepage and then find its children. You now have a first-level for your navigation links, if you decide to setup your navigation based on the tree structure of your site (you don't have to). I can't say whether this is any more helpful or not than other forum responses, or examples in the docs. Generalized questions are really hard to answer simply because there are so many ways to come up with a solution and a lot of it depends on many various factors.

My personal believe is that ProcessWire would be the perfect platform for what you want to do, but you won't be able to completely circumvent a PHP learning curve. Since I don't know any platform or toolkit on the market that provides all the features you want without some programming (and the trend goes towards dropping pre-built solutions and requiring more programming, even with the "big players" like Sharepoint or Typo3), it's probably just a question of picking your poison. I'll try to answer your points as good as I can, though others with more experience with the specific requirement may have even better ideas. 1. Member login is possible with the free FrontendUser module. 2. Donations could e.g. be achieved with Stripe (Patreon, from what I hear, is cutting down on its APIs and trying to monetarize things to a point of pain). There's a stripe payment processor that's part of the commercial FormBuilder module. 3. Taxonomy is an integral part of PW. Tagging, either with plain text tags or pages (the later even created on demand when you add a tag or relationship item) can easily be achieved out of the box, and there are free modules for things like creating two-way relationships between pages. PW's philosophy that "everything is a page" may sound a bit scary at first if you've worked with CMSes like WP or Drupal, but in the most simple case, a page is just a title field and auto-generated name living somewhere in the page tree. 4. You actively have to implement (yourself or with a module) the blog behavior. If you want it, it's pretty simple with PW's built-in selectors and pagination. 5. Really easy to implement. Add a "featured" checkbox to the templates that are relevant, call $pages->findOne('features=1, sort=-created') to your home template and render the returned page. 6. This is easy too. Yes, it too requires small bits of PHP, but most of it is still CSS and JS. Just a small step up from a static HTML page. 7. Again, FormBuilder might be a good choice here. There are a few more options out there as well, and you'll certainly get good responses here if you inquire with a specific example or use case. 8. Rendering an RSS feed is possible (though I haven't used those in a long time) with free modules, it just needs a tiny bit of (well documented) programming. 9. Just add PW's core Markdown Textformatter or (if you want to mix Markdown and HTML) install and add TextformatterMarkdownInMarkup in the field's configuration, and it will convert the markdown when the contents are shown in the frontend. One thing I'd like to add: you'll certainly not find a CMS with a more friendly and helpful community than PW.

In order for you to answer this, I should give you some background first. I am not a web professional of any stripe. But I understand HTML and CSS and have kept up with them quite well. I have built static websites with only these languages. I have very little understanding of PHP, despite trying on and off over the years. I can understand simple statements, but if I use some example code, it must work as provided because I cannot alter it or add context. I once used Drupal for a magazine site, with my own theme. I am familiar with the interface but theming is extremely esoteric (and only seems to have got worse) and it can be very frustrating to implement anything a bit different. I have tried Wordpress and hated it; it made no sense to me and only got in the way of how I think. Why that is so popular, I don't know. I intend to set up a hobby magazine website and I want distinctiveness, flexibility, and expansion potential without going down a dead end and ending up out of my depth – mixed metaphor! – invested in a CMS which was the wrong choice for me. Here is a short list of some of my requirements, those which I am not sure are met by ProcessWire. Member log-in required for comments – its absence would be a deal breaker. Potential for later integration with services such as donations or Patreon. Taxonomy, ideally capable of building strong relevance between content. Not forced to use blog-like next/previous article links, pagination, chronology, etc. (These seem to be difficult to avoid in Drupal.) One newest article from each category in a “featured” section on the home page. Custom image galleries for showcases in masonry grids. Custom form building for a feedback form. (I would like to have control over the HTML but let the CMS provide the PHP as I have been successful in implementing PHP form processing.) RSS feed. Ability to paste Markdown into a content textarea. (I cannot get this to work in Drupal either, though.)

https://processwire.com/api/ref/sanitizer/entities-markdown/

I'm sure I've seen this before but can't find it anywhere… I have the TextformatterMarkdownExtra text formatter installed. I have a field that uses TextformatterEntities but in certain instances I want to switch to markdown on the fly. How can I do this. Obviously $page->of(false) first — and then what? Thanks.

No worries, I have no guidelines in place so nobody can know. Once I tried to protect the main branch from PRs but then something else was not working any more (I think automated releases)... But I think with this module and if it's only about new tweaks it shouldn't matter at all where the PRs want to merge, I'm not sure, I'll try that out tomorrow ? Great input. I've thought of a new parameter like "help" or something, and maybe one for "author" to give proper credits and one for "maintainer" if that's someone else (like you or @netcarver porting over tweaks from tpr/aos). "help" would be markdown syntax and show up in a modal. author/maintainer could be icons ? I don't think that I like the idea of having tweaks spread around several repos of several people! The module is MIT, so I'm happy to maintain it for now and if something should happen anybody could take over.

That might be another thing to test then, too - see if the automatic ZIP upload and decompression setting of a file field that ended up getting used in a, let's say FormBuilder form, which then creates pages for the user...would allow a PHP file to be created, and accessible, by a nefarious site user. In hindsight it seems silly to allow such a process to occur, but when you're so focused on the intended uses of something like this, the unintended sometimes is missed. (ex: Having a local writer's community website managed by ProcessWire, and allowing them to upload ZIP archives of text, html, photos, markdown, etc., to then be published for others to read/see - and then overlooking the potential for an HTML file to reference an external site via iframe that does some fun things - it's not specifically a ProcessWire issue, it's an oversight in development)