Leaderboard

@theoretic It's actually the opposite of that. ProcessWire is an API and that's all it is. Any output comes from the user of the API and not from ProcessWire, as it doesn't output anything on its own. ProcessWire started as a headless CMS, before the term even existed. The admin was later added on as an application built in PW, and then grew from there. But the base of PW is still just nothing but the API. ProcessWire itself doesn't output HTML. But since most use it for that, all of our example site profiles output HTML. There could just as easily be a site profile that outputs JSON or XML, or whatever you want it to. The point is PW has always been separate from whatever you choose to output with it, so that it has no opinion about what you use it for. While we could have a site profile that outputs something other than HTML, I don't really know what we would have it output or who it would be for, but maybe someone else does (?), it would be a simple matter.

Hello @theoretic, have you tried StaticWire? https://processwire.com/modules/static-wire/ I have used it once for a locally hosted website for a exhibition, but it worked for me as a basic SSG. For online hosted websites I always use ProCache, which is AFAIK similar to a SSG : https://processwire.com/store/pro-cache/#procache-is-for-speed-and-seo Regards, Andreas

Hi friends! And thanks for ProcessWire! Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements. JAMStack paradigm It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages: There's no need to generate pages each time they are requested from server. They can be generated just once. Returning static pages drastically reduces the server loading. Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there. APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact. Processwire vs JAMStack The current ProcessWire is pretty far from JAMStack paradigm: By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once). If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data. There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box. Processwire as "headless CMS" Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? ) Processwire as "static site generator" (SSG) SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW. Bringing the pieces together PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing: Native tools for building an API on top of PW. Again, it's doable, but it's not native. A PW-compatible (maybe even PW-based) SSG which won't be a headache. Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!". Hope this will worth a good discussion ?

I thought I would share this as I am finding it increasingly useful and am often using it to replace the standard PW modal. It allows display and customisation of admin page in front end as well as back end via a modal. In the modules library at https://processwire.com/modules/admin-in-modal/ . Also here https://github.com/MetaTunes/AdminInModal This module provides a Page hook method ($page->aim($array)) for front-end use and a similar Inputfield hook (for back-end use) to render a link to a lightbox modal containing an admin page. Optionally, class styling can be passed, otherwise default button styling is supplied. Full list of options and defaults for the array is : 'href' => null, // the url for the linked page (including any required GET params) 'text' => '##', // the text that will appear in the link 'class' => "uk-button uk-button-primary", // any suitable styling for an <a> tag 'width' => '90%', // size for iframe 'height' => '95%', 'header-text' => 'Save required changes before closing -->', // Text to appear above top left of modal 'save-head-button' => '1', // Adds a save button at the top of the modal. Set to '0' to omit. 'suppress-notices' => 'messages', // e.g. null/[]: no suppression, 'messages': suppress messages, 'warnings messages': suppress warnings & messages, 'errors': suppress errors 'close-button' => '1', // set to '0' to remove close button (but you'd better be sure you know how the modal will be closed!) 'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress) (From v0.3.0, these defaults can be configured in the module settings). For front-end use, the lightbox will only be rendered if the page is editable by the current user. Configure editability of the page by calling a hook after User::hasPagePermission The lightbox is provided by the Magnific popup, which is in the PW core. Although I have used it quite a lot, I cannot say that it has been fully tested, so is alpha at this stage and should be used with care. It is the user's responsibility to check that it suits their needs. Because it allows access to the admin back-end, particular care should be taken to restrict page-edit access.

Overview The TextformatterTokens module allows other modules to register tokens and replace them with actual values. Installation Enable the TextformatterTokens module. Enable the SiteTokens module. Enable the TextformatterTokens text formatter for a field. Usage Use tokens provided by the SiteTokens module inside a field that has the TextformatterTokens text formatter enabled. Save and display your page. The tokens should be replaced with the actual content. Example Tokens [site:name] [page id=123] where id is the ID of the page you want to embed its body field. Debugging You can view logs under your ProcessWire admin dashboard at Setup > Logs > tokens. Writing own tokens To create custom tokens, refer to the SiteTokens.module file for an example implementation.

