kongondo

@Gideon So, Please correct your code. It is broken in several places (missing braces, etc.). For instance: Here you close </li> early, before its children (nested ul). I think you meant $pages->get(1) ?.

Unfortunately, we cannot get a way from a full page refresh no matter how desirable a partial refresh is. htmx deals with selectors, to find the element(s) to swap. It would be very onerous for ProcessWire to read through a template's code to find the element to swap. This means this: <div hx-get="/some-url" hx-trigger="some_event" hx-target="#body" > </div> OR this.. <div hx-get="/some-url" hx-trigger="some_event" hx-target=".body" > </div> What @ryanis suggesting is that the target for htmx can be read from the GET variable. Whilst this might work for simpler cases, and it is a nice idea, the fact is there are myriad ways for building templates. What about fields that are split into various fragments on the page, how do we update those? What about the concatenated ones? This also means developers need to code for the live preview and in a certain way. Having said that, htmx has hx-vals. <div hx-get="/example" hx-vals='{"myVal": "My Value"}'>Get Some HTML, Including A Value in the Request</div> OK, that might work. This would tell ProcessWire if this changes, give me the changed values for 'myVal'. All these lead nicely to the next headache. What happens when your site goes live? It means you have to delete all those hx-attributes as you only needed them for live preview. Just playing devil's advocate here ?. If live preview was about rendering an Inputfield's content, that's easy. We would let individual Inputfields' __render()s handle it. I am using this quite a lot with partial updates (i.e., only those bits that have changed). However, if it is about previewing the site, how it would appear when rendered on the frontend, then the many difficulties of adapting to a developer's code in their template files make partial updates quite difficult, if not impossible.

There's lots of use cases mainly related to module development as well as internal ProcessWire use. You can also use it (with caution) for housekeeping. Let's say you created a number of fields for testing purposes on a site or module you are working on. You gave your fields a specific prefix to easily identify them as test fields, for instance. You now want to delete them. They are not in use in any template. There are a lot of them. Instead of deleting them manually, you can use the API to do it for you. <?php namespace ProcessWire; // get your 'test' fields // their names start with 'test', e.g. 'test_some_field' $testFields = $fields->find("name^=test"); d($testFields,'TEST FIELDS'); foreach($testFields as $testField){ $fields->delete($testField); } Run that in Tracy console and you are done.

Yes. Using Ajax. There are many way to send an Ajax request to the server: vanilla JavaScript, jQuery (?), Axios, htmx ?...etc. A workflow like this maybe: Create buttons of type 'button' - to avoid them submitting the form normally. Choose the client-side library (or pure JS) that will to talk to the server. Listen to the click events on the buttons. I would probably toggle the buttons. User clicks on I am here: this sends an ajax request to your server. Create a session (or if you wanted, a cookie) to 'register' the user's presence. Populate your log-page. Send back a response to client, toggling the I am here button to a I am out button. This would be trivial if using htmx. User leaves: delete their session in #6. Amend your log-page. If stream still continuing, show I am here button. Stream ends: clear all sessions from #6. Something along those lines, assuming I understood your question ?.

Hi @howsoonisnow90. Welcome to ProcessWire and the forums ?. Not directly related to your question, but you will want to rename your field. ProcessWire uses and prefers lowercase letters for field names. So, viaggi_gallery. Yes and yes. Your viaggi_gallery field is most likely an image field that accepts and outputs multiple images. So, when you do an echo $pages->get('your_field') you are actually telling ProcessWire to output a whole collection of images and it is asking you which one? There are a number of images in here. Secondly, you need to specify what property of the object you want it to out. Maybe an object->url, or object->description, etc. This is just a toString() method kicking in. <?php namespace ProcessWire; $out = ""; // --------- $out .= "<ul>"; foreach($page->viaggi_gallery as $image){ // foreach($page->get('viaggi_gallery') as $image){// would also work // most likely you want a thumb so create one // processwire will only create this if one is not already available // $thumb = $image->size(200,200); // if you want to specify height only and let width be automatically determined $thumb = $image->height(200); $out .= "<li><a href='{$image->url}'><img src="{$thumb->url}" alt="{$image->description}"></a></li>"; } // ----- $out .= "</ul>"; echo $out; Have a look the documentation and the getting started tutorials. https://processwire.com/api/ref/pageimages/ https://processwire.com/api/ref/pageimage/ https://processwire.com/docs/tutorials/ ps: written in browser; please check for errors.

One of the many reasons I like htmx. It reminds me of ProcessWire a lot. Out of the box all it does is give you the necessary tools then stays out of your way. Even the author, for some reason, reminds me of Ryan ?.

After releasing Padloper 2, I'd like to give this (and others) module some attention. Any ideas on how it could be improved (UI, etc), please note them here. Thanks.

