Leaderboard

Admin Theme Canvas DEPRECATED: I am no longer supporting AdminThemeCanvas. Now that the new native KONKAT theme is part of the ProcessWire core, this module is largely redundant. Thanks to everyone who used and supported it!. This repository will remain available for legacy projects but will not receive further updates. To make the KONKAT theme behave more like this one you can install the AdminQuickTree module, which gives you direct access to the page tree navigation. A minimal admin theme with optimised page editor UI, based on Uikit 3. Currently this is close to stable, but users are advised to be cautious and test thoroughly. This theme is tested in all major Browsers including IE 11, Edge (>85), Chrome (>85), Firefox (>81), Safari (>11). If you find any bugs or have ideas for improvements, feel free to post your feedback. Download from Github Download from Modules Page Features Minimal black and white admin theme Fixed masthead navigation Direct access to page tree navigation inside page dropdown Less distraction for editors (when editing a page, the tabs are displayed as a dropdown menu inside the main navigation) Options to customise the ui Less distraction for editors Direct access to page tree navigation inside dropdown Page tree Options to customise the ui Login (inspired by AdminThemeBoss) Requirements Process Wire 3.0.100 or greater Installation Go to “Modules > Site > Add New“ Paste the Module Class Name “AdminThemeCanvas“ into the field “Add Module From Directory“ Click “Download And Install“ On the overview, click “Download And Install“ again… On the following screen, click “Install Now“ Go to your user profile page and change the theme to Admin Theme Canvas

As we often use Matomo (former known as Piwik) instead of Google Analytics we wanted to embed Matomo not only in the template code but also via the ProcessWire backend. That's why I developed a tiny module for the implementation. The module provides the possibility to connect to an existing Matomo installation with the classical site tracking and also via the Matomo Tag Manager. If you have also PrivacyWire installed, you can tell MatomoWire to only load the script, if the user has accepted cookies via PrivacyWire. To offer an Opt-Out solution you can choose between the simple Opt-Out iFrame, delivered by your Matomo installation, or a button to choose cookies via PrivacyWire. You'll find the module both in the module directory and via github: ProcessWire Module Directory MatomoWire @ GitHub MatomoWire @ Packagist ->installable via composer require blauequelle/matomowire I'm looking forward to hear your feedback!

Here is the first very early concept of a Page Builder. As per the conversation in the 'ProcessWire beyond 2021' conversation, I set myself a challenge to make a clone of YOOtheme Pro's Page Builder. This was mainly spurred by @Jonathan Lahijani's excellent overview of ideas of a page builder for ProcessWire. This is still in very early stages and I am not really sure where it is headed. I would like to hear the thoughts of like-minded persons ?. I would especially love to hear from @Jonathan Lahijani, @szabesz, @AndZyk and @flydev ?? please. Concept The page builder in its current state is a Fieldtype + Inputfield supported by other behind-the-scenes Fieldtypes without Inputfields. There are no hidden or extra pages in contrast to Repeater Matrix. All values are stored in the Page Builder fields for the page being edited. The fields do not store values as JSON. Definitions for elements, rows, grids, etc as stored as JSON. Currently, for storage purposes, 4 datatypes are supported - Text (HTML), images, plain text and headlines. From a storage perspective, the latter two are one and the same. Just texts with different 'schemas/definitions'. More on this below. The fields are multitype fields. This means one page can hold multiple texts, allowing for repeatability. Similar datatypes are stored together in one field/table. For instance, there is no reason why a (future) URL element (datatype) should not be stored in the same table as plain text. At the database level, they are both just texts with similar requirements. At the processing level, URLs vs other plain texts (headlines, etc) are handled differently (validation, sanitisation, etc). Each 'element' represents a row in a table for most types (e.g. slideshows are slightly different). Querying and access of field values is via the main Fieldtype - FieldtypePageBuilder. However, the supporting Fieldtypes can be also be accessed and queried individually, if one wishes, using normal ProcessWire selectors. The supporting Fieldtypes, if such need arises could easily become custom tables instead (but best to keep them as Fieldtypes - easier querying with selectors, etc). It is totally CSS-agnostic in relation to frontend output. You bring your own CSS. In the preview, you can also use your own CSS. In the frontend, you can choose to output raw values as you wish or use inbuilt render methods to render the whole layout for you or to render the value of an element as per its tag definition (e.g. headlines as h2, h4, etc) where applicable. Fully multilingual (although the editing UI not yet implemented). Issues The main issue is the real estate needed for InputfieldPageBuilder. Any such page builder would require the whole width of the window. As you can see from the screenshot below, this obviously throws things out of kilter with respect to the ProcessWire page edit UI, in any theme (I believe). I am not a designer so would love to hear from you about possible solutions. My current thoughts are: Modal Open the page builder in a modal for editing. Pros Would allow for use of whole real estate. Title and other fields would not be in the way. Cons Editing in modals can be tricky? Other..? Process Module Pros Solves the real estate issue. Cons Disconnect between the page being edited/created and the page tree. Screenshot No attempt has been made to theme it as per any current ProcessWire theme (that I know of). This was a quick and dirty-ish clone of YTPB. As stated, however, the current ui is not acceptable as an Inputfield for, mainly, real estate reasons. Video Demo This is a demo for the Page Builder app outside ProcessWire. Thoughts? Thanks. PS: I currently have no time to continue working on this (Padloper, etc..)

