kongondo

Hi @Marvin, Sorry, I missed your post. It's difficult to tell what's going on because I am not sure what type of fields you are using, e.g. are they actual images of images in file fields. Maybe try the below outside your code, just to test. This assumes you have a field called 'images' and it allows multiple images. // Example of outputting a thumbnail gallery of Pageimage objects foreach($page->images as $image) { // $image and $thumb are both Pageimage objects $thumb = $image->size(200, 200); echo "<a href='$image->url'>"; echo "<img src='$thumb->url' alt='$image->description' />"; echo "</a>"; } Do you get the correct output with resized images? Do you get any errors? If so, which ones?

I can't recall whether it was this topic or another one but I remember someone asking where best to discuss issues/wish list, etc? In case you missed it, @ryan, I would like to bring GitHub Discussions to your attention. Maybe something worth considering.

Definitely ?. This was for demo purposes only. My plan is to develop my own using Affinity Designer...at least the easier ones. However, I don't know how much different I could make them look compared to YOOTheme's. Thanks. Will have a look. By the way, I have been keeping an eye on this one: https://heroicons.com/ ...by the folks at TailwindCSS

Nope ?. This is all handcrafted using Vue JS + TailwindCSS + custom JS + some drag and drop library. I sometimes use vanilla JS for drag and drop but didn't this time. I have never used grapejs. You are wrong in your assumption ?..., at least in the context of what I am developing here. We are managing content; we are just not using "traditional ProcessWire inputfield interfaces". The app runs in __render() method of the inputfield. Saving is via ajax but that can be changed to form submissions with page reload if one wanted to (not that I would want to do that myself). All my responses below are with respect to this Page Builder. Wrong again. Jessica White's data actually lives in the database. Still wrong. Jessica's marital (or any other of her attributes) status lives in the database. It is retrievable via the API and editable in the app GUI...all the CRUD goodies. You update it once and it is reflected everywhere that data is used, both live as you are editing and once you save your edits. That's what is happening in this builder as well. You can choose anything. Literally, anything from the system. It's just a matter of requesting it via the API and getting back a response from the server ?. It's not shown in my demo but you can even do Page Reference fields. All data requests by the App request are vetted on the ProcessWire side (permissions, validation, sanitising, etc). Neither have I but it looks like your brief experience with it wasn't great? Maybe it was a misconception? A quick Google search tells me grapejs can work with a database backend. We can and we do....? Examples include Padloper 2, this Page Builder and other Vue JS apps I have built (unreleased). By smart content I assume you mean data stored in the database, be it in ProcessWire fields or custom tables. All the data you see in the demo of this Page Builder are stored in ProcessWire tables (Fieldtypes). You can access this data using the API and carry out any CRUD task using the usual ProcessWire API.

Hi @teppo. This is a holding response since I am short of time at the moment. You've raised an important issue surrounding funding of modules/remunerating developers, etc that I have been meaning to discuss in the beer garden with the whole community. As it is a broad issue, I would like to answer this question within that broader context. As for this module in particular, I haven't decided yet but leaning toward commercial. That's not cast in stone though given the broader issues I'd like to discuss. I had a feeling this would cause some confusion. I will come back with a detailed answer. For now, just note that schema is used in the sense of defining something, in this case, a column in a DB table containing JSON with the schema/description of that element with respect to layout, tags, etc. Hope I haven't confused you further. Excellent! Thanks.

Hey @Marvin, Welcome to ProcessWire and the forums. It looks like your are dealing with multiple images. You need to resize them individually in your code. Something like this: <?php $num = 1; foreach($pages->get("/files/")->children as $child) { $current = $child === $page ? " class='current'" : ''; $images = $child->images; // $images->width(900); // $images->height(100); foreach($images as $image){ foreach($pages->get($child->name)->files as $file) { // $file = $child->files; // echo $file->name; // ---> RESIZE SINGLE IMAGE <--- // $imageThumb = $image->size(200,200); $imageThumb = $image->width(900); echo "<tr><td>".$num++.".</td><td>".$child->title."</td><td>".$child->text_1."</td><td>".$child->text_2."</td><td>".$child->text_3."</td><td><a href='".$file->httpUrl."'>".$file->name."</a></td><td><img src='".$imageThumb->url."'></td></tr>"; } } } ?> See the docs here: https://processwire.com/api/ref/pageimage/

Thanks Jonathan. I'll be in touch soon.

Here you go...took longer than planned.

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..)

Hi @flydev ??, I haven't made a firm decision yet but it may not be ready before the launch.

