Leaderboard

Hi @michelangelo, The fastest way to achieve the effect of Instagram feed, is to use Processwire Pagination with Ajax Infinity Scroll, for example https://infiniteajaxscroll.com There is no silver bullet to take thousands of results form any kind of database. You should take it part by part and Processwire Selectors with Limits are good solution or prerender them as static data and keep them cached, as guys above said. BTW, 1,000 divs on one page is realy bad idea in terms of browser capacability. Just open Instagram, scroll hounded posts and take a look how many resources it will takes from your console. Good luck Alexander

A ProcessWire find will perform an SQL query. The important thing (in terms of performance and tools like RockFinder) is what happens next. SQL queries are normally very fast. However, if you then load the results into Page objects, you might get a performance hit depending on the number of results you fetched. RockFinder does not load Page objects, hence remains very fast and performant. It is very much suited to handling large datasets.

We have created a module to create BlurHash strings for images while uploading in ProcessWire. This blurry images will be saved in the database because they are very small (20-30 characters) and can be used for Data-URL's as placeholders for image-lazy loading. https://github.com/blue-tomato/ImageBlurhash E.g. where we use this in production: https://www.blue-tomato.com/en-INT/blue-world/ https://www.blue-tomato.com/en-INT/blue-world/products/girls-are-awesome/ https://www.blue-tomato.com/en-INT/buyers-guides/skateboard/skateboard-decks/ https://www.blue-tomato.com/en-INT/team/anna-gasser/

RockFinder can massively reduce search times. I've used it to reduce complex searches from several seconds to fractions of a second. However, if your searches aren't too complex, even on a fairly large number of pages the difference could be between part of a second using PW selectors and a very small part of a second using RockFinder. This isn't really going to solve your problem. So I'd suggest sorting out the rendering first, as suggested by others, with RockFinder as a possible later refinement.

OH, hurry up, I need this as soon as possible! ?

Indeed, it will work on front-end editing for defined roles ??

Ok this is awesome then - best of both worlds! One other feature request that will make this a killer module IMO... that it should work with Front End editing.

Reading more on your project I think this is the right way to do it, RockFinder and RockGrid are very oriented in display the data in one shot using the browser for what I understand. You shouldn't really have that much issues using the built in pagination. I have a project where I paginate about 2 million pages and works (not blazing fast) but it does work at a reasonable speed. As @horst suggests, ProCache makes a whole world of difference too.

Combine the power of ProcessWire selectors and SQL Differences to previous RockFinder modules RockFinder3 comes with extensive docs ? RF3 supports chaining: $RockFinder3->find("template=foo")->addColumns(['foo']). RF3 fully supports multi-language. RF3 makes it super-easy to add custom columnTypes. RF3 makes it easier to use custom SQL statements. No bloat! The module does just do one thing: Finding data. Differences to findRaw Background: RockFinder has been there before findRaw existed findRaw makes it a little easier to query page fields, but RockFinder is more flexible in that regard RockFinder might be faster than findRaw: see here DOCS & DOWNLOAD: https://github.com/baumrock/rockfinder3 Thanks for using RockFinder3. If you find RockFinder3 helpful consider giving it a star on github or saying thank you. I'm also always happy to get feedback in the PW forum! Happy finding

This is a module I made as an experiment a while ago and never got around to releasing publicly. At the time it was prompted by discussions around using Repeater fields for "page builder" purposes, where the depth feature could possibly be used for elements that would be nested inside other elements. I thought it would be useful to enforce some depth rules and translate the depth data into a multi-dimensional array structure. I'm not using this module anywhere myself but maybe it's useful to somebody. Repeater Depth Helper This module does two things relating to Repeater fields that have the "Item depth" option enabled: It enforces some depth rules for Repeater fields on save. Those rules are: The first item must have a depth of zero. Each item depth must not be more than one greater than previous item depth. It provides a RepeaterPageArray::getDepthStructure helper method that returns a nested depth structure for a Repeater field value. Helper method The module adds a RepeaterPageArray::getDepthStructure method that returns a multi-dimensional array where the key is the page ID and the value is an array of nested "child" items, or null if there are no nested children. Example The module doesn't make any assumptions about how you might want to use the depth structure array, but here is a way you might use it to output a nested unordered list. // Output a nested unordered list from a depth structure array function outputNestedList($depth_structure, $repeater_items) { $out = "<ul>"; foreach($depth_structure as $page_id => $nested_children) { $out .= "<li>" . $repeater_items->get("id=$page_id")->title; // Go recursive if there are nested children if(is_array($nested_children)) $out .= outputNestedList($nested_children, $repeater_items); $out .= "</li>"; } $out .= "</ul>"; return $out; } $repeater_items = $page->my_repeater; $depth_structure = $repeater_items->getDepthStructure(); echo outputNestedList($depth_structure, $repeater_items); https://github.com/Toutouwai/RepeaterDepthHelper https://modules.processwire.com/modules/repeater-depth-helper/

Hi @androbey, Now I can confirm the db issue, it appears also on my dev env. I will take a deeper look into it tomorrow.

+1 ?

Yep, that was fix. Forgot that step. Thanks for the quick help

