modifiedcontent

Very interesting/cool, but 'Htmx is a dependency-free, browser-oriented javascript library'. Is this really more efficient than jQuery or plain js? Does this leverage ProcessWire; is this the best PW-native solution? I have implemented this solution here in my sites and have to move on to other things to finish before the new year. I'll keep an eye on Htmx - it's The Future apparently... - and maybe implement this next Christmas. ?

I had a working version in my previous comment, but can't get PW $posts array to play nice with the rest of the script; I have to convert PW $posts to another $posts_array and then echo with the `$post['title']` syntax to make it work - why? what am I getting wrong? That works OK if you only want to show one or two fields, like `$post->title`, but obviously not if you want to do more complicated stuff. So I'm trying another approach. I first grab a batch of IDs with $pages->findIDs() and then use those to lazy load each entire object as they are needed scrolling down the page. Should be a very efficient approach, right? Or not? I had trouble echoing the IDs with $post->id or $post['id'] or whatever, but apparently $post alone works with this simple one-dimensional array (?) - it's like all clever and stuff... This works ? : Let me know if you see problems, possible improvements, bits that can be replaced with PW methods, etc.

Finally got the demo working in a PW template testpage.php: I'll replace this step by step with PW native stuff and other updates. I see I can't simply replace the hardcoded demo $posts array with `$posts = $pages->find("template=video, limit='12', sort=-date");`. I guess I need `"id" => "1"`, "id" => "2"`, etc. or rewrite something somewhere? Or JSON encode $posts? Why does $posts from $pages->find() not work when the manual/hardcoded $posts array from the demo works fine? I see the PW $posts array starts with the following: ProcessWire\PageArray Object ( [count] => 12 [total] => 118 [start] => 0 [limit] => 12 [pager] => 1 to 12 of 118 [items] => Array ( [Page:0] => Array ( [id] => 7457 [... etc. So there is the built-in pagination stuff. How can I work with that? I don't want "12 items per page". I want to grab a bunch of items and then add those to the page 1 by 1 (or 2) as you scroll and they come into view. How can I make $posts from PW behave like the demo script? This works, but it is not the PW way: It only works with `echo $post['title'];` in the output, not `echo $post->title;`. Why? But this does what I need, so I'll use this in my sites after further clean-up and updates. Are there bits that could easily be replaced with PW equivalents? Do you see obvious problems/downsides? Any other suggestions how to improve this much appreciated. I don't understand what `<input type=hidden id=currentquery value="" />` does, but removing it breaks the script... It looks hacky. Is there a better way to do whatever it does? ? I guess the syntax `$limit = isset($_GET['limit']) ? $_GET['limit'] : 2;` doesn't work within PW and I should use `$input->get('limit')` with `if ... else` instead?

Thanks again @gebeer. I am now puzzling with `if($config->ajax) { ...` - I have used Ajax elsewhere in my PW sites, but only with POST form data, not GET. Yes, I would prefer to use ProcessWire built-in methods. As long as PaginatedArray doesn't require creation of stupid URLs like nextpage1, nextpage2, etc., happy to leverage that. Either way, it shouldn't need an external plugin. The documentation doesn't give me much to work with - no code examples for noobs etc. There are examples here, but only in combination with the MarkupPagerNav module, with all the page number and URL stuff I am trying to avoid. Someone else was struggling with PaginatedArray here - 'pagination never works!' There is a code example in that thread that looks promising. I have to go back to basics, because none of this is obvious to me. This works as a super minimal GET Ajax demo:

Thanks again for the feedback, @gebeer. Even if I don't (immediately) agree with all your points, it is super helpful to focus my attention, research things, sort out my priorities, etc. I avoid plugins because they have to be all things to all people. Plugins come with lots of built-in assumptions about how everybody does stuff. I prefer to have a minimal solution tailored to the needs of my site that I understand and can expand/improve as necessary. I have decided I absolutely don't want any pagination, not even 'just one link to the next page'. It goes against the logic of my site; you can browse the content by topic, location, etc., each with their own index pages and then limited continuous scroll + a search box. No page1, page2, page3, etc. I don't necessarily want search engine bots index anything other than the top pages by topic, location, etc. and the posts' own pages. It would still be good to have the first few posts of the post array in the page without requiring javascript; the first post would also be a "featured" post, styled differently etc. So I probably have to rewrite the scripts - any ideas appreciated. The infinite-scroll.com plugin is originally from 2008, the granddaddy of continuous scrolling. The codeblock.co.za demo is from June 2020. Millennial developers have been claiming for the last ten years that everything will move to Javascript, with V8 in Chromium, React and all the other js frameworks. Is 'visitors without JS' still a serious issue? Or like nobody is developing for IE anymore. jQuery is the uncool old js framework, but isn't it still default in Processwire? I use jQuery everywhere in my templates. Yes, I noticed that. Thanks for the pointer. I'll have to rewrite that later. Any other suggestions how to improve that much appreciated. The codeblock.co.za demo has a line like this: $.get('posts.php', queries, function(data) { In my version I want to just get a $posts array instead of an external file. How should I rewrite that? Syntax etc.? Or is that not possible? What should I google for to find the solution? Searching now, but if anyone knows, please let me know. This doesn't work. Does anyone spot the problem? Should I use `if($config->ajax) { ...` etc.? Using `jQuery.noConflict()` did not fix it, but I still leave that in, because it works fine in the other test version: posts.php looks like this: I can't figure out how to pull in that posts.php file into Javascript within PW; hardcoded paths that work fine in a folder outside of PW, like this, don't work within PW: jLoad.get('/myserverpath/posts.php', queries, function(data) {

Thanks again @bernhard. I don't care about the SEO argument; those paginated nextpages should not exist. All content will have its own page and those pages will be reachable via search and limited continuous scrolling on index pages. Efficiency; good point. I guess PW's pagination solution takes care of caching and limiting database calls etc.? I have always avoided pagination, so will have to do some homework... This is probably what I'm looking for; continuous scroll (and load more button) with items from a array, not pagination. This example includes a lot of stuff at once... - https://codeblock.co.za/infinite-scroll-load-more-jquery-php/ I've downloaded the github files here and stripped out/dumbed down all the distracting css and fancy filtering, sorting, etc. to get a minimal working proof of concept that I can sort of understand and apply to a PW posts array later. This works as a demo: index.php js.js products.php I'll try to apply this in a PW page with an items array tomorrow... Or do you see obvious problems with this approach?

Thanks @bernhard and @gebeer, that is excellent input for me to start thinking through the options. @gebeer, the 'infinite scroll' solution seems to presume that you already have a pagination system, with next pages etc., that you then convert into infinite scroll. Is that correct? Do I first have to set up pagination in Processwire - PaginatedArray etc.? I want to avoid/bypass the messiness of pagination, have a continuous scroll system instead that just adds items, keeping everything on one page, in combination with a 'more button' and a search field, with advanced search and sorting options where necessary. I see renderPager() from @bernhard's suggestion is also part of PW's pagination system. Is it unavoidable? Looking into it... My clunky solution 5 years ago was based on ID's in the items and then adding the next one, like this, via Ajax - still searching for the other bits and pieces in my archives...: This worked in combination with this jquery:

Returning to this after 5 years, one of my annual Christmas/New Year web development projects. I think I got something working 5 years ago, but it was clunky and too confusing to implement throughout my sites. What is the recommended approach for 2023? Wish list: Infinite scroll - within reason, turning into a 'More' button after the first dozen items Lazy loading Not using plugins/modules ... Should I start with pagination? Or some other built-in feature to creates an array of items on page load, ready to be added to the page as you scroll down? The clunky first attempt called items by batch based on the latest added item, I think. I'll add my solutions here as I find them, using this thread to keep track of what I'm doing. Any tips/suggestions appreciated.

Thanks for the response @wbmnfktr. I've had this Leaflet module in my sites for years, but it has some problems. I was just wondering if there were better alternatives for 2023. Didn't Google Maps go fully commercial at some point, with unworkable limitations? What inputfield would that be? I think I use an inputfield StreetAddress that doesn't integrate with LeafletMapMarker at all. LeafletMapMarker has its own Address, Latitude, Longitude, Zoom fields, and then it also has a search field on the map. Entering an Address never works; the module forces you to use the search field on the map and that only finds a few weird irrelevant "landmarks" and in module's Address field weird addresses are added, sometimes adding words in Russian characters. Manually adding lat/long is usually the only way to get the marker in the right location. I have to use some other tool to find the correct lat/long. Is there a way to get better integration? Just add a street address somewhere, generate a correct lat/long, not have the MapMarker module make up all kinds of stuff. Also sometimes the map does not "kick in" in the front end; I just get an empty space. Probably some javascript not loading or loading too late. And probably just my template mess, but I haven't been able to troubleshoot/fix it yet.

This module hasn't been updated since 2018? What is currently the best way to put a map in a Processwire site?

I am using this module and am generally happy with it. Would be good if someone would maintain it. One issue I have; maps sometimes don't show up. I guess the javascript doesn't kick in somewhere and then you get a empty blank block. What can I do to make sure the javascript kicks in? Or something has to happen in the right order? Has anyone else seen this issue and fixed it? Probably not even 100% related to the module; it may just be something dumb in my templates.

Wow. That is perfect. ?

Just started using the image focus feature - very cool, works great, fundamental workflow improvement. ? What happened to the optional, future zoom feature that Ryan showed in the video here? Can I enable it somewhere? Is it still coming? Or left out to keep things clean and simple? Other ways to achieve the same?

Upgrading the secondary site to the same version as the "mothersite" fixed the issue. As explained here: 'Ideally all instances should be running the same exact version of ProcessWire if possible. At minimum, the versions must be close.'

Upgrading the secondary site to the same version as the "mothersite" fixed the issue. As explained here: 'Ideally all instances should be running the same exact version of ProcessWire if possible. At minimum, the versions must be close.'

Several of my sites stopped working. Has this multi-instance support been removed somewhere between v3.0.162 dev and 3.0.198 dev? Is there now another way to achieve the same? I urgently need to restore my sites. ? Is it related to this? Setting $config->useFunctionsAPI to 'false' makes no difference, so I guess not. The mothersite on the older PW version is still accessible with useFunctionsAPI on false or true; trying to access content from sites on newer PW versions produces a nasty 503 Service Unavailable error.

I am now starting to rebuild this from scratch. I have a main "mothership" site and want to display content from that site in a secondary site on the same server, with another URL. I had three sites working like this with a solution that involved $config->useFunctionsAPI that worked fine, until an upgrade somewhere between 3.0.169 and 3.0.198 dev. Did anything change recently? Where are the current instructions for this? I see a lot of stuff about multisite, but that seems to be about managing multiple sites with different databases from the same admin etc. When I put this in my home.php template: <?php $forum = new ProcessWire('/home/bizpartn/public_html/mymothershipsite/site/', 'https://mymothershipsite.com/'); echo $forum; ?> I get this error in the browser: No error message in logs. If I uses another site on a lower PW version, echo $forum outputs this in the browser: I guess this was "multi-instance support", I originally worked on it here. Has it been deprecated/removed?

My multiple instances (?) broke in upgrade somewhere between v3.0.169 and 3.0.198 dev. Did something change? What is currently the way to use this? I have to go back to basics and try to rebuild it.

I have three secondary websites that get content from a related mothership website's database via the API - "multisites" or multiple instances with $config->useFunctionsAPI enabled and `new ProcessWire()` etc. This broke for mothership websites that were upgraded to PW version 3.0.198 dev; it still works fine for the one that is still on 3.0.169. If I edit the other secondary sites to get content from the v3.0.169 site, they work fine as well - but with the wrong content obviously... With the v3.0.198 dev mothership sites, I now get error page 503 on the secondary websites that should get content via the API. The log says: 'Error: Exception: Unrecognized operator: % (in /path_to_my_pw/wire/core/Selectors.php line 410)' - I can't find info where that problem starts. There is probably bad coding/syntax somewhere in my template files, but I can't pinpoint it. Any suggestions? What changed between 3.0.169 and 3.0.198 dev? What could cause 'Unrecognized operator: %'? The selector error could be related to this?

@da², there are probably several standard ready-to-use scripts floating around on this forum and elsewhere and I think there was another module - curious to hear responses from others, I haven't checked recently. Here is a login/register process from the main PW developer Ryan Cramer. It's 5 years old, but I think it should still work and that it was provided as an example that you can adapt and expand to suit your needs. And if you really need a generic out of the box solution, you could always use the Pro module. Here are some of the old threads where I was trying to solve some parts of this, like best practices to secure registration and front-end password reset. Also see this post.

@da² I developed my own login/register process with a lot of help from this forum, I think just before that LoginRegister module(s) appeared. There are a lot of advantages creating your own process and PW makes it relatively easy. Once you have it, you can reuse it for different sites. Probably not super helpful in your case, but I imagine this is how many PW users approach it. Curious to see other responses...

I am trying to put together a front end form for a repeater field. The solution in the previous post gives helpful clues, but my repeater field doesn't need new pages and templates I think - isn't that a Page Reference field? My repeater field is for RSS feeds; name 'feeds', type 'Repeater'. The field used by 'feeds' is name 'rssfeed', type 'URL'. To store a regular field I'd use something like this: But instead of one value it would be adding one or more values to an array, somehow done with the fieldname[] and for ( $i=0;$i<$fields;++$i ) stuff, but without new Page() and template etc.? Not sure how to put that together, will try things this weekend... Is there a code example somewhere? Is there a way to get the same fancy repeater input field as in the admin area?

Thank you @horst! That was the problem. I was using $sanitizer->text() on the field. If I remove that it works fine. There is a $sanitizer->textarea() and $sanitizer->purify() is probably best for my use case.

Input from a textarea field via the front-end gets truncated; only the 246 characters (with spaces) get saved, nothing longer. When I enter text for the same body field via the admin back-end there is no limit and it also shows up fine on the front-end, but when I edit and save that same longer text from my front-end form, it gets cut at the same spot around 246 chars. I have tried with and without Ckeditor, but that makes no difference. I guess I can eliminate Ckeditor as a possible cause. What else could it be? This may be related or not. Any other ideas appreciated.

Why would I do that? I now have the delete button figured out - with your help! - so why would I start over again? I do normally avoid modules and try to use built-in methods that I understand. Agreed with your point. But for the comments section, this is a module by our fearless leader @ryanand as far as I understand it, I like his approach; looks like a solid future-proof basis to move forward with. So I need to sort out an edit button next, probably next Christmas... If anyone has any ideas, please post in this thread. I guess for an 'edit' button you would use updateComment()? Edit field via ajax?