@szabesz I've thought Lexical looks like a really interesting project so have been curious about it. I can't even make past the first line of their quick-start work though, it gives me a JS error. I'm interested to see what the guy from BookStack comes up with. I'd also like to experiment with Lexical more. TinyMCE is providing custom open source licenses to projects like ours, and I have requested it from them here, but so far the responses I've received from them don't seem to be aware of any of it. They've been giving me prices for commercial licenses, so I'm kind of confused. There is a fork of TinyMCE 6 called HugeMCE that will apparently continue on the MIT license, but not clear how far that will go.

@jploch @bernhard Long term I think we'll want to make it possible for others to sell their commercial modules here. But short term, what else can we do to help? You've both written some amazing page building software that deserves a lot of attention. Would you like to do a blog post about about it here? Or should we maybe have section on the site that highlights these tools? Perhaps something on the download or modules page? Doing commercial modules is hard either way, for me too, but I think it benefits all of us to have these tools available. Let me know what I can do to help.

Hi @bernhard and thanks for your warm welcome! Indeed, I will only have access to template files in a few weeks from here. OK, now I see why the changes to the page do not show up in frontend. Seems I will simply have to wait for access via ftp client. Thanks a lot for clarifying! (I am hesitating to fiddle with the templates via tracy debugger, as I am new to both PW and the company I am working at, but thanks anyway for the hint!)

Hi @Christophe you know, there must be far more sentences that are not translated, if you go to the language translations tab in french and search for "vide", you'll see, there is no remaining empty sentence, vide/empty meaning not yet translated, in the core translations part but, huge but, if now you click on this button you'll sse a lot of files to translate, some concerning your templates maybe, some the modules and some others a few parts of pw that are not in the core translation files now coming to your "Show this field only if" looking for it using the serach field, funny enough, it's in the file you see in the image, it is translated but... wow ? ? ? thank you, as i say on my github repos, i started from en existing pack and just updated the new missing sentences from 3.0.184 but, honestly, apart from some typos here and there, i never thought there were such mistakes, thanks to you this one will be corrected on the next master release french pack (Afficher ce champ... of course) ? Have a nice day

Aha! Always something more to learn... I use that module a lot, but never explored individual tables. I guess it's fine where the tables are 'stand-alone' as in this case, but otherwise it might get a bit scary. No matter, the module was quite quick and fun to write and hopefully carries less risk of screwing up the database ? EDIT: Plus I can integrate it into my migrations module if I want to.

@Christophe, glad you find it useful. Technically you don't need Custom Inputfield Dependencies if you want to show/hide a field according to the parent page ID. The PW core includes a "Parent" field in Page Edit on the "Settings" tab. This field is named "parent_id" so you can do something like this:

Welcome on board. So... as it seems your MariaDB isn't configured as it should be. What kind of setup are you using? DDEV, Laragon, local installation, or remote? You might want to get MariaDB fixed first. As far as I can tell, this isn't ProcessWire's fault. For the future tell us a bit more about everything. Setup, ProcessWire version, PHP version, and all these nice little details. For now I can only suggest that you look that error message up and check the solutions provided there.

See my query here: My solution was to bulid my own module - HannaMigrate. Basically it exports or imports all Hanna codes in a database. It was built to use along with my migration module ProcessDbMigrate, but should operate without it (but not tested). It provides 2 methods exportAll() and importAll() Simple usage: Install the module. Use TracyDebugger console in the source database to: $hannaMig = $modules->get('HannaMigrate'); $hannaMig->exportAll('optional_migration_name'); where optional_migration_name is a name of a related migration, if you are using ProcessDbMigrate. Otherwise leave blank and the code will be in assets/migrations/hanna-codes/. Then use TracyDebugger console in the target database to: $hannaMig = $modules->get('HannaMigrate'); $hannaMig->importAll('optional_migration_name'); (Do this while on the Hanna Codes page, then refresh the page to see the results and any error messages). You could also use the methods in your own code. I may look to integrating it more fully in ProcessDbMigrate.