The Bard field in Statamic has been been discussed and mentioned several times in the forums, dating all the way back to 2018, as something worth emulating in ProcessWire. Here is a short demo of a proof of concept of an unimaginatively (temporarily?) named (and very colourful) module doing just that. Demo App running outside ProcessWire. Screenshot Screenshot of the app in InputfieldBrad, running in a modal, quirks and all. Way Forward I don't know but no current plans for any sort of release, paid or otherwise. I like where @flydev ?? is headed with FieldtypeEditorJs so let's support that ?.

I guess you forgot to set the working directory in your crontab. You should invoke Tasker using cron this way: */2 * * * * docker exec --user nginx phpweb bash -c "cd /var/www/html/site/modules/Tasker && LD_PRELOAD=/usr/lib/preloadable_libiconv.so /usr/bin/php runByCron.php" You can skip the docker and LD_PRELOAD parts but you need to set the working directory (cd ......./Tasker). I don't really understand the other problem, sorry. Do you have trouble with the createTask() method called from your own module?

Inputfields have two separate settings for setting the required flag for backend validation, and including the required attribute in the HTML output. In a regular text field settings, there are two settings for making a field required and including the required attribute in the frontend as well. For API usage: $field->required controls the backend validation, the HTML attribute can be added with $field->requiredAttr. So this should work: // make the field required for backend validation $field->required = true; // include the required attribute in the HTML output $field->requiredAttr = true; Though I have used this in different contexts to varying degrees of success. Might also try to force the attribute with $field->attr('required', 'required').

Great job jploch and kongondo! Ya'll can really put together modules quickly. Looks like that could also be used as "Freeform layout builder" component/section that can be added to a normal page table like I show above? jploch, I wasn't clear on how the user gets to see the grid editor in your example video? Do they click on a button to enter into the grid editor or does it take over the normal page editor somehow? I also like the mobile preview buttons at the top? Maybe ProDrafts preview mode can add those? I think CraftCms just added that feature as well? I expected it would work like the ProDrafts preview mode's sidebar? I just don't want the preview area modifying the site's markup. Like adding plus icons everywhere or drag and drop. That is what the Godaddy.com editor does. I'm not a fan of that. Sometimes those *features* can cause CSS conflicts and cause the preview to mess up. See below for example of the buttons that appear on hover: I like how the ProDrafts preview mode doesn't add those *features* to the preview area. On another note...people here were also talking about Editorjs.io and storing content in json in the database. I ran across a spec for that from https://www.sanity.io/ it's called Portable Text https://github.com/portabletext/portabletext and they talk about it more here. I guess you can run into problems when creating headless sites that store rich text as HTML in the database? They use JSON instead to remove all the styling and so on. I'm not sure how widely it is used, but I thought I would mention it in case anyone hasn't heard about it. I'm also not sure if it is compatible with Editorjs.io?

