Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 12/24/2020 in all areas

  1. 42 points
    Last week I asked you what you'd like to see in ProcessWire in the next year (and years ahead), and we got a lot of feedback. Thank you for all the feedback, we've had a lot of great and productive discussion, and of course feel free to keep suggesting things too. Below is a summary of things based on what I thought was feasible from the feedback so far. I'm not suggesting we'll be able to do all of this in 2021, but do think it makes a good preliminary roadmap of things to look closer at and start working on some very quickly. I'll keep working to narrow this into a real roadmap, but wanted to share where we're at so far (consider it preliminary/unofficial): Flexible content or page building One of the most common themes has been that people want more content building options as an alternative to using a rich text editor at one end, and page builder at another. This is a direction that some other CMSs have been going in (like WordPress), and one that many would like to see ProcessWire provide an option for as well. But the needs seem to come from two different angles, and it points to us pursuing 2 directions simultaneously: First would be a flexible content block style editor in the core as an alternative to rich text editor that supports pluggable block types while maintaining best content management practices. If possible, we'd use an existing tool/library like editor.js or another as a base to build from, or potentially build a new one if necessary. To be clear, it would not be a replacement for CKEditor but an alternative approach supported by the core. Second would involve improvements to Repeater/RepeaterMatrix that enhance its abilities in supporting those using it for building more complex content page builders. Since many are already using it for this purpose, the goal would be primarily to better and further support this use case, rather than make Repeater/RepeaterMatrix a dedicated builder. Jonathan Lahijani and others have pointed out some specific things that would help achieve this and I plan to implement them. Admin theme improvements We would like to add additional flexibility to the AdminThemeUikit theme so that people can further customize it how they would like it. What directions this will take aren't nailed down quite yet, other than to say that it's going to be getting some focus (and this has already started). At the very least, we know people want more sidebar options and the ability to tweak specific CSS, perhaps in a preset fashion. Improvements to existing Fieldtypes and Inputfields Things like support for a decimal column type, more date searching options and additional input level settings on other types. Though these are specific feature requests and our focus is more broad, so we'll be going through many of the core modules and adding improvements like these and more, where it makes sense. Pull requests and feature requests People would like to see us expand our code contributor base by merging more pull requests in cases where we safely do it. We will also be narrowing in on the specific feature requests repo to see which would be possible to implement this year. External API There are requests for an external/front-end API that would also be accessible from JS. I support the idea, but have security concerns so am not yet sure if or in what direction we might take here, other than that I would like us to continue looking at it and talking about it. File/media manager and more file sharing options There is interest in an option for a central media/file manager so that assets can be shared from a central manager rather than just shared page to page. There is also interest in the ability for file/image fields to reference files on other file/image fields. External file storage Some would like to be able to have PW store its /site/assets/ and/or /site/assets/files/ on alternate file systems like S3. That's something we'd like to use for this site too. To an extent, work already started on this last year with some updates that were made, but there's still a long way to go. But it will be great for sure. Live preview and auto-save There are requests for live preview and auto-save features to be in the core. Currently they are just in ProDrafts, but there are now more options and libraries that would facilitate their implementation in the core, so I'd like to see what we can do with this. More multi-site features There is interest in ProcessWire natively supporting more multi-site features, potentially with the option of working with our multi-language support.
  2. 28 points
    This week I’ve been doing some work on the core, but it’s been a short week with the holidays, so I’m holding off on committing the updates till I can test and tweak them a little more next week. I’ve been working on some upgrades to the core Fields editor (Setup > Fields), as well as some improvements to our Inputfields system, among other things. Next week I’m also planning on working through some of the GitHub issue reports and some other parts of the core as well. With it being Christmas today, I’ve barely been at the computer and I’m guessing not many of you are either, so I’ll keep this short and wish you and your family a Merry Christmas and/or Happy Holidays!
  3. 24 points
    This week I've had to work on a client project (and that continues for the next week or two), but also have some good progress in the next development branch version of ProcessWire (v3.0.171), which includes the addition to two feature requests: The Repeater Fieldtype (and likewise RepeaterMatrix) was updated to improve support for the "depth" option by introducing something called "family friendly mode". This makes the "depth" setting behave in a manner where items with more indent are considered children of items with less indent (parents). So when you click and drag to move a parent item, it brings along the children too. This works whether changing the location or the indent of the parent. In addition, it enforces the parent/child relationship so that there can't be more than one level of indent between parent and child. So you couldn't (for example) have a parent-to-grandchild relationship in the repeater items. A useful case for this is when using repeaters in page builder contexts, like those Jonathan Lahijani demonstrated with RepeaterMatrix. In fact, the settings in this "family friendly" mode were his idea. More to come here too. To enable "family friendly mode", go to your Repeater or RepeaterMatrix field settings and make sure the "depth" setting is greater than 1. When greater than 1, the family-friendly option will appear as a toggle you can enable. The other thing added to the core this week was a FieldtypeDecimal module that has been requested for awhile. I was planning on making it a setting of FieldtypeFloat, largely to avoid interfering with the existing 3rd party FieldtypeDecimal module. But a few people indicated they'd prefer it to be separate. After testing on an installation that already had the 3rd party FieldtypeDecimal installed, I found it didn't cause any problems, so that alleviated my concern. To be safe, the new core FieldtypeDecimal module uses the same exact setting names as the 3rd party one, so that hopefully they should remain compatible. In my case, I found that deleting my /site/modules/FieldtypeDecimal directory, and then doing a “Modules > Refresh” enabled the core one to take over with any existing decimal fields. However, until we have reports that the same works well for others, I would suggest backing up and confirming it yourself to be safe. It's not often we intentionally introduce module name collisions, and I don't think we've ever done it in the direction where a new core module overlaps with an established 3rd party one. But in this case, it does seem to facilitate the transition a bit. That's all for this week. I've been enjoying and am looking forward to continuing with our roadmap discussions hopefully next week. Have a great weekend!
  4. 24 points
    Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? 🙂 Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here 😎
  5. 22 points
    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..)
  6. 21 points
    Shetland.org is a website run by Promote Shetland which inspires people to visit Shetland, encourages people to move to Shetland to live, work and study, and attracts people to invest in commercial activities in the isles. We (NB Communication) have run the Promote Shetland service on behalf of the Shetland Islands Council since 2017, and as part of the contract undertook a project to redevelop the existing Shetland.org website. In this showcase we’ll highlight a selection of modules we used and what they helped us achieve. Visit the site: www.shetland.org Pro Modules ProCache We use this on almost every site we build. Indispensable. The cache settings used are pretty simple – most templates are set to 1 week, with the entire cache being cleared on save. We use ProCache’s CDN functionality to serve assets from CloudFront via c.shetland.org. We also use the API provided by ProCache to compile (SCSS), minify and collate our styles and scripts via $procache->css() and $procache->js(). We then use the URLs returned to preload the assets, making the site even faster! ProFields: Repeater Matrix Again, we use this on almost every site we build. Another must have Pro module. This module allows us to create a really powerful page builder field (we call it ‘blocks’) that handles the majority of the content on the site. On a simple development, we just use two block types - Content and Images - the latter displaying as a gallery or a slideshow. On this site we have 13 different types, including ‘Quotes’, ‘Video’, ‘Accordion’, and ‘Links’. Additionally many of these are configurable in different ways, and some render in different ways depending on the template and context. Have a look at the links below for some examples: https://www.shetland.org/visit/do/outdoors/walk https://www.shetland.org/blog/how-shetland-inspires-me-artist-ruth-brownlee https://www.shetland.org/life/why/teach-shetland-school NB Modules We also used a number of modules we've authored: Instagram Basic Display API Used to retrieve the 6 latest images from instagram.com/promoteshetland. Markup Content Security Policy Used to implement a CSP for the site. Currently scoring a C on observatory.mozilla.org – not the best score possible but significantly better than all the other destination marketing websites I tested (all got an F but one which was a D-). Pageimage Srcset Used throughout to generate and serve images of different sizes via the srcset and sizes attributes. This module is really useful if you are looking to optimise the serving of images to improve page speed times/scores. Video markup for YouTube/Vimeo This module was developed specifically for use on this website, as we wanted more control over the rendering of the oEmbed data. In the example below, the video thumbnail is displayed with a text overlay – when clicked the video (YouTube embed) opens in a lightbox. And a big shout out to… Page Path History The previous site was also built by us in ProcessWire, but a number of years ago now. The new site has significant changes to the sitemap, but 1000+ blog posts were also migrated. Instead of an .htaccess file with thousands of 301 redirects, we were able to use the functionality provided by this module to implement redirects where required, and in the case of the blog posts which were migrated via an import script, implement the redirects via the API - $page->addUrl(). ... The above is just a fragment of the features present on this site, and the development just a part of a much larger project itself. We're really proud of what we've achieved, and we couldn't have done it without ProcessWire. Cheers, Chris (NB Communication)
  7. 20 points
    Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/
  8. 20 points
    For years, as a personal project, I've been documenting my little corner of the globe via my personal website www.marlboroughonline.co.nz, which also gets used as my testbed for new ideas with ProcessWire, SEO and other stuff, as I'm not going to have some client on the phone if I break something, but if I do it well, I can earn a few dollars from Google adsense. I've always had a bit of a passion for natural history, being introduced to David Attenborough documentaries when I was a teenager, and actually studying life sciences at university, so it's only natural if you'll excuse the pun, that a part of my site would be dedicated to documenting local plant and animal species in my part of the world. For many years, one of go to reference websites for information about native plants has been New Zealand Plant Conservation Network, and I often include a link from my site to details on a species on the site as an authoritative reference, and I use the site to help identify plants I've photographed. It was only recently that for some reason I decided to have a look at the source code of the site, and it looked suspiciously like it was made with ProcessWire. After a bit more detective work, I found out that it was made by @Robin S and is indeed built with ProcessWire. To get away from the computer, I also teach kids edible gardens at my daughter's school a couple of hours a week. It's part of a wider Enviroschools programme here in NZ, and among other things it covers is teaching kids to recognise noxious weeds. There's a really useful website Weedbusters that's supported by councils and used as a reference for many invasive plant species, and it turns out it's more of Robin's handiwork. I think it's a bit funny that even when I'm supposedly away from ProcessWire engaging in other activities, it seems to follow me around. 😀
  9. 16 points
    This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348. I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!
  10. 16 points
    Your points about this are all completely fair. It's up to you to integrate or reject the changes a PR does. Currently the latter however does not happen in a manner visible to the creator of the PR or anyone else looking at the PR. So they just stack up looking like they were never looked at. If you consider something not possible to be added (or even not possible in the near future) everyone is better off if the PR would be closed with a short note of the reasoning. PRs do not age well and it's better to close them than letting them sit until no longer mergeable. The closed PRs (and issues) are still searchable, so if people to their due diligence they'll see that things were rejected before, find related discussion if attached, …. If you're not happy with the code for a given change you can also help people come to a version you're happy with maintaining without needing to go code it yourself. This does even work for issues. One of the most encouraging responses to issues I know from other OSS projects is "Sounds good. PR welcome.". I rarely see that as a response to bigger feature requests, but on smaller incremental things making parts of the project better it's a good way to move the burden of actually fixing something off of the maintainer themself. If a PR is not of that kind it's totally fair to close it with something like "This is to big a change and needs upfront discussion before consideration.". You don't need to take the time of reviewing PRs in depth, when you already know you'll not merge from just the title/description/amount of changes/…. So in conclusion: Without a response from your side a open PR is dead weight in the context of the community helping you improve processwire. Someone did some work and now it's stuck. Even if the response is negative it'll give anyone involved context either to adjust and be fine with things not being added or next steps to get things integrated either by starting a needed discussion, changing the code or implementation or whatever else needs to be done before it could be merged. Given the fact PRs don't age well I also feel response should be reasonably timely – even if the merge actually happens at a later time. Take a year and the PR creator might have moved on or worked around it, the underlying code changed in the meantime so the PR is no longer easily mergeable, but the issue fixed by the PR might still be present. I know this well given I have two open PRs for processwire from 2017 – one small fix, one not as small feature. I hardly use processwire anymore by now.
  11. 16 points
    Hear, hear! 👍 One place to find ready answers to this question is the requests repo: https://github.com/processwire/processwire-requests/issues That repo currently has 289 ideas for improvements, and it would be fantastic if you can find the time to do a quick first pass through the repo and add any comments or questions to the requests, and indicate which ideas you think are the most promising for developing this year. At the top of my wishlist is an Image Reference fieldtype: https://github.com/processwire/processwire-requests/issues/207 I'm imagining something that works much like a Page Reference fieldtype, with various options for defining which images are selectable and some elegant way of selecting from a large number of images (maybe a modal interface similar to Lister that lets you filter and select images for adding to the field).
  12. 13 points
    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.
  13. 12 points
    I wonder if anyone else can weigh in on directions here? I know a lot of people like the editor.js direction, but Bernhard has also posted what seems like a good direction. They are very different directions, but seem to accomplish similar things. Ideally I'd like the community to narrow in on what's best for their needs and for ProcessWire. I don't think I'm the audience for this builder (my projects don't use this approach), but I really want ProcessWire to meet this need and compete in this space. I trust the community advice on this more than my preferences so would like to hear from you. I've spent some time looking at editor.js, and here's a benefits/drawbacks list that I came up with: Editor.js benefits Easy for users figure out, but does require experimenting with it to find where the tools are. Tools only visible contextually so everything is very clean, no real baggage until you need it. From a marketing/appearance standpoint, maybe good for PW (?). Storage is simple JSON, which is easy to work with as a PHP array on the front-end. That's assuming you need the content separated like this in the first place, which presumably the developer audience for a builder would be. Since it's a modular/plugin system, it has potential to offer more down the road than it does now in terms of capabilities. To me it also seems like kind of a cross between a full builder and something like CKEditor, so it might appeal to some as an alternative to CKEditor for certain cases. It already seems to have wide adoption and be an active open source project with a good track record. Editor.js drawbacks Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block. Interface that while nice in many respects, is completely different and inconsistent from anything else in PW. You are forced into using HTML elements (like <p>...</p>) as blocks, rather than being able to have something like a "rich text" block. It seems to me like a "rich text" (CKEditor) block is more useful than assuming every block-level HTML element to be a builder block. There are surprisingly few plugins, and few (or none?) seem to go much beyond what you can already do in CKEditor. Maybe the potential for creating our own new plugins is greater than CKE, but it's all JS and we mostly work in PHP. Unclear if there are any tangible benefits to the user relative to CKEditor. I'm also guessing most clients would prefer CKEditor since it's more like working in MS Word. Maybe it doesn't matter since this is a different animal and you might not swap one with the other anyway. If we are to do anything beyond the basics with it, it looks like it would be a lot of work. The plugin system looks beautifully simple at its base, but the actual implemented plugins look surprisingly verbose/complex for what they do. We couldn't use our existing Inputfield modules for new blocks (like an Image block) and so would be starting from scratch on a lot. I've also spent some time with Bernhard's editor (he sent me a demo) so will also come up with a benefits/drawbacks list for that. Interested in any other approaches you think we should look at also. Regardless of direction, my plan is to bring live preview and auto-save into the core, as I think all builder directions would benefit from that. Also, I want to mention the RepeaterMatrix stuff discussed earlier is something we'll be doing either way, I consider that just part of regular updates to the module, and so that's a separate project.
  14. 12 points
    @ryan I can collaborate with you on improving Repeater Matrix and giving you a really deep understanding of page builders, issues that would be faced and my thoughts on a direction ProcessWire can take. I've built a module internally that demonstrates a lot of these concepts.
  15. 11 points
    The other great thing about it is that it's a very realistic thing we can do. Though Jonathan's video pointed out a lot of drawbacks. Maybe we can solve some of them with upgrades to RepeaterMatrix like Jonathan proposed, and maybe others are acceptable drawbacks given our context is very different from tools like WordPress. Plus, it seems like Jonathan is already using this approach successfully with clients. I took a closer look at https://editorjs.io/ and I like it for a lot of the same reasons I liked what The Bard example was showing. The plugin-based approach for blocks it uses looks great and this seems like something we could probably integrate pretty easily/quickly since it's based off an existing tool that handles the difficult-to-code parts. Being able to solve this need with an existing tool like this is the ideal route IMO. While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management. Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. I'm already a fan of Unpoly after spending a lot of time looking at it, particularly with how lightweight it is relative to what it does. There isn't anything hard coded in it. The top area is a CKE and images field, and images use tags to place in groups. The next part is list of features/highlights, each with headline, icon, description, and link; these are a FieldtypeTable field. Another FieldtypeTable field manages quotes (quote, cite, source, active), which are pulled randomly in different parts of the page, as well as on other pages in the site (which pull from the same field). Everything else on the page is pulled in dynamically from other parts of the site. For instance, the blog part always shows the newest blog posts, the showcase part always shows the newest site additions, the Pro modules part pulls from the /store/, etc. So there isn't really much code on the actual homepage template, since it's actually the other parts of the site rendering each of those. I agree, I will add this. Yes, that has been my experience as well and so this was one of the things ProcessWire has always tried to solve from the beginning. Keep the client focused on semantic content and not on style, layout or presentation. It's also why I've never been a fan of front-end editing. As soon as the person editing content takes their focus off of meaning and shifts to presentation, that's where things go south and content is no longer portable. I see a fundamental job of a CMS being to manage portable content. With all that said, it does seem like there is an exception to the above (per what Jonathan mentioned earlier). That is, the perhaps temporary 1-page marketing things, where questions of portability don't really matter and the short term marketing needs do. This is already built into FieldtypeFloat, so another good reason for it to add DECIMAL column support. Well in this case, we would add the support to the core, so one wouldn't need to use Combo for that purpose. A number spinner is built into the HTML5 number type, which is already an option for the float field. What's lacking is the ability to modify the step value from the default. I can add that, no problem. @Robin S I've been experimenting with your Uikit admin CSS additions and a few of them (some of the "fix" ones) seem like they should be added to the core. Some of the other more subjective ones, you've got me thinking we should have a "customization presets" dropdown in the Uikit admin that lets you select predefined customization sets like yours. I think having separate configuration settings for all the different things you've changed is probably too much configuration, but presets seems like a good way to answer common preferences people might have?
  16. 11 points
  17. 10 points
    You are all right and everyone have good arguments. A page builder should be built IMO. As a recent example, I needed to build a cool invoice, like the one you receive in your inbox sent by big companies names. Their email look so fun/cool/responsive that YOU WANT TO DO THE DAMN CLICK on their call-to-action button. Then I found a cool software called "Nicepage", where you move blocks, edit styles and content, and tada, a cool page done in a minutes, with clean code, really - after a copy-pasta moment, I had my invoice in my template sent by PadLoper. I think it's @Jonathan Lahijani that was saying something in this, users which build marketing pages, landing pages and other things like that, it's just incredibly useful. Another example, I don't build website everyday anymore, but backends (based on ProcessWire) with public/restricted API and desktop/mobile apps connected. I can imagine how easy it could be to extract/manipulate data from an external apps (What's happened with EditorJS). Plus, and even if it's not the primary goal, given the tool we already have in our hand, it will make a bump on new users/devs which will use ProcessWire. The right ones ? not sure, maybe the forum will be spammed by "unexperienced user" which will try to build a website with the builder but doesn't understand in first instance how to apprehend ProcessWire. But it should be developped keeping in mind what all the devs say in their different horizon. I mean, a system of permission should be built-in, every blocks or type of blocks should have a permission, restricting some functionalities that could be used in an editor, or the page builder it-self. Eg. all blocks are available to superuser, but other users will have only access to the defined blocks for their role combined to the restrictions of the page being edited. "I don't want to give so much freedom to my client because he will ruin the front-end" Absolutely, but is your job to lock everything. Building pre-defined blocks (speaking styles, not content (even if you should limit content)). - Give them possibility to write their article, and to add a block with three columns for 3 featured products of their webshop. So cool. - Give them possibility to write their article, and to add a banner/call-to-action newsletter. Here you limit the number of words/paragraph, whatever, then again, So cool. And IMO, it doesn't change anything at this time of writing: with or without a page builder, clients are often asking more and more. Where I see a benefit to give the user the ability to add / remove blocks from a page builder is the ease and feel when editing content - productivity in addition. It depend also on how large is the project, the client's technical background, if there is a team or not, a frontend dev on the team or not. Given this factor, you have to "educate" your client in consequence. This imple to explain to the client, how/why it can and howtonot/whynot it can. To each one his field of work and I think this particular argument should not stop any idea because it is valable for whatever special you make for a client purpose. You will have on the next weeks a preview of EditorJS which maybe will give you more idea/insight on how to work/render/restrict theses data blocks.
  18. 10 points
    That's it. I just don't want to let my clients have the freedom to play with styles, at least not within boundaries I can manage by code. It would be such a pain if I have (as accountable/developer of the project) to fix the mess made by a client inside the editor. Moreover, from my experience, if I give a client some sort of freedom (especially inside the creative side of things) then he will ask me more and more (Can I do this? Can you add this for me?). The editor become their toy, and the front-end the crappiest as ever. On the flip side of the coin I would really love if we, as developers, could have the ability to let editors manage our pre-made components in a more compelling/modern visual way.
  19. 10 points
    Recurring dates / calendar module A big +1 from me for this. A lot of sites need this kind of functionality. The key thing is solid RRULE support in a user-friendly interface. It's really common to have events that occur on a regular schedule (e.g. the first Tuesday of the month for now until eternity) but then occasionally have exceptions where the event is moved to a different day or cancelled for a particular date. The Recurme module had the right general idea but if you take a look at the source code you can see why it's not really scalable and needs a lot of tidying. A robust calendar module is not a simple thing so it would be great to have something that's built to the standard of Ryan's other Pro modules. Flexible content I find that Repeater Matrix is fine for when the content is divided into discrete conceptual and visual blocks on the frontend. It's pretty easy to make the mental connection between "conceptual/visual block on the frontend" and "Repeater Matrix item in the backend". Where it's not so good is when you have a long piece of text that is interspersed with different pieces of other content, e.g. text - image - text - graph - text - pullquote - text. In this scenario the editor/author wants to think of the text as one conceptual unit. Breaking the text across multiple Repeater Matrix items feels wrong, and it's difficult to locate and move paragraphs between the different blocks. For this scenario (which is pretty common now - think of Medium articles or other longform articles containing rich content) the Statamic Bard fieldtype looks like it nails the solution pretty well. The user wants to see a single flow of text with elements floating inside the text that represent the other pieces of content. These floating elements should reveal the content they contain (or at least the type of content) so that the user can understand what is what, but perhaps be edited outside of the text editing interface where that is more practical, e.g. click an element to edit it in a modal. I have actually made a couple of different experimental modules that expand Repeater Matrix in this direction but haven't found a fully satisfactory solution yet. Admin theme I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is. Having said that, a couple of ideas that would make it easier for those who want to tweak the admin: 1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin. 2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do... class AdminThemeFoo extends AdminThemeUikit ...the admin experience completely breaks so it's not currently a good foundation to build on. And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.
  20. 10 points
  21. 9 points
    Just my five cents (or fifty, looking at the length of this answer): There is zero interest here to move ProcessWire away from what it does now, or somehow get rid of the way it handles structured data. Absolutely zero. If you're worried that someone wants to thrash the system we now have and replace it with a Gutenberg clone, fear not: that will not happen, period. Now, as you've pointed out, there are different use cases. Almost all the sites I build and clients I work with nowadays require a "builder" approach: flexibility in terms of laying pages out. CKEditor goes to some extent here, but it's riddled with issues, and honestly the experience can be pretty horrendous: image management in particular is a lacklustre, and embedding any type of dynamic content (or anything CKEditor doesn't handle itself) gets difficult/technical (short codes with params etc.) A couple of reasons why comparing what we're doing to what WP is doing with Gutenberg makes little sense: In WordPress Gutenberg is going to replace the "classic editor", and it's also going to replace a lot of other built-in tools (such as menu management GUI) in the long term. The ultimate goal there is a "full site editor". This has very little to do with what we're discussing here. WordPress has never (natively) provided custom fields. Instead they have predefined fields and (freeform) page meta. ACF and similar plugins that make custom fields possible are popular, but page builders are even more so. It makes sense for the core team to extend the core with the tools that most users seem to want. I could get into the reasons why Gutenberg reviews are so bad — such as there being a lot of history, a lot of resistance to change, a lot of misunderstanding, likely mostly developer votes while the feature itself is aimed more at content editors, and so on — but I won't. My point is that improving the ability of ProcessWire to handle flexible layouts is not going to take anything away from those who don't want or need that. ProcessWire has many things that some users don't need or use. For an example, I've never used front-end editing for client sites. It's a feature I don't need, so I don't use it. It's as simple as that 🙂 I'm going to cherry-pick one thing from this list: "I want to protect the entire site" 🙂 I've worked on many completely non-public sites. While I believe I get the reasons @ryan has for not allowing the home page to be non-public, I would absolutely love for this to change. Even if it required a hook or config setting, that'd be a very nice addition. Currently I'm doing this with custom code, but there are some negative implications and I'm always a bit worried that it'll break: first of all it's (my) custom code and if something changes there's always a slight possibility that it won't work as expected, and second of all it needs to be done with hooks (to protect assets and make sure that nothing can interfere) and can thus sometimes get a bit complicated. TL;DR: if there was an option to somehow protect the entire site so that all non-authenticated requests (home page included) result in a login request, I'd be one happy user 🙏
  22. 9 points
    If your module has a lot of config fields you might want to divide them into groups inside a tabbed interface. Here is a demonstration module showing how this can be done. https://github.com/Toutouwai/ModuleConfigTabs Thanks to @kixe for providing my starting point in this forum topic.
  23. 9 points
    @LostKobrakai In addition to what I've mentioned above, I openly admit I'm not great at PRs, if that's what you are looking for an admission of. I try and make up for it in other areas. Nobody is perfect and one area I have work to do is getting better with PRs. I stated earlier that this is a priority for 2021. I will revisit the PRs that you mentioned. Maybe some think it looks bad to have open PRs, but to me it looks like enthusiasm, ideas and potential. I consider it an honor anytime someone would want to contribute in this way. I actually think the majority of PRs have a lot of merit and like what I see. I almost never would say "no" and close a PR in the way you are suggesting, because I almost never would feel that way. Instead, I look for the same crossover of priorities and timing that I do when it comes to adding new features. I like having a solid repo of PRs because it's stuff that is available for when the time is right and stuff I can refer back to and know someone else is also interested. All open PRs are a "yes" in my mind and just a matter of timing. Though going forward my hope is to find more time to cover open PRs even before the timing is right, since the community has indicated this would be helpful in appearances. PRs only don't age well if taken as literal code, which is not the way I work with PRs. It doesn't matter to me if the literal code has not aged well or not because it's the ideas that matter much more. Whether PRs or not, and whether my own code or not, I go through code additions line by line multiple times, often writing and re-writing, both for QA and to fully understand the logic... so I do not care about age of any particular code. I just care about the idea, getting it right and being able to support it for the long term.
  24. 9 points
    Off the top of my head if I had to name the things that are going to be — and, to be fair, have already been for some years now — potential "game changers", it'd have to be "flexible content" (as in some sort of page or site builders) and "headless" (as in native, external APIs). Neither of these is anything new, and both I believe have been mentioned here, and perhaps even existed on our roadmap in one form or another. In my experience the API part is driven largely by developer intent: there are many developers out there who prefer to work with something like JavaScript, or simply want to make a more clearly defined distinction between the data (API) and the application/front-end. WordPress has a native REST API, which (while not perfect) often gets the job done. Bolt has native REST and GraphQL APIs. And then there are all sorts of headless CMS' out there (Contentful, Strapi, Prismic, and so on) that have taken this even further, though I'm really not an expert on those myself. If ProcessWire wants to attract more developers, especially the types that enjoy working with modern technology and particularly JavaScript, this might be worth considering. Modules like AppApi and Process GraphQL have done a great job at providing an almost-out-of-the-box solution, and it's also very easy to build APIs on top of ProcessWire, but a native API would bring certain benefits that none of these solutions can do. That being said, it would also likely be a massive undertaking and would no doubt require a lot of planning: ProcesWire has a fantastic "internal" developer API, so the bar for a built-in "external" API would be pretty high 😉 As for flexible content, this is now something we use for pretty much every site we build. Unless it's a registry of predefined items (which is pretty rare), it's going to benefit from some sort of flexible content strategy. These days most content editors just can't be satisfied with "here's a CKEditor field, it works kinda like Word" — they demand quite a bit more than just that. We've been using RepeaterMatrix for this purpose and for the most part it works, but I do have to admit that it doesn't feel as slick and intuitive as some of the competition. Both Kirby and Bolt have interesting ideas in this regard, and Gutenberg is starting to look very interesting as well. Finally, a pet peeve of mine: the admin. While I really enjoy using ProcessWire's admin, there are also things I don't quite enjoy. For my taste it feels a bit overly verbose with all those lines, and when I look at the screenshots from something like Bolt, I really miss a sidebar. A proper one, one that stays in place, like the Reno theme had. I know I sound like a huge WordPress fanboy, but this is something they got right early on, and based on user feedback I'm not alone with that opinion. ... so that's one smaller-but-still-possibly-somewhat-meaningful feature I would like to see on our roadmap 😅 Now, having said all that: I know this is nothing "unique" or "groundbreaking". A lot of other systems are already doing these things. I would love to throw in an idea or two that no one has yet thought of, but honestly I think on the web today it's more about "who does it best" than "who has the most unique ideas".
  25. 9 points
    Hi @ryan - it's been a great year for the PW core - thanks for all your hard work as always and very glad to hear that pro module sales are doing so well for you! In addition to the requests repo that @Robin S mentioned, there is also of course the https://processwire.com/talk/forum/5-wishlist-roadmap/ thread. I actually think it would be best to start with the issues repo and once those are all fixed, then move onto those two requests lists. Lots of user input has gone into those lists and I'd hate to see that effort ignored or pushed aside in favor of new suggestions. I have lots of new suggestions / ideas, but I think they should wait so your efforts can focus on outstanding issues first - does that make sense?
  26. 8 points
    Wow - totally missed the discussion here!!! That's why the page-builder-part in my post in the newer news-thread was somewhat offtopic... I'll reference it here and throw it into the discussion 🙂 Let me comment wildly on some statements first - I'll try to summarize that in the end... Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. Please. No! I've done some research before starting with RockMatrix and editorjs was an option that I looked at. I decided against that approach. I can't really explain, but I had the feeling that this is some 3rd party concept and not the way ProcessWire would do content management. I had the feeling, that if we used something like editorjs we'd need to develop a totally new concept for all the content blocks. But WHY should we do that? WHY would that be better then using existing ProcessWire concepts? We have everything we need (speaking about Fieldtypes and Inputfields) and throwing that away would not be clever imho! Take a look at my matrix setup: First block is a headline - a regular PW "title" (text) field. I'm just removing the inputfield's header (we can already do such things easily via hooks!) Second block is a ckeditor field - similar, we remove the header and allow just a subset of usual ckeditor buttons. For example the image button is removed, because images are inserted via their own custom blocktype (gallery). That approach has several huge benefits that by far outweigh the drawbacks: Blocks are PW pages, this means you can do all kinds of PW magic with them. Think of hooks, think of custom page classes, think of doing listings using RockFinder (for example I'm using RockMatrix to hold invoice items having a description, an amount and a price and I can simply query all those items with a simple find call like "template=invoiceitem, year=2020") etc.; What about Multi-Language?! How would one build an editorjs field that properly reflects the internal PW multilang system?? What about file uploads? We know that files need pages and corresponding folders... We use existing, proven tools (fieldtypes/inputfields) Exactly. That's what I've built my matrix field for and that's what I need in every project. @Autofahrn has also put a lot of work into that topic! That sounds great. My matrix field does not allow nesting and showing items side-by-side or dragging dem from one block to another. But so far this has not been a problem at all! Quite the contrary. My clients love the ease of use. Even Non-Tec people can build great looking sites within no time. See these examples: https://www.kaumberg.gv.at/naturparadies-kaumberg/wanderwege/bergsiedlungsrunde/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/aerzte-therapeuten/gemeindeaerztin-dr-alexandra-hutsteiner/ https://www.kaumberg.gv.at/gemeindeamt-buergerservice/gemeinde-mitarbeiterinnen/ And using the same content blocks for a totally different topic: https://www.kaumberg.gv.at/gastlichkeit-tourismus-betriebe/betriebe-in-kaumberg/ This is SO flexible. If they needed any new content type (eg Youtube Video) I'd just add another matrix block and they could add videos everywhere on their website. I'm avoiding the PW admin more and more. I'm doing most of my work in RockMigrations nowadays, because it turns out that this often is quicker and less tedious than clicking around through the admin, replicating the changes on dev/live, rolling back changes manually etc etc.; Using migration scripts on the other hand I have my code in GIT, can just copy over parts as needed (git pull/git push), or simply use MultiCursor in my IDE to change the "columnWidth" setting of multiple fields at once (does anybody want to count the clicks necessary for changing 3 fields' columnWidth setting in the PW backend? 😁 ). I don't want to say that the PW backend is bad. Not at all. I've even wondered what @LostKobrakai is talking all the time when he showcased his migrations module back then, but I want to say that the PW backend might be really nice to have for simple use cases and beginners, but it is definitely a burden when dealing with advanced setups (think of automation, CI/CD, maybe multiple people working on one project at the same time, etc, etc). But I'm not voting for editorjs route here either! When I looked at editorjs and how plugins are built, that was a whole new world. I don't know much about all those modern javascript related dev tools and I don't really want to learn them, to be honest. Maybe that's the problem and I'm not being fair. But creating a new matrix block in my case is simply creating one single PHP file that extends \RockMatrix\Block, that's it... And I'd love to see such a setup in the core or a professionally supported one as pro module 🙂 Sounds great 🙂 This gets totally easy when using RockMigrations!! That's another reason why a solid migration system should definitely be part of the core! Everything would benefit a lot from such a core feature - module development, devs developing sites and reusing parts, etc... That would be a dream. Though I say again that I much more prefer defining things in code. Building user interfaces can be soo hard, while adding a hook can be so simple, efficient and clear. For example defining allowed blocks in RockMatrix is done like that: $wire->addHookAfter('RockMatrix::getAllowedBlocks', function($event) { $field = $event->arguments(0); $page = $event->arguments(1); if($field->name !== 'rmtest') return; $event->return->add([ '\RMDemo\Headline', '\RMDemo\Markup', ]); }); Imagine you had to build this as GUI... Sounds not too complicated, because you could use an ASMSelect field that lists all blocks and makes them selectable and sortable. But what if you'd want to show some blocks only to some special user role and hide them for others?! A simple if-statement in the hook. Nearly impossible to build as GUI... *emotional* Please, don't 😇 I've created a video that hopefully helps you all to get an impression: I think it would be helpful to clarify WHERE this discussion should happen upfront. In the forum? Via e-mail? Opening an issue (I think that's not the right place)...? But yeah... thinking about it I can imagine that monitoring all those channels is not easy and must take a lot of time...
  27. 8 points
    @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 😉.
  28. 8 points
    Oh. One more. I get that this is literally something you said you're well aware of, but I'd still like to say that I would absolutely love to see more pull requests get pulled into the core this year 🙂 This has been brought up many times over the years, but the truth is that "if ProcessWire is so good then why are only a handful of people interested in contributing" is still one of the FAQ's I ever so often find myself answering. At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. I want to be able to justify why I'm not using the most popular platform out there, and sadly it's getting harder and harder by year (and a rather low number of contributors isn't helping, at the very least).
  29. 8 points
    Since others are getting into localsied greetings, Meri Kirihimete! (Although we're actually already a day ahead and Christmas was yesterday in my part of the world.)
  30. 8 points
  31. 7 points
    @ryan and others 🙂 Sorry I'm a little late to the party. I just wanted to share my view as a designer on an update of the core default admin themes and future branding of pw in general. This is just my opinion, and I'm aware that this can be a very subjective topic. I just want to contribute to the discussion. I really like that PW gets out of the way when it comes to designing/developing a website. It's like an unopinionated frame around my projects. The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color). I wish the default admin themes and UI would act more like a neutral frame/canvas for the content. The future will probably be more about frontend stuff that gets rendered inside the backend (pagebuilders for example), so it would have less of a conflict with the frontend (that might have a lot of colors). Also I would love to have a option for a fixed header that takes less vertical space. While I know that clients love to see their logo, I don't like the Idea to do a custom branding of the backend based on the CI of the client (the client CI, logo and colors might not be working in an UI context). Instead I would prefer a solid default UI that gets out of the way. Another area where the branding and use of color gets in the way is on the showcase page of the PW website. The websites/projects presented here would benefit from a more neutral background (e.g. white, light grey, black). Imagine a museum where all the artwork from different artists and contexts, would be presented on a blue wall instead of a white wall. I recently released my own admin theme, which follows some of the ideas mentioned here. Maybe this can be an inspiration for a future default theme. Please don't take this the wrong way. I really appreciate all the work that goes into PW and this amazing community! I would love to know how others feel about this!
  32. 7 points
    Around 3yrs ago I got excited about Progressive Web Apps (PWAs) and found a site that magically created an offline experience with a few clicks. It worked until it didn't. Had to backtrack and remove the PWA code on lots of sites due mainly to exceeded offline cache storage causing problems. My JS skills weren't, and still aren't, up to the level of expertise needed to rectify. I still did the manifest.json thing, reduced the network load wherever possible and got some great Google Lighthouse performance results by tweaking PW especially with ProCache. 3yrs is a long time in web life. If 1 dog year = 7 human years, then 1 web year must be 10+ human years. I delved back into PWAs recently and Google Workbox in particular. The biggest hurdle I had to overcome was Google's own Workbox docs. Forget the "Import" statements and the CLI easy PWA method recommended in the docs. They don't (or I could not get them to) work with ProcessWire. They're geared to web apps like React that have a build process that publishes to a directory eg 'app'. ProcessWire doesn't work that way. So here's what worked for me: Create a template. I called mine "offline" that may only have one page, no children and does not have a trailing slash at the end of the URL. Create a page, add fields as necessary, eg 'body' and apply the 'offline' template and save as a child of "Home" Change the page url to 'offline.html' - this is the default page name for Workbox. Easier to change this than fiddle around overriding the Google Workbox defaults. For extra comfort, I made the page name 'Unique' and 'Hidden' from lists and searches. Ensure the workbox service worker javascript is NOT appended to the offline.html page On all other pages append the following to the <body> tag. I'm using Regions so this goes in my <region id="regFooterScripts"> in _main.php <?php if ($page->name != "offline.html") : ?> <script> if ('serviceWorker' in navigator) { let scrUrl = '<?=$pages->get('/')->httpUrl?>sw.js'; window.addEventListener('load', () => { navigator.serviceWorker.register(scrUrl, {scope: '/'}).then(registration => { console.log('Service Worker registered: ', registration) }).catch(registrationError => { console.log('Service Worker registration failed: ', registrationError) }) }) } </script> <?php endif; ?> Next, by hook or by crook, get the workbox library into a directory of your PW project. You can use the CLI 'copyLibraries' feature. See https://developers.google.com/web/tools/workbox/modules/workbox-cli for more info. Do NOT use any of the other CLI features! You can also download the library from gitHub. Didn't go there so please don't ask for help. I used the CLI method & saved the files to site/templates/scripts/workbox. Now you can start building your sw.js file which is saved in root directory. Here's mine using the Google Workbox docs & recipes. The big thing to remember is NOT to "Import" anything despite what the docs say. When you configure workbox to use your local copy of the library, all importing is done for you by using the 'workbox' namespace. importScripts('/site/templates/scripts/workbox/workbox-v6.0.2/workbox-sw.js'); workbox.setConfig({ modulePathPrefix: '/site/templates/scripts/workbox/workbox-v6.0.2/', globIgnores: ['processwire/**.*'] // change according to your PW admin URL }); // Include offline.html in the manifest workbox.precaching.precacheAndRoute([ {url: '/offline.html', revision: null } ]); workbox.routing.registerRoute( ({url}) => url.pathname.startsWith('/processwire/'), // change according to your PW admin URL new workbox.strategies.NetworkOnly() ); workbox.recipes.googleFontsCache(); workbox.recipes.pageCache(); workbox.recipes.staticResourceCache(); workbox.recipes.imageCache(); workbox.recipes.offlineFallback(); These are all the basic workbox features & recipes including offline.html and will probably need updating as time goes by. Up to you to add/modify/delete as you like and outside the scope of this tutorial. Good luck & have fun with Google Workbox PWAs in ProcessWire sites.
  33. 7 points
    I often need to explain my clients that they need to be more precice with their bug reports and explain step by step what they did and what happened. Today a friend of mine shared a link of an austrian startup that wants to help in such situations with easy on-the-go screen/audio/video recording. https://recorder.calipio.com/home What do you guys think? I could think of a "support" button in the PW backend that opens that tool and sends the link directly to me via mail as a support request...
  34. 7 points
    Hello fellow coders. Need someone to work with on a large actor hiring project. The idea is to build a website with user registrations intended for movie cast persons ONLY. A simple registration process of email/password would be required which after a confirmation would lead to an option to edit the rest of the profile and add an IMDB URL to the users Name Page. This value would not be allowed to be changed by the end user once it is saved and will be used to populate the information for the profile. The key needs of the projects will be related to using some reputable API to query IMDB (without getting banned or blacklisted by IMDB), build an internal messaging system (with new message notifications) for initial communication between registered users ONLY, have a calendar of availability for every person and an option to RATE a person ONLY IN CASE THE TWO PERSONS WORKED TOGETHER on a specific movie cast. The project could expand furthermore, so the need is for a long term developer to work with and the prices will be discussed further. Presently we own the LoginRegisterPro, FormBuilder, ProFields to facilitate creation of any forms and speed up the development. Web hosting is already set and full access will be provided for the hosted project. Not sure how long could it take for a PRO developer to achieve the project initial phase so that will be discussed further. I am presently located in Canada but can be available for any time zone location comms if a need be. The entire scope of the project is added to JIRA and will be provided to better understand the needs and all the correlations avoiding confusion throughout development. I have experience with ProcessWire so if a need/will be, can assist. Unfortunately my time and custom module skills are not yet there... Join us and let's build something beautiful to be proud of 😉
  35. 7 points
    Hey, My 2 cents on the page layout / builder : about editor.js, I see it more as a nice-looking alternative to CKEditor than something genuinely different in what it offers (apart from for the structured data) and it seems a bit limited to be a page builder more than what is already available to us. And I agree with your pros & cons @ryan. But I do think that adding some improvements to the RepeaterMatrix module, which we all seem to use as a "page builder", is a good way to go. As much as I don't want my clients to have too much freedom when it comes to the layout, I think there could be a way to introduce a "layout abstraction" into RM, something simple and limited, but that could give more flexibility. In a (distant?) way, it would be like giving the user the ability we have, as admins, to define fields' width or group them in a fieldset. I drafted some screenshots to show what I had in mind, that could be "user-friendly" (close to what @Jonathan Lahijani showed in his video). The idea would be to have "layouts" which would be described just like RM items but instead contain abstract "containers". Just like you would with fields, you could change the width of said containers, and make sure they add up to 100%. Then in the page editor where your RM is, you would have the possibility to either add a "layout" or an item. A layout and its containers would reflect the way we described them in the settings, re: width. To show that the layout is something different, we could use the secondary color. And this could be how we translate that into (hopefully not with repeating parts like mine) code: <?php foreach($page->test_matrix as $item) { if($item->type == 'matrix_layout') { // reserved type name if($item->layoutType == 'two-columns') { echo '<div class="grid">'; foreach($item->subItems as $subItem) { echo '<div class="column-1-2">'; if($subItem->type == 'type_text') { echo $subItem->text; } else if($item->type == 'type_image') { echo $subItem->image->render(); } echo '</div>'; } echo '</div>'; } } else if($item->type == 'type_text') { echo $item->text; } else if($item->type == 'type_image') { echo $item->image->render(); } } A few notes : Don't be fooled by my screenshots, I just messed around with Firefox's dev tools. To keep things simpler a layout should not contain another layout. The page editor may become too dense, even unpractical, if there is too much containers. Maybe a toggle on a container to expand it along the horizontal axis could be a solution ? End of my 2 cents. (also : I like how @bernhard is removing the field's label to gain space and I think it could be nice to have such option in the core, like "☑️ Do not display the field's label". Of course it would then remove the ability to collapse the field, but it would be a conscious choice. Edit : this is especially useful in context where you use RM and have 1-field types, like I used in my example above)
  36. 7 points
    Just adding my voice from a user perspective. I am not a coder but a very happy user of processwire. For some of my sites I use the repeater matrix apporach which was done for me by someone from the forum, great work. End of last year I decided to buy access for one year to thrivethemes.com a builder for wp, simply because my business model needs landing pages, email squeeze pages, courses, etc. etc. I get sick already with the trouble of learning how to do stuff in thrivethemes environment. Everything I built so far is far slower than what I have in pw, but for pw I need developers everytime I need something new. The guy behind thirvethemes now has 70 people working, so there is a market for this type of stuff. I much prefer what I have in the repeatermatrix pw way of doing things, and would therefore be SOOOOOOO happy if this gets taken further and I beleive if a few of you coding ninjas would build the pw version of thrivethemes, there is a market waiting to be tapped into. Just my 2 cents! Love the discussion and the talent gathered here.
  37. 7 points
    Yes, this is also what I was liking about it. I think the only thing that gave me pause is the development side of it. The plugins don't look as simple to develop as I thought they would be. At least, the learning curve there looks a bit high, and the amount of code to develop something simple seems more than I would have expected. But the same is true of developing CKEditor plugins, and none of those are deal breakers. This seems to be the nature of JS based plugin systems. I do feel like I need to find all the editor.js type options, as I'm guessing there are similar projects we should explore before picking one to build from; even if editor.js seems the most likely at the moment. Sounds awesome. I'd encourage you to release it as a module if you can. The reason I'm looking at two strategies is because I agree that the editor.js approach is great, and probably a good fit for many (or most). But there's also users like Jonathan Lahijani, where the editor.js/bard approach is not nearly powerful enough. The repeater approach does have the power, even if it's not as immediately intuitive. That's why my plan is to further develop RepeaterMatrix to better support those that want to use it as a builder, while also pursing a simpler strategy along the lines of editor.js. Does this mean that either approach is going to answer every need and interest for everybody? That's unlikely, but hopefully it'll be a good start and get the momentum going. If we were to use editor.js, then I wouldn't expect one's template code to consume JSON. We'd map the JSON to an object (or array) so that it could be used just as easily as page fields. Right, same kind in terms of what it stores. In terms of implementation, I think we are talking about 1 core direction, but 2 different directions overall. Neither direction at the expense of the other. A reasonable one that the core provides (editor.js approach or similar). And then upgrades to RepeaterMatrix for those that want to use it as a more powerful builder. So the 2nd option would simply be ProFields RepeaterMatrix, and it wouldn't even be a builder per se, but it would be ready to be used as a builder a lot more than it is now. Not flaws per se, but features that would make it better support use as a builder. That's what I'm looking to add. For a repeater matrix based builder, this would be at the discretion of the developer as to how and what they wanted to store. So in your case you might want to store something more abstract, whereas someone else might want something directly tied to their output framework. For the simpler/editor.js type builder, I don't think it would get into this type of layout thing at all. This is all true, I don't think you would be able to on the editor.js side. The elements are defined by editor.js plugins, static code. Just like CKEditor plugins. Though we'd probably bundle a lot of plugins and build some of our own. Ultimately the editor.js route will never be as powerful as the repeater route in this regard. But it will be very easy to setup and very accessible. This is something Jonathan and I discussed on our call last week. The storage behind Repeater/Matrix is overkill for the needs of a builder, so what would be ideal is if repeaters had an option to merge some of the storage needs. It's something I'm going to be looking into, though I'm not yet sure what's possible. This is basically what the new Combo field does. Though they are connected to the database, but a repeatable Combo field wouldn't require pages for storage the way Repeaters do. Nevertheless, for a builder, it seems that the underlying pages do bring a lot of benefits, even if they are overkill for the need. This is already true. But I still think the two-tier route offers the most benefits. On one side something simple like editor.js, and on the other side, something ready for more complex needs based off an existing Fieldtype like RepeaterMatrix. Also, Bernhard's solution in the other thread looked pretty great too; he said it was similar to repeaters in some fashion, also using pages from what I understand. Will do. That's true. Use ProcessWire (or any other tool) for what it has right now. You are right there are no guarantees about which features or ideas will be implemented, even for me. There have been cases where someone needed something and decided to sponsor it for the community, by hiring me or someone else in the community to build it. Outside of that, I have to find a crossover between feature requests and the needs of the projects that I work on with my clients, or with Pro modules. I can't afford to build features just for the sake of building them; I still have to find a way to fund them and then support them afterwards. The way I do that is by developing stuff that finds a balance between client needs and project needs. That way I don't have to bear all the development costs myself. The Pro modules also help to fund the core, though they also are significant projects in their own right, so I try to put much of Pro module budgets back into Pro modules themselves too. Though I put the question out there because I thought this year I could get into a couple of things that go beyond the usual development path. I'm admittedly cautious about what gets pulled in, and there's no guarantee that a PR submitted without prior discussion will ever be added. I'm also serious about supporting this project for 10, 20 years or more, so anything that gets pulled in also becomes responsibility to support it for life. The person that submits the PR does not have that responsibility. I need to make sure I fully understand and can support anything that gets pulled in. I also have to make sure it's worthwhile for the majority of users. So my preference is for PRs to be preceded by a discussion before someone creates it, so that we can evaluate needs and timing, etc. Sometimes something can be added very easily and without a lot of investment to review and understand it all, and I try to cover those once a year, or more if possible. The guidelines are here (https://github.com/processwire/processwire/blob/master/CONTRIBUTING.md) and while they do touch on this, they could go further. I will work on that. Thanks.
  38. 7 points
    👍 🤣 🏅 🥦🥕🥒🍅 🥚🥗 🍉🍎🍏🍐🍑🥑🍓🥝🍒 🏃‍♂️🧗‍♂️🕺🤸‍♂️🤽‍♂️🧘‍♂️🤹‍♂️
  39. 7 points
    I'm not sure I understand what you mean. We've got templates which define a Page's type in terms of fields, behavior and access. Then we've got custom Page classes which define a Page's type in terms of its API, which can also extend other Page classes. Then we've got Page tree/hierarchy/parents, which define their type in terms of location. I'm not sure what's left. 🙂 Is there some other kind of page type you are talking about? I will update the AdminThemeUikit repo. Unfortunately I've run into some npm error where it wants to do some kind of updates before it will update the UIkit version, but updates it wants to do in npm fail. This seems to happen every time I want to update something that uses npm, but I always eventually find a way around it. This last one has had me stuck for awhile though. I'll revisit it here soon. I've never liked these command line package installers/managers because they always seem to have some problem without a clear answer. I guess it's the nature of the beast. In this case, you've modified the core _masthead.php. Don't do that. 🙂 The intention is that an admin theme would provide its own _masthead.php file (or whatever you decide to name it). Actually I was thinking admin themes would replace all of the markup files. That's in part why they are all split out on their own. The updates added to AdminThemeUikit last week make it so that you no longer have to provide your own markup files if you don't want to, but for your case where you are changing method calls and include statements in those markup files, you'll no doubt want to have your own markup files. This gets into more overhead than I'd want to be involved for rendering the admin theme... at least for the core default one (AdminThemeUikit). I've even tried to actively avoid the traditional type of hooks here, so that the admin theme itself doesn't add its own overhead to the request. There's nothing faster than include() of a php file to render something, so that's the strategy AdminThemeUikit takes. Admin themes use a different kind of hooks for adding markup in parts of an admin theme, and they actually aren't really hooks at all, even though I still think of them as being a type of hook. You can call $adminTheme->addExtraMarkup($name, $value); to add extra markup to various parts of the admin theme. Any module or admin template code can do this any time during the request, up until the admin theme gets rendered (at the end of the request). The $value is the markup you want to add, and the $name is a region name where any one of the following are currently recognized: "head" - adds markup before </head> "masthead" - adds markup in the div#pw-mastheads "notices" - adds markup after the notices/notifications "content" - adds markup in div#pw-content-body "sidebar" - adds markup in #pw-sidebar, only if theme uses a sidebar "body" - adds markup before </body> "footer" - adds markup in footer#pw-footer This is the strategy that the admin themes use to support other modules in adding markup where necessary to the admin theme output. This is faster and simpler than using a traditional hook. More region names can be added easily if/when we need more. If developing your own admin theme, then you don't need hooks or the addExtraMarkup() function because you can already override anything in the AdminTheme you are extending, you can provide your markup files as needed, and add your own methods as needed. Admin themes should still support markup added with addExtraMarkup() though, but it's easy, just $adminTheme->renderExtraMarkup($name); at the appropriate spots in your admin theme template files. If there's anything I can add to make it easier for people to have a dashboard page, I'm happy to. But I don't currently think it should be built into the core. The core doesn't have anything worthwhile to communicate to admin users in a dashboard, so it would just be extraneous fluff (i.e. "numbers", "more numbers", and "numbers again"), like it seems to be in most systems. The kind of stuff that makes a simple system look complicated. Others may have something specific they want to communicate to their logged in users, and that's where I think it becomes worthwhile. If there's demand for it, I'd be more interested in hearing not about a dashboard, but about what one is wanting to communicate with it. Thank you for continuing to develop this. I agree there are benefits. This may be something we should keep talking about for the longer term. With the exception of WireMail, all the classes you mentioned are intended to be available for standalone use. Though it's been a long time since I've used any of PW's classes in that way. This I think is likely an easily attainable thing to support though. Most of the mentioned classes just extend the Wire class, making it the only dependency (and Wire doesn't require a DB connection). A DB connection would be needed for WireMail because it is a module type. Installed modules are known from the database modules table. A WireMail module also maintains its settings in the database. Now is is true that the base WireMail class can operate without a database, but WireMail is only useful because it is a module type. Take out the module aspect and WireMail is just an interface to PHP's mail(). The core datetime field is meant to store a single date/time, but that's it. I agree that sometimes a need arises for more than a single date/time. ProcessWire core is meant to focus on the basics, while supporting modules to accommodate a broader set of needs when they occur. I think this is a good example of a need that is nicely accommodated by a module that you've developed. Thanks for sharing the strategy you are using here. It's great to see the different solutions people are working with these last couple of weeks. From the screenshots I really like the approach you are using here. It looks powerful while easy to understand and client friendly. Yet also looks very PW familiar as well. Visually it might be the clearest I've seen, even relative to something like The Bard. The means of definition does also look simple, though I think for something that other developers would use, they might prefer that the front-end rendering be isolated from the back-end component. Something that makes it easier for you to provide pre-written components, while they provide the front-end markup. For instance, maybe the render() method delegates to a front-end template file somewhere in a subdirectory off /site/templates/fields/? And if there is not file, then maybe it provides a default output. The reason repeaters store their pages off in the admin structure is to solve these things. But it does come with its own challenges as well. Most likely I wouldn't be able to make any more commits to the core if I got run over by a train. I've always thought this was one of the reasons to use open source, ensuring that when someone smacks the tracks, the code doesn't. But it's not just about being open source, the code also has to be clean and well documented so that others can easily take it on board. That's one reason why I put so much effort into code quality and code documentation. My intention is that the code is always ready for others to understand and work with. As for commercial services/modules, it's the same risk inherent with any product or service you pay for. While not open source, the Pro modules do have the same code quality and documentation as the core, and are not obfuscated or encrypted. If it sets your mind at ease, I'm 46 years old (not 76), and am very healthy. I run and lift every day, eat lots of salads, don't eat red meat, and don't participate in any dangerous activities. Most likely I'll be here for at least another 46 years. But if I'm ever derailed then I know the project would still be in good hands. Seems like it might be simple to do. Can you expand on this? When/where would you use it?
  40. 7 points
    First of all I want to say, that I am really enjoying the discussion about the flexible content builder or the WHATEVER-builder (as I accidentally named it earlier) we are having here. And now I am purposely not calling it more specifically Site / Content / Page / Layout / Theme Builder. I think that @kongondo made a really wise question asking to define the distinction between those. And to determine, what exactly do we want to build. Are we really talking about the different things? It seems to me that now we are contrasting the YOOtheme Builder from @Jonathan Lahijani‘s epic video labeling it as a layout editor or a site builder, to bard / editor.js calling them content block editor or something like that. And choosing between the two. But, as I understand, @Jonathan Lahijani never proposed a layout editor / site builder way in a sense that it should store the final html code and let the content editor to directly manipulate it. He intentionally made it clear, that he chose to show us YOOtheme builder because it “separates the builder-part from the actual content” doing it in a “ProcessWire way”. And he also stated, that he is not for tightly coupling to the CSS framework (Uikit in YOOtheme). But he would want the ability to define the layout IN SOME WAY, like being able to create a 2/3/4 column grid and place the components (I think that they are the same as content blocks from bard / editor.js) inside those columns. And to be able to move those components to desired slot in the layout. I would really want that part too) I think that the earlier mentioned “ProcessWire way” is actually the separation of content and presentation. When we use Repeater Matrix, we store the content and some meta information not directly in the html code, but in the Repeater Matrix Page’s fields. Actually, editor.js (do not know about the bard field, but probably that one too) is also storing the content separately from the presentation. Not in the separate database tables, but in one json object. So it is kind of doing it the “ProcessWire” way too))) One difference, is that in the case of editor.js we have to manually deal with json when generating actual markup, when Repeater Matrix provides us the comfortable PW API for that (making this way a little bit more ProcessWire). The other difference is that when using Repeater Matrix we have to manually create all the actual fields and assign them to content types, making this way more laborious. The coin has two sides. So, as I can tell, we all want the same kind of editor. The one that does not store the actual markup, but the one that stores data, that later we can render to actual html (or any other format really). What about the layout part? As I said earlier, I would really want to have the ability to define layout with the flexible content builder we are talking about. @Jonathan Lahijani showed 3 ways of doing it in current Repeater Matrix-based content builder, and all of them are kind of a pain. But I do not want our editor to actually store something like col-sm-6, but rather some generic layout information. Like having a grid block, that can only have col block as a child, which in it’s turn can store the actual components. In Repeater Matrix now we do not have a distinction between layout element and a component. We only have the ability to put one element inside the other (the ugly nested Repeater Matrix way or the repeater depth way which also has its flaws). But it is the developer who is responsible to make all the decisions generating markup. So the developer could choose to implement the layout part or not to do so, which is really a powerful stuff I enjoy and would like to keep. That’s why I was talking about the “WHATEVER-builder” or a “framework for constructing a content builder” before. To do so, our new flexible content builder should allow us to: define the allowed parents/children for the elements; allow to show the child elements side by side (to imitate layout); intelligently control the drag and drop, taking into account the allowed parents/children for the elements. As far as I know, editor.js does not allow the nesting of the elements. Creating custom elements from admin The other great thing about the Repeater Matrix-based content builders is that we can easily create new custom content types (elements, components…) right in the comfort of the admin. It is not really a quick thing, as we need to deal with creating the fields and assigning them, but it is rather familiar. And those custom components can use all the other ProcessWire data with Page Reference fields, Selector fields etc, which is cool. If we go with with editor.js, I am in real doubt we would be able to create the new elements in admin. The dev would probably need to develop a js plugin and install it in non-PW-standard way, making it unlikely to happen. The connection to other Processwire content from that custom element would be even harder to implement. Visual representation of the content Repeater Matrix-based flexible content builders in the mentioned video look nothing like the actual content. The left part of YOOtheme builder does neither, but it at least represent the layout in some way. Editor.js / bard do not do that too. From the other replies in this thread I see, that it is not that important and even not desirable. Repeater Matrix interface is kind of ugly, when representing content. But: at least is is familiar and in line with all the other backend; it could be improved to be more like YOOtheme builder: add icons for adding content types, remove or refactor the repeater elements “chrome”, allow showing repeater elements side by side for the layout thing; and it uses the standard admin form ui, which means it is easier for @ryan to deal with. As you see, I am for the native ProcessWire UI here) And one more thing. In the video we see the actual markup rendered to the right of the YOOtheme content editor. We can do that also, creatively reloading THE WHOLE PAGE on changes with Hotwire / Unpoly / Vue. Making the flexible content builder feel dynamic and not requiring those saves-and-reloads. And making the connections between the options in the builder part and the final markup obvious to the editor. The data storage Repeater Matrix-based flexible content builders store the data in pages and fields. This makes it laborious to create new content types (create a new field, or find an existing one to reuse it, assign it, override it…) This also makes it hard to duplicate, copy/paste content in the site or between the projects. But it also allows us to use the familiar API when generating markup. Editor.js’ data object is compact and probably easier to be reused. But it lacks connection to other PW data. And the UI is totally different. Could we combine the benefits of the two? What if we invent the json-based storage for the data gathered with regular ProcessWire inputfields? Something like Mystique field combined with JsonNativeField (so the content is even searchable). And what if we allow to create the Interface for the new flexible content builders components with “fake” fields, which have their inputfields only, and are not connected to the database? Kind of like fields for the Form Builder or the UI for the @adrian’s Admin Actions’ actions. Think about that. We could design elements with any fields we need not messing up the regular fields namespace. Those fields’ definitions would be stored in our flexible content builder’s options, as well as all the content types (elements) and the actual field data in json. The UI would be the same inputfields we already have. When working with this field from the API, the field could be accessible as a PageArray object where each Page is a corresponding element. Bringing it all together I think it is possible to build the flexible content builder (or the WHATEVER-builder) using a lot of the technology we already have in PW. It can be comparable if not better than all the other competition. It can be well integrated and totally configurable through the admin. It can be portable between templates and projects. And it can be visual and responsive. What do you think?
  41. 7 points
    RockMatrix --> thats a modules similar to RepeaterMatrix. When a matrix item is created, a meta entry stores the reference to the page, where the matrix item lives on. That's similar to the TrelloWire example 🙂 RockMeta --> that are fields for the PW backend that do not store their value in their own DB table but in page meta-data. This is great, because I can add Inputfields to existing Inputfields to make them more flexible without having to create many fields in the system.
  42. 7 points
    My module TrelloWire module uses $page->meta as an easy, site-independent way to associate module data with a page. The module creates Trello cards for new pages, and can update them through Trello's API whenever the page is changed. To do this, the module needs to store the ID of the card associated with that page somewhere. Using $page->meta was the easiest option, much simpler than creating a custom database table or programmatically creating a field when the module is installed. The caveat is that the value can't be updated or deleted through the user interface. However, that could be achieved through hooks. You can see how I store and use the page meta data in TrelloWire::createCardForPage and TrelloWire::buildCardData 🙂
  43. 7 points
    @Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this: File: /site/modules/AdminThemeTest/AdminThemeTest.module <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } } You'll also need this file in the same directory: File: /site/modules/AdminThemeTest/controller.php <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); require($config->paths->core . "admin.php"); The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though): <?php namespace ProcessWire; class AdminThemeTest extends AdminThemeUikit { public static function getModuleInfo() { return array( 'title' => 'Test Admin', 'version' => 1, 'summary' => 'Test extending Uikit admin theme', 'autoload' => 'template=admin', 'requires' => 'AdminThemeUikit', ); } public function renderExtraMarkup($for) { $out = parent::renderExtraMarkup($for); if($for === 'head') { $out .= "<style type='text/css'>" . "#pw-content-head h1 { font-size: 24px }" . "</style>"; } return $out; } }
  44. 7 points
    Regarding @teppo's suggestion about a native external API - I know that we just lost one PW website to a JSON / GraphQL / Gatsby / React stack because the developer decided that was easier to do that than use GraphQL / Gatsby / React on top of PW. Personally I think his decision was misguided because now he is managing content in json files (he is the sole dev / content editor so he doesn't need an admin CMS), but I think he'd have done much better using PW for content management and generating JSON that can be pulled into the frontend. But maybe if PW had a native way of doing this, he might have stuck around and I am sure there are lots of other devs out there that ignore PW simple because they don't think it will let them use these modern frontend stacks. I do think an integrated javascript API would make lots of things much easier as it always feels a bit hacky to me getting PW data into JS - it would be great to have JS page object available on page load, but also to have a built in AJAX method to pull other PW data on demand. I do feel like we need to convince potential developers that PHP can work together with the rest of the tools they want to use - they don't need to use Node to integrate things. I am still baffled that companies are paying thousands of dollars a month for things like Contentful or ContentStack when PW can essentially do the same thing - I know there are other benefits to these services, but I find the downsides not worth the tradeoff. There are of course self-hosted headless CMSes out there, like https://strapi.io/ which has been around since the end of 2015 and has 32,000 Github stars and 600 contributors. I know you have constantly maintained that you don't care about popularity, but clients often do, and with good reason - they need to know that there are other developers out there to take over if needed. The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice. One thing I would like to see is a way to easily implement certain admin forms in the frontend - yes we can do this with the API, but having all the admin tools available in the frontend would have saved me a lot of time over the years essentially rebuilding functionality. Sometimes I can get away with the AdminBar module, but it's not always appropriate. If you want an idea for another profield, a properly working version of a recurring dates field would be awesome. Unfortunately the Recurme module just isn't a viable option - I do have it running in production, but it's not efficient and I have several hacky fixes in place. It's actually a difficult problem doing recurring dates well, but it is a common need for lots of sites and so a good implementation would be very popular. However, my biggest concern and bugbear has always been what some might consider little things, but these "little things" can sometimes cause lots of frustration - things like: https://github.com/processwire/processwire-issues/issues/550 - there are lots of other examples of these sorts of things that require hacky workarounds. It is much more important to me to find proper solutions for these than adding fancy new features. I'd also like to see the admin user interface tightened up - there are lots of areas for improvement and so this is just one silly example, but having the double-click to open/close all repeater items on the on/off toggle button is confusing and I think needs fixing. I have converted a local web dev agency to be exclusively PW (from Drupal), but whenever we chat, their main complaint is always the look of the admin - they feel it doesn't look modern and clean enough and makes PW look a bit cartoonish. Please don't take that as a personal insult - getting this right is difficult and in my mind take a very talented design person to get the details right - I can see the things that are jarring, but I am not good at figuring out how to make them right. I think this is really important in ensuring that PW continues to be something that we can convince clients is a modern platform. I do also think that the interface to RepeaterMatrix could be modernized. I am not a huge fan of fancy website builders, but I do think we need to find a middle ground between what RepeaterMatrix currently provides and the best of the new building tools out there, because eventually clients will complain that they don't have access to the shiny new tools - it hasn't happened to me yet, but I think that's partly because of the type of clients I typically have.
  45. 7 points
    @ryan Maybe also some Point to start: The Open Pull Requests: https://github.com/processwire/processwire/pulls
  46. 6 points
    Just in case you don't know, you can do this via the parent page template's Family tab > Sort settings for children This is possible with the AdminOnSteroids module's AddNewChildFirst option which allows you to maintain manual sorting, but automatically putting new pages on top. BTW - not suggesting that something like this shouldn't be in the core - just hoping to help you out with a solution now.
  47. 6 points
    A lot to agree with here 👍🙂 One thing I particularly liked about editor.js is how it keeps content separate from design: behind the scenes everything is abstracted so that a quote block is really just an object with a few text properties, etc. You could render that quote block in a hundred different ways for the front-end. Portable indeed 🙂 In fact the more I think of it, the less sense it makes to think of block editors as something that would replace pages and fields. I'm all about having content split into separate fields where it makes sense. But as a replacement for RTEs, that's something I can definitely get behind: an RTE is a decent tool for creating text-only content, while for anything beyond that I find them rather awkward. For "body content" (which may these days typically be a varying mixture of text, images, tables, forms, highlights, and so on) flexible content fields are (imho) a much better choice.
  48. 6 points
    Below are the style overrides that I apply, mostly just spacing changes and fixes for things that looked off to me. There might be one or two things in there that don't make sense out of context because I'm also loading some custom JS to change the icon of the "user" menu and have the primary link be to the site frontend rather than the user profile. The problem is that if you create the minimal module that extends AdminThemeUikit (i.e. just the class declaration and the getModuleInfo method) then what you want to see is everything displaying as per AdminThemeUikit. Then you would add custom CSS/JS and override any AdminThemeUikit/AdminThemeFramework methods as needed. But what you actually see is this: If that is expected then it would be helpful to have some documentation or a blog post about how to go about extending AdminThemeUikit, or what file structure is needed for a full custom admin theme if anybody is game enough to try that. The only hookable methods that I can see are AdminThemeUikit:renderBreadcrumbs and AdminThemeFramework::getUserNavArray. So for the thing I mentioned (manipulating menus) you can only customise the "user" menu. It's not possible to dynamically add items to the Pages, Setup, Modules or Access menus without resorting to JS hacks like AdminOnSteroids does. And on the topic of the admin menus, the caching is a bit of a pain and doesn't measurably improve performance according to my tests: https://github.com/processwire/processwire-requests/issues/268#issuecomment-464200684 Another menu related request: https://github.com/processwire/processwire-requests/issues/189 What would be great is if for each major part of the admin theme layout (e.g. header, menus, top of content, bottom of content, footer) there was some hookable method so it was possible to inject custom markup at those points.
  49. 6 points
    З Різдвом Христовим!
  50. 6 points
    Here is a nice alternative: https://kenwheeler.github.io/cash/
×
×
  • Create New...