@DrQuincy - I think you should really change your entire DB because that utf8mb3_general_ci encoding has caused you other problems as well. IIRC in your other related post I linked to a resource that explains how to make the change.

True, as long as you really set the charset to MB4 in the ProcessWire installer. This isn't the default I think.

Regarding page content creation by "site editors" in the admin, since TinyMCE's future regarding its open-source state is questionable, Dan Brown at BookStack started to implement a replacement based on lexical: Building a custom editor would also allow ProcessWire to cater to its own needs, like a live preview feature described as: It would be nice to be able to implement sort of block editor-like features in the RTE (and share them with the community). More complex block editors have their use cases and clients for sure, but for most projects, being able to do some sort of simple block editing would be enough, just like Ryan's example here: https://processwire.com/blog/posts/using-tinymce-6-in-processwire/#example-of-using-extra-css-styles. But, instead of very limited techniques like that, a custom RTE could provide a more robust solution without being a full-blown frontend block editor like RockPageBuilder and PageGRID. Such a custom RTE would automatically be supported by Ryan's PageAutosave module and its Live Preview feature.

No question, ProcessWire is fabulous for developers and the suggestions above would make it even better. Customers who are not developers are increasingly giving me feedback about how unintuitive the backend admin/editor is, especially now with the proliferation of DIY pagebuilders. Clients don't understand or care about the consequences. They care about not having to learn code to easily update their sites. They want the backend to look similar to the frontend, the convenience of doing it themselves without having to pay a developer. Too bad if the site doesn't work on all screen sizes, light/dark modes, isn't accessible, the home page looks like a ransom note, whatever. They genuinely don't like the default PW admin UI/UX. Pagegrid and RockPageBuilder modules are leading the way to solve this issue. Kudos to both developers BUT the modules are premium while a WP site gives customers basic WYSIWG page editing out of the box. My vote is to overhaul the admin UI/UX to make editing pages more WYSIWIG.

Until it is in the modules library, you can get it here https://github.com/MetaTunes/AdminInModal EDIT: Now in the library, Also I have released v0.3.0 which allows the defaults to be configurable.

Thx for sharing. Does it have a feature to auto-close the modal after page save (without errors) and then reload the page?

Thank you! I have just published this module to Packagist. It can be obtained through Composer with the following command: composer require zigit-dev/textformatter_tokens

@Jonathan Lahijani Please don't interpret what I wrote in reply to your post as negative - it's not meant to be. That may well be a fine solution for this. I appreciate knowing about the option, and having the link to the github issue you posted is a major bonus - I missed that one until now.

I've been continuing to work on the PageEditChildren module that I wrote about here last week. This week a "Clone" feature was added. You can click the Clone action and it'll create a copy of the page below the one you cloned, and then make it immediately editable before you even have to save. This Clone action is an example of an Inputfield header action, and it accompanies the Move, Pub/Unpub and Trash actions for each page in PageEditChildren. I thought this ability to add Inputfield actions seemed useful beyond just this module, so the ability has been added directly into ProcessWire's core Inputfields JS API. If you grab the current dev branch of ProcessWire, you can test it out if you'd like. You can paste these examples in your web browser's Javascript console. But in actual web development, you'd likely put these in a separate JS file that is added to your page editor with a hook. Open the page editor to any page, then open your Javascript console in your web browser, and then paste this in: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', callback: function() { ProcessWire.alert('Hello World!'); } }); That should add a hand icon to your "Title" field header, and if you click it, it'll pop-up a dialog box that says "Hello World". Let's say you wanted it to show a different icon when you hover it, and also to show tooltip text via a title attribute. You can add the 'overIcon' to specify what icon to show on mouseover, and 'tooltip' to specify the tooltip text: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', overIcon: 'fa-hand-peace-o', tooltip: 'Hello world', callback: function() { ProcessWire.alert('Hello World!'); } }); Above are examples of 'click' actions. We also support toggle or "on/off" actions: Inputfields.addHeaderAction('title', { onIcon: 'fa-toggle-on', onTooltip: 'Click to toggle off', onCallback: function() { ProcessWire.alert('You toggled on'); }, offIcon: 'fa-toggle-off', offTooltip: 'Click to toggle on', offCallback: function() { ProcessWire.alert('You toggled off'); } }); Toggle actions like this are primarily what is used by the PageEditChildren module to handle the Published vs Unpublished state, and Trash on/off state. Whereas "Clone" is an example of a Click action. Our callback functions in the examples above are very simple alerts, but of course you could make it do anything you want in those callbacks. Also added this week to the Inputfield JS API was an update to the Inputfields.label() function that now allows you to set the label for an Inputfield (previously it could only get the label). This is a bit of a contrived example, but since we were talking about header actions above, let's demonstrate the label() function within a header action. This example adds an action that lets you edit the Inputfield label: Inputfields.addHeaderAction('title', { icon: 'smile-o', callback: function($f) { ProcessWire.prompt('Enter new label', 'Label', function(val) { if(val) Inputfields.label($f, val); }); } }); By the way, there's a lot more to the Inputfields JS API, and it's all documented directly in ProcessWire's inputfields.js file. I'll be bumping the core dev version next week to hopefully accompany the first version of the PageEditChildren module. Thanks for reading and have a great weekend!