@flydev ??, Spot on, everything you've said! I've been thinking along similar lines! I wish I could give you more likes! ?. I agree and I don't think it should be limited to this group. Lowering the entry barrier to any software, especially in the modern age is incredibly useful. Look at all the rage about coding for kids, etc. Python is great in this regard. So are tools like Flutter. For a while I was of the notion that things like page builders are somehow anti-pattern with respect to ProcessWire. Lately, I have had to discard that opinion. Don't get me wrong, I am not saying that the core should provide this capability. No, such things can be built by the community. For me, when we say that ProcessWire is simple, powerful, enjoyable, scalable, familiar, friendly, etc...., that encapsulates the absolute freedom the tool provides me. I can do almost anything with it. It doesn't take away from the tool. It is a testament to how versatile the tool is. Behind the scenes, it is still ProcessWire. The output, what I can do with it, well, that is the magic that is ProcessWire. And for this, I have to give Ryan credit. I doubt there are many CMSs out there that will allow you to extend it as much as ProcessWire does, yet remain stable and secure. I don't see this as a problem at all, but rather an opportunity. I am not talking about the more the merrier. Rather, making a powerful, enjoyable tool accessible to people with different skill sets and different approaches to building things. That is a good thing, maybe even a great thing. In the end, we all want the same thing. To build secure, reliable, fast, stable websites/portals for our clients. If you can achieve that via pure coding, more power to you. On the other hand if you can achieve that (at least partly) via drag and drop, nice one mate! More power to you too. In addition, a builder doesn't mean the builder will just output code arbitrarily. On the contrary, the dev still has full control over the output, access controls, etc. This is crucial! In the same manner we lock 'fields' , 'templates', 'modules', etc., we can and should lock the builder down, both at the visual and processing data level. Exactly! That's how I've designed the builder I worked on this weekend ?. Looking forward to this! Hopefully, in the next few days you will also have a preview of the page and content builder I developed over my weekend hackathon ?.

I often develop ProcessWire websites for large companies and organizations, where there are 20+ employees. In these scenarios, my point of contact is almost always someone with a marketing or managerial role. Here are the actual positions I just pulled from the email signatures of my go-to contacts of several of my clients... notice the similarities: SVP Marketing Marketing & Business Development Marketing Associate Director of Marketing Director of Marketing (again) Assistant Marketing Manager Marketing & Communications Coordinator Production Artist Office Manager These marketers are the ones who manage the day-to-day content needs of the site. They are not coders, but are generally technically savvy. They like ProcessWire, or at least the way I set it up. They oftentimes need to throw a page together that's not strictly defined by a template. They need some flexibility to express themselves. While this can be done with Matrix in its current state (say you made 20 different sections that they can choose from), it requires a lot of planning beforehand and can't handle edge-cases without developer involvement.