Update: Blog 2.4.6 Changelog Fixed fatal error when installing Blog (thanks @Orodreth , @lele_ballack and @Sascha Nos for reporting. Various other minor fixes. Please test and let me know. Thanks. PS: Not sure when it will propagate in the modules directory. I couldn't log in to force a re-trigger as I seem to have forgotten my password for that area ?.

I am happy to help in this regard in any way I can.

Just cross-referencing this announcement/call for testers here:

In preparation for testing of the initial (alpha/early beta) release of Padloper 2, I would like to gather expressions of interest. In the past, some of you expressed a willingness to help with testing. It has been many days since and your position might have changed. In addition, I would like to do this in an organised manner so we cover as much ground as possible. The grounds I’d like to cover are usability and technical aspects with a bias towards the latter. Please also note that there are a number of planned features that will follow the initial release. Hence, we shouldn’t focus much on those. These and similar thoughts will be added to a planned features list (more on this below). The main focus of this testing is to make Padloper 2 production-ready. In order to properly organise this testing, I will need to gather some information from you. I will be doing this via Google Forms. The most important detail will be your email address. I will need this in order to inform you how to access Padloper 2 as well as for other necessary communication. I will not use your email address for any other purposes nor pass it to any third-party ?. Other information to be captured in the form would be what areas of testing you will you want to be involved in and your preference for planned features (since I will need to prioritise them). Forms are better than plain emails in this respect. Please note the following if you wish to be involved in the testing programme: Pricing and subscription will follow the model I have previously stated (similar to ProcessWire Pro Modules). However, for the testing programme, your subscription period will NOT start counting down until after the production-ready release. You will still also have VIP support (please note the nature and location of this may change). To be fair to other testers, anyone joining the programme needs to actually spend time testing the product. If you won’t have time to do this, please wait for the production release. This initial release is NOT a production release. Although it may work for some in that regard, it will not be tagged as production-ready (hence the alpha tag). Licences will be the usual three: (i) Basic/Single Site Licence, (ii) Developer Licence and (iii) Agency Licence. I can explain the different between these three if anyone needs clarity. The initial release will have the introductory prices of €150, €300, €900 for single, developer and agency licences respectively. Cooling period will be 14 days (within which a full refund can be requested, no questions asked). Please note that this time period may change for the production release. Here is the link to the Google Form to express your interest in the testing programme. The form will close in 10 days. Many thanks for your patience. Hope to see you soon in the testing programme. I trust you will enjoy Padloper 2 as much as I have had the pleasure (and honour) of developing it ?.

I fixed some typos in my code, by the way, in case you didn't see them ?.

@horstbeat me to it ?. Two options: Option 1: substr() https://www.php.net/releases/8.0/en.php (+ trim() only if needed) edit. <?php namespace ProcessWire; $originalString = '01 - Category1'; // will remove the space after 01 - for you as well $str = substr($originalString, 5); // debug // d($str,'substr'); Option 2: array explode() + trim() <?php namespace ProcessWire; $originalString = '01 - Category1'; // explode the string on the hyphen ('-') // this creates an array $str2Array = explode("-",$originalString); // our string is in the second position // we get it and remove spaces on each side $str2 = trim($str2Array[1]); // debug // d($str2Array,'$str2Array'); // d($str2,'str2');

I don't think this is right. My runtime Fieldtype is based off Ryan's Concatenate Fieldtype and that does not create a DB table. See also his comments in the code, e.g. this one. No database table is necessary.

Been getting a similar error on a custom runtime module. Only way around it is to specify a field/fields to fetch as in your example.

Just a comment on the code (not the necessity or rationale of it): A find in any context will always return a collection. In this case, a RepeaterPageArray. You cannot directly apply an action such as status to a whole collection. Although your code might have returned a result whose count is 1 (your 1043 item), it is still a collection. I.e., your 1043-item is in the collection RepeaterPageArray. So, your choices are: use get(1043), in order NOT to return a collection (e.g. RepeaterPage) or grab the first item in the collection, i.e. find(1043)->first(). Ideally, you should be checking that your get() returned something before apply an action to it. Otherwise, you might end up with a 'call to member function addStatus on null' error.

Ladies and gentlemen. You have been waiting for a very long time. I am happy to say we are almost there. I am fixing a few loose ends in readiness for the launch. I will create a new thread outlining the way forward with alpha (early beta) testing later this week (barring any show stoppers) or next week at the latest. Thanks.

I have no idea ?. I have never used Form Builder. Does Form Builder work with custom fields? Honestly, I don't know how it works.

You are up late @Jonathan Lahijani ?. Thanks for the tutorial!

Only if the keys are strings ?...which they probably are in this case.

I get you. Commit's don't always increment the version though ?. When Ryan bumps the version he'll clearly state that in the commit.

The feature was committed some 20 hours ago. Maybe you downloaded your version earlier than that?

https://github.com/processwire/processwire/tree/dev Welcome, @vangeesonto ProcessWire and the forums ?.

<ot> A few months ago, a Google search for htmx "whatever" would invariably throw up 'Did you mean: html "whatever"?'. Those have since reduced. Even the Google AI is getting better acquainted with this new technology ?. </ot>

Glad you've at least isolated the cause of the problem. If you find a solution, please let me know if there's anything I need to do on MM side. Thanks.