When I create a new Hanna Code tag I am always creating a PHP tag (I don't think I've ever had a need to create a text or Javascript tag). And I prefer to edit my tag code in my IDE rather than in the code field within the Hanna Code module. Because of this my Hanna codes always consist of... <?php include $config->paths->templates . "hannas/{$hanna->name}.php"; ...which just includes a file named the same as the Hanna tag from a "hannas" folder in /site/templates/ Always on the lookout for efficiencies, I had a go at automating the process of setting up new Hanna tags and come up with the following. Maybe it's useful to someone. In /site/ready.php: // Pre-fill code for new Hanna tags and create file $wire->addHookBefore('ProcessHannaCode::executeEdit', function(HookEvent $event) { $id = (int) $this->input->get('id'); // Include code for later use $file_include_code = '<?php include $config->paths->templates . "hannas/{$hanna->name}.php";'; if(!$id) { // A new Hanna tag is being added // Set type to PHP $this->addHookBefore('InputfieldRadios(name=hc_type)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->value = 2; }); // Set code to include file of same name as tag $this->addHookBefore('InputfieldTextarea(name=hc_code)::render', function(HookEvent $event) use ($file_include_code) { $inputfield = $event->object; $inputfield->value = $file_include_code; }); } else { // An existing Hanna tag is being edited (the new tag has been saved) // Get the data for this tag /* @var \PDOStatement $query */ $query = $this->database->prepare("SELECT name, type, code FROM hanna_code WHERE id=:id"); $query->bindValue(':id', $id); $query->execute(); if(!$query->rowCount()) throw new WireException("Unknown ID"); list($name, $type, $code) = $query->fetch(\PDO::FETCH_NUM); // If it's a PHP tag and the tag code matches the include code... if($type == 2 && $code === $file_include_code) { $filename = $this->config->paths->templates . "hannas/{$name}.php"; // Check if there is an existing file and if not... if(!file_exists($filename)) { // Define the contents of the file // Just the namespace and API variables for IDE code-completion // Some of this is PhpStorm-specific so adjust as needed $contents = '<?php namespace ProcessWire; //<editor-fold desc="API variables"> /** * @var Config $config * @var Fieldgroups $fieldgroups * @var Fields $fields * @var Languages $languages * @var Modules $modules * @var Page $page * @var Pages $pages * @var Paths $urls * @var Permissions $permissions * @var ProcessWire $wire * @var Roles $roles * @var Sanitizer $sanitizer * @var Session $session * @var Templates $templates * @var User $user * @var Users $users * @var WireCache $cache * @var WireDatabasePDO $database * @var WireDateTime $datetime * @var WireFileTools $files * @var WireInput $input * @var WireLog $log * @var WireMail $mail * @var \ProCache $procache * @var \FormBuilder $forms * **/ //</editor-fold> '; // Create a file and insert the contents above file_put_contents($filename, $contents); } } } });

@adrianI just had the same problem, which took me hours to figure it out...