Hi @StanLindsey, I haven't seen that one before :-). Could you please tell me more about what's on that template? Assuming you have TD installed, could you please tell me/show me the output of the following? Please add the following debug calls: <?php // around line #369 in the method ___render() in InputfieldMediaManager.module bd($this->mediaManagerField, 'MEDIA MANAGER FIELD'); // around line #38 in the method __construct() in MediaManagerRender.php bd($mediaManagerField,'MEDIA MANAGER FIELD'); edit: What's the name of your Media Manager Field? Is it all lower_case? Thanks.

@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 ?.

@flydev ??, Sorry to tag you like this. I am not sure if you are following the discussion here regarding content blocks? Just wondering how far you are from releasing your Editor.js-based Fieldtype? Given that you've probably spent months developing the module, I'd be interested to hear what your thoughts are.

Thanks for the defs @Jonathan Lahijani I'll see if I can set myself a challenge to build a basic clone of this this weekend ?.

Same here with Hotwire. I watched 4 different videos and I still couldn't get it. Site / Content / Page / Theme Builder Are these four really synonymous? I am not an expert, not at all. However, we seem to be using these terms interchangeably, meaning perhaps we are not on the same page? Could someone please explain the differences? @Jonathan Lahijani?

No. That date has not yet been set :-).

I see your point. However, it doesn't need to be an SPA. Webpack is a pain to configure, although there are various approachable alternatives out there.

This is very much doable using Vue JS. It is a progressive framework. You can use it with your existing HTML ,sprinkling in as much or as little of Vue reactiveness as you need.

Btw, @Jonathan Lahijani, making content editable versus non-editable as per your comment in the video is 'quite easy' to do with reactive frameworks. You can even make this configurable if you wanted.

Sure, but to some extent, we have been locking ourselves to the future of some technologies for decades - PHP, MySQL, jQuery. This is not necessarily a bad thing. It depends on the maturity of the technology, I suppose. Sometimes it depends on the needs of the users of the tool you are providing, for instance, Bootstrap 5 removed dependency on jQuery having been 'locked' in for at least a decade, I reckon. GitHub did the same. Sorry, my examples are all jQuery-related - it is just a coincidence ?.

Ha! Great minds! ??. I just beat you to it ?.

Thanks for the very insightful video @Jonathan Lahijani Flexible Content / Page Builders When it comes to this, if you look at what's out there, in many cases, you'll invariably end up in either of two places with respect to the technology behind the builders; Vue JS or React. A few examples: Statamic - Vue JS Gutenburg - React YOOtheme Pro's Builder - Vue JS Storyblok - Vue JS There is ?. It is called Vue JS (I prefer it over React). OK, there is no ready made tool solution but from my experience developing Padloper 2, I can say it is quite doable. If we are to build any sort of page/site builder, I'd highly suggest to look at either Vue or React - especially Vue. It will save you a lot of hassle. The biggest challenge I found with these frameworks if using the CLI versions (recommended) is that the 'app' has to be developed outside ProcessWire as they run on different ports. This means the app has to be 'built' in order to test it inside ProcessWire. This is a tedious process. I have never been able to develop a Vue app inside ProcessWire and still get the benefit of Hot Reloading. If we end up using Vue JS (or even React), then perhaps we need to pay a visit to our old friend jQuery (and its siblings - UI) to plan for their retirement? ?. It wouldn't make sense to have both. Even if we didn't end up with Vue, modern JavaScript has some great APIs that can replace the dependency on jQuery. I know this is a huge undertaking. I know both the modern and the old have their pros and cons. I also know that jQuery is not evil. I know the decision to use it or not can be subjective. I just prefer working with reactive frameworks (and vanilla JS). What do you guys think? @ryan, would modern JavaScript tools fit into this vision?

Happy to help :-). Glad you sorted it out.

Assuming I understood the question...one way to do it: <?php namespace ProcessWire; // init empty string to store markup output $out = ""; $events = $pages->find('template=calendar-post, limit=5, Start_date|End_date>=today, sort=Start_date'); // we found events if($events->count()){ $out .="<h2>My Header for events</h2>"; // my events code! // start list - just an example $out .= "<ul>"; foreach($events as $single) { $out .= "<li>{$single->title}</li>"; } // close the list $out .= "</ul>"; } // use this if you need to show 'no events info' else { $out .= "<div>There are no events at the moment!</div>"; } echo $out; Please note, I haven't checked the validity of your selector.

This will not work with PHP, so no ProcessWire if that was your intention.