In the near future I plan to study on using Teppo's module to build an index directly to a Meilisearch instance running on the same server. I used it on a recent Laravel project and, although I only scratched the surface of its capabilities, the partial match and typo toleration is worth a try IMHO. Also it was a breeze configuring it.

There's also this cool module by @teppo that let you create a search index to speed up things immensely on some cases. https://modules.processwire.com/modules/search-engine/

... and I thought that we in Germany are already tortured with extreme detail. ? Thanks for sharing the explanations!

Note that legislation may differ from country to country. For an example here in Finland one apparently still has to document the cookies, even though "necessary" ones don't require opt-in (or opt-out). IANAL etc. but that seems to be the common consensus anyway ? Here's a rough translation of the descriptions we've been using: wires ProcessWire session identifier. First-party session cookie, expires when the browser is closed. wires_challenge ProcessWire session cookie used to verify the validity of a session. First-party persistent cookie, expires after 30 days.

Needless to say, that's exactly how it works. Thanks again, you two. Greetings

I think I get what you mean @Guy Incognito Actually, you can move every single paragraph independently - BUT, you can also copy/cut all the selected paragraphs and move them as it was a "one-block".

This looks cool. One bit of feedback (and this may just be my opinion rather than a general consensus) but I really dislike how the WP Gutenberg treats every paragraph as a block. To me it makes no sense to be able to rearrange text at the paragraph level. To me a single block of text with multiple paragraphs within it seems more sensible. Although looking at the example JSON doc on the Editor JS homepage it looks like it treats every para as an element and for ease of maintenance I guess you won't won't want to stray too far the default behaviour.

Thank you lads, sounds great. Now I got a better understanding. @Alexander yeah, 1000 divs is not the best :| I will make use of the template caching and just save the output of this page. And I maybe misrepresented the concept. It's just a list of all the 1000s of songs I have in my db. So technically it's more like a div with 1000s of spans or a's. Thanks for the ajax idea :)) Does the cache option on the templates relate to the $cache()? I enabled it for my templates and it seems to make everything faster, but I am randomly picking options (e.g. saving it for 1 hour!? ) and I am not sure how to continue...

Super cool stuff, @Robin S! Your modules are always the thing you wanted to, but never managed to do) I understand it is for all Repeaters not for Repeater Matrix only. But when used with Repeater Matrix it would be useful to: limit the RM types for the 0 level; limit the available children for a type. Maybe it is too much. And would probably require hooks to implement anyway, so not so useful for easy management. But just wanted to get those ideas out of my head)

I have now, as promised, a new version ready for you. Version 2.1.3 includes the improvement that @bernhard suggested. Twack is now available as api-variable. I personally prefer the wire('twack') syntax, but that's a matter of opinion. All code-examples and the project`s readme.

Hi @michelangelo, what's about pagination? As you mentioned the skyscraper site, if I remember right, it also uses pagination. And besides pagination you should use caching. If possible, you should use ProCache. But there is also template caching and more available.

Definitely take a look at RockFinder3 along Rock2Tabulator.

I for one am excited to see the release of this; waiting patiently.

That makes a lot more sense in terms of advantages - I will need to look into this some more! Thanks.

I'm also using Twig with a custom translations system for interface text / code i18n. While the built-in multilanguage support for page fields is well-done, I don't really like the system and interface for code internationalization and localization, and it doesn't work with Twig files (which is probably why you want to build your own). I have written about the approach I took in the second part of my Twig + ProcessWire tutorial (towards the end, the section about translations). It comes down to a ProFields Table field that holds all the translations (so they can be edited through the backend as well) and a function that gets a local translation for the current language based on translatable strings (msgid). By the way I've switched to a Twig filter since writing this tutorial, I find it easier to write, so now I can simply do the following in Twig: {{ 'hamburger_button_label'|t }} If you do end up writing a module for this, make sure to publish it here as well, I've been looking for a more scalable approach ?

Well, if you look through the database, you can see that SelectOption fields are always saved by ID (i.e. the value that goes into the database for this field is the selected option's ID). The mapping of IDs to values and labels is done through the central field definition. So changing that would be a lot of work. Can't you change the API call (or whatever) to the external service to use the value instead of the ID?

https://github.com/processwire/processwire-issues/issues/480#issuecomment-382383357 https://processwire.com/blog/posts/pw-3.0.99/ Percentage-based widths should be the default IMO.

I appreciate the effort here, but remember @kongondo that many of us aren't looking for that full list of features from your original post two years ago. I'd much prefer a performant cut down version and the ability to give you some money for ongoing development than one giant release with all the bells and whistles. MVP > feedback from real customers > new releases. Thanks and i hope everybody is okay considering the current climate =D

Hey everyone, Max from Snipcart here! We just published a full tutorial showing how to use ProcessWire + Snipcart (our dev-first HTML/JS shopping cart platform) to enable e-commerce. It was pretty much my first time playing around with the Apache/MySQL/PHP stack, so I'd love to get some feedback on the demo code. Oh, and also, if you feel like the Snipcart integration could have been done in a different/better way with ProcessWire, let me know! > Blog post tutorial > (Very) simple live demo > GitHub repo Cheers folks.