ProcessWire is definitely a sustainable open source project and here for the long term. Though if the standard of adoption measurement is WP, then we are nowhere near that and never will be. I certainly wouldn’t want that either. But our installation base is already much larger than I would have ever believed possible. This is in part because ProcessWire has grown, but also because the demand for what ProcessWire provides has grown, as has the entire online landscape. When a client hires us, they hire us because they aren’t web developers themselves, and they want an expert. If the client has already decided on the best tools for the job, which is not their expertise, then they aren’t looking for an expert. I hope that most of us can be selective enough not to take on such clients. There are also cases where you as the expert may decide that WP is indeed a good fit for their need. So long as the client understands what they are getting into, and they trust your expertise, why not use WP? Maybe some think that PW should always replace WP, but they are different animals with their own strengths, and neither is a replacement for the other. To be honest, I am glad that WP is where it is and has the usage that it does. In some ways PW is successful because of WP and the path it has opened for PHP, MySQL, content management and open source. WP has helped to open the gates so that even a relatively small project like PW can have a significant self sustaining user and installation base. I see no harm in expanding FieldtypeFloat to support a decimal column type, so I’m going to go ahead and do that. Is there any issue in the existing FieldtypeDecimal that also needs to be solved when I put in this update? This is the AdminThemeFramework class, which AdminThemeUikit extends. While it hasn’t really played out that way yet, AdminThemeUikit itself was built to be a more generic base, though for Uikit-based theme) The AdminThemeUikit module (and its supporting files) are also a good template for marrying a CSS framework with an admin theme. I don’t see much potential for an abstraction layer between AdminThemeFramework and AdminThemeUikit. If I wanted to build an admin theme that used a different CSS framework, then I would copy all the files from AdminThemeUikit, replace the Uikit library with another, and update the files as needed for the other framework. AdminThemeUikit is already the default for new installations. For existing installations where someone has already selected AdminThemeDefault or AdminThemeReno as their theme, then we don’t change their selection. Although I think AdminThemeUikit has effectively replaced AdminThemeDefault, and I don’t plan on doing any more with AdminThemeDefault, other than probably dropping it at some point. I would like to keep AdminThemeReno though maybe refactor or rebuild it so that it is also using our base AdminThemeFramework. That you Jonathan, this is a really fantastic overview/presentation of the builder concepts. Also, amazing work with what you’ve built! My impression is that yes we could certainly take RepeaterMatrix quite a bit farther in supporting a lot of this (moving children with parents, limiting child types, etc.), per the things that have been outlined here and in your video. And maybe I should add those things, just to open the door at least, and let people decide how they want to use them. But it’s uncertain if RepeaterMatrix is the best foundation for this builder concept (as you’ve pointed out). To take it further, I think it’s also uncertain if pages are even the best foundation for each element or section in a builder. In a page builder, there doesn’t seem to be much technical need for all the data to be stored in separate fields and pages, because it all seems to be aimed at achieving some front-end layout rather than a flexible and accessible inventory of data. All of the sections, elements, etc. in the builder seem to be aimed at segmenting content for a particular layout on a single page. This separation is about front-end layout, and not much else (is this even content management?). I think the back-end storage of it should also reflect that. Basing it on a Fieldtype does seem to make sense, but RepeaterMatrix is really overkill on the storage side, while not enough on the editor side. Given this, it seems like a site builder might benefit from being a new Fieldtype rather than one based on Repeaters. Though I can already see there are drawbacks and benefits either way. One question for those interested in a site builder: who is the audience for it? Whether we should be looking towards something really simple, or something more complex, likely depends on the answer. It looks to me like the audience is primarily web developers, or at least people that know some web development, because you’d need some pretty savvy clients to use tools like this. Though “The Bard” looked like something I could potentially walk a client through. But it’s obviously not nearly as powerful as something like the YOOtheme builder. That one looks like Dreamweaver for Uikit. Is there demand for that? It’s technically quite cool, but is it wise or portable to couple content with layout like this? It’s clearly a compromise, but maybe it depends on the use case. CKEditor is also a compromise, but it’s usually portable and semantic enough for the content to survive site redesigns. I like and am open to adopting Vue where needed, but not at the expense of jQuery. I don’t lose interest in a particular tool just because it’s been around a long time. I know everyone likes what’s new and always changing, but for me, some of the best tools are the ones that have been around a long time. jQuery remains one of my favorite tools and an important part of ProcessWire's admin. Now if we have to change the way we use jQuery, such as using jQuery() instead of $(), in order to integrate a library like Vue, then I would be fine with that. As fun as it looks, building a tool at that level probably isn’t realistic (for me anyway). If we were to have a tool like that, we’d want to adopt an existing open source tool, much in the same way we do CKEditor. That would be ideal. If that’s even an option? I spent some time checking out the Unpoly library and thought it looked pretty great! Hotwire’s video lost me though, some guy talking on top of a video on fast forward, zipping through command lines and such, insanity, can't tell what the hell is going on.

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits. I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan ) (note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem) Please share your thoughts.

Thx! Warnings will display with a yellow (#ffe299) and errors wth a light red (#f8ada5) background

Super theme ? A simple tips. If you are using - the must have module - BreadcrumbDropdowns from @Robin S, it will work with this theme once you put this config line in the module config : AdminThemeCanvas::renderBreadcrumbs ?

My theme is still extending the default admin theme and updating uikit is not a big deal, however changes to admin theme uikit php files would need to be done manually. I cloned the admin theme uikit to have more control of the markup. I plan to support this if people are interested, Iam using it for all my new sites. A version that extends the uikit theme like admin theme boss does would then rely on Javascript and CSS to manipulate the dom right? Using a hook could be an option. Maybe someone better with hooks could colaborate ?

@jploch - this really does look very nice - much cleaner and more professional. I really appreciate the hard work that's gone into it and I would love to use it, but unfortunately for me it always comes back to the fact that themes in PW tend to end up out of date when Ryan applies fixes and new features so I find it's just not worth the risk. Am I the only one that feels this way?

The procedure I use is: Old Server: Download the database export. Download the site folder (you can skip cache). New Server: Install Processwire (same version). Delete the site folder and Empty the database. Upload the site folder from the old host. Import the database from the old host. Empty cache and sessions. Update the config.php where necessary (database credentials, etc.). Creating a site profile is not necessary. [edit] Since all my machines are *nix based, I use rsync to maintain duplicates: rsync -azP host:source destination

You can use a hook to append a formatted created date to the end of the page list label. In /site/ready.php... $this->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $created = date('d/m/y', $page->created); $event->return .= " $created"; });