Leaderboard

Just a quick heads-up that Wireframe 0.17.0 went live a few hours ago. Versions 0.15.0 .. 0.17.0 mostly included behind-the-scenes improvements and refactoring for existing features, so didn't think these were particularly interesting. Full changelog can be found from CHANGELOG, as usual. Probably the one and only feature that might come in handy during development is the shortcut method for defining view template and view at the same time (to use a view from a specific template instead of current one), added in 0.16.0: <?php // find blog posts and render them using the "list_item" view of the "article" template: ?> <ul> <?php foreach ($pages->find('template=blog-post') as $post): ?> <?= $post->setView('article/list_item')->render() ?> <?php endforeach; ?> </ul> On a loosely related note I've removed the "WIP" label from the topic of this thread, and am considering submitting the module to the modules directory. I think it's long overdue, really ?

This is a braindump of experiences and considerations that a matrix-based page builder should balance. I'll give more thoughts on this later: heading hierarchy source order div nesting section patterns general fields general fields "2"..."n" ex: image + image_2 ex: list_items + list_items_2 (for example, a section w/ description list + tabs) fields mapping to components ex: title => heading ex: image => image ex: menu_items => subnav items, nav items ex: list_items => description list items, tab items, accordion items, slider items, slideshow items, grid items what to do if field is empty? hide surrounding div structure? list_items field selectively showing/hiding appropriate fields depending on component type ex: accordion items => title + body only ex: slideshow items => image only (note: currently a bug with this using matrix template overrides; utilizing hack workaround instead atm) item templates for use in repeatable components when to use hannacode vs. component section switching (in an easy/quick way) section options (mystique) css framework components 3rd party components component options css framework flexibility (use setting() to store classes) naming approach ex: Grid vs. List of People user friend matrix-type registration visual selector w/ placeholder content instant preview (ideally prodrafts) direct vs. dynamic content saved / reusable sections multilingual weird things like - wrapping links (messes up predictable div nesting?) - image backgrounds using inline css - single line vs multi-line text ex: sometimes a heading should be multi-line instead of having 2 separate fields ability to programmatically include a section template using $files->include css grid vs. flex grid - flex gap? https://coryrylan.com/blog/css-gap-space-with-flexbox A section is literally an HTML <section> (or it can be a div if specified). Imagine a section that has 2 components in the following source order: image + text. A section can be styled independently and map to UIkit section classes: https://getuikit.com/docs/section You could call this section "Image + Text" in repeatermatrix for example and give it the UIkit markup to put the image on the left and the text on the right using the appropriate css classes, and wrap it in a container. This is very easy to understand for content editors. Very important. Now you what if you want flexibility such as having a small container instead of a regular sized container? The "wrong" way to do this would be to make a new matrix-type called "Image + Text (Small Container)". Instead you think of maybe having additional dropdowns to manage such things in the matrix block, but if you think that through and build many sections, it will be overly complex and feel wrong. The "correct" way to do this would be to have various section patterns that modify the div structure and component options of that matrix-type. So for example, if you wanted a small container + animations + rounded corners on the image, you could have a section pattern (would have to be created by the developer) that the user selects that applies all that collectively. Maybe each section has 2-5 section patterns which seems reasonable. With this section pattern approach, you could theoretically have the same section display the image on its own row and the text below. But what if you want each component to be in its own different sized container? If you think this through this requires a different div nesting structure to keep things super flexible: <div class="<?=setting('div-1-class')?>" <?=setting('div-1-attr')?>><!-- container --> <div class="<?=setting('div-1-div-1-class')?>" <?=setting('div-1-div-1-attr')?>><!-- container inner --> <div class="<?=setting('div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-attr')?>><!-- grid --> <div class="<?=setting('div-1-div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-div-1-attr')?>><!-- col --> <div class="<?=setting('div-1-div-1-div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-div-1-div-1-attr')?>><!-- component wrapper --> <?=files()->include('./fields/blocks/image.php', [ 'page'=>$page, 'block_options'=>setting('image-1-block-options') ])?> </div> </div> <div class="<?=setting('div-1-div-1-div-1-div-2-class')?>" <?=setting('div-1-div-1-div-1-div-2-attr')?>> <div class="<?=setting('div-1-div-1-div-1-div-2-div-1-class')?>" <?=setting('div-1-div-1-div-1-div-2-div-1-attr')?>> <?=files()->include('./fields/blocks/text.php', [ 'page'=>$page, 'block_options'=>setting('text-1-block-options') ])?> </div> </div> </div> </div> </div> vs. <div class="<?=setting('div-1-class')?>" <?=setting('div-1-attr')?>><!-- container 1 --> <div class="<?=setting('div-1-div-1-class')?>" <?=setting('div-1-div-1-attr')?>><!-- container inner 1 --> <div class="<?=setting('div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-attr')?>><!-- grid 1 --> <div class="<?=setting('div-1-div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-div-1-attr')?>><!-- col 1 --> <div class="<?=setting('div-1-div-1-div-1-div-1-div-1-class')?>" <?=setting('div-1-div-1-div-1-div-1-div-1-attr')?>><!-- component wrapper 1 --> <?=files()->include('./fields/blocks/image.php', [ 'page'=>$page, 'block_options'=>setting('image-1-block-options') ])?> </div> </div> </div> </div> </div> <div class="<?=setting('div-2-class')?>" <?=setting('div-2-attr')?>><!-- container 2 --> <div class="<?=setting('div-2-div-1-class')?>" <?=setting('div-2-div-1-attr')?>><!-- container inner 2 --> <div class="<?=setting('div-2-div-1-div-1-class')?>" <?=setting('div-2-div-1-div-1-attr')?>><!-- grid 2 --> <div class="<?=setting('div-2-div-1-div-1-div-1-class')?>" <?=setting('div-2-div-1-div-1-div-1-attr')?>><!-- col 2 --> <div class="<?=setting('div-2-div-1-div-1-div-1-div-1-class')?>" <?=setting('div-2-div-1-div-1-div-1-div-1-attr')?>><!-- component wrapper 2 --> <?=files()->include('./fields/blocks/text.php', [ 'page'=>$page, 'block_options'=>setting('text-1-block-options') ])?> </div> </div> </div> </div> </div> You can represent those 2-component div structures like this: (1 2) (1) (2) If you have 3 components: (1 2 3) (1 2) (3) (1) (2 3) (1) (2) (3) 4 components: (1 2 3 4) (1 2 3) (4) (1 2) (3 4) (1) (2 3 4) (1) (2) (3 4) (1) (2 3) (4) (1 2) (3) (4) (1) (2) (3) (4) 5 components: (1 2 3 4 5) (1) (2 3 4 5) (1 2) (3 4 5) (1 2 3) (4 5) (1 2 3 4) (5) (1 2 3) (4) (5) (1 2) (3) (4) (5) (1 2) (3 4) (5) (1) (2 3 4) (5) (1) (2 3) (4 5) (1) (2) (3 4 5) (1) (2 3) (4) (5) (1) (2) (3) (4 5) (1 2) (3) (4 5) (1) (2) (3) (4) (5) (it can actually get more complex than that, but no need to go there) A CSS Grid approach probably removes the complexity required for div nesting (not 100% sure since I haven't used CSS-grid in a long time). UIkit would ideally have a built in solution in version 4. Maybe I'm overthinking this div nesting part. Perhaps the section pattern (which comes in via a json settings file and stores its values in setting()) directly specifies which div nesting layout should be used. Hmm.

This week the core version remains at 3.0.166, but 3.0.167 should be ready by next week. The main reason I'm not bumping the version is just because a couple additional updates I want to get in 3.0.167 are started by not yet fully finished. Below is a look at what's been committed to the dev branch this week so far: Added custom Page class support for the Language class by implementing your own LanguagePage class that extends it (i.e. /site/classes/LanguagePage.php). Added a PR from MoritzLost with improvements to the CURL support in the WireHttp class. Added a new method to the Fieldtype interface named getMatchQuerySort() this method lets a Fieldtype module optionally manage the query when a $pages->find() requests a sort by a field/subfield handled by the Fieldtype. The first implementation of the getMatchQuerySort() method was added for FieldtypeOptions, which now lets you sort by option values or titles, despite those values and labels being in a separate table that the rest of ProcessWire doesn’t know about. Added a new getAfterLoginUrl() method to the Process module interface which lets Process modules optionally sanitize and validate request URLs to the module for a non-logged-in user. The resulting URL can be automatically redirected to once the user has logged-in. While the method has been added and implemented in several core Process modules, it is not yet used by the core after login—that will come next week in 3.0.167. Previously the only aspect of an admin URL that could survive login was an “id” integer in the query string. This week there were also several optimizations and improvements made to the PageFinder class and resolutions to 4 issue reports. Thanks for reading, have a great weekend!

@monchu is correct, please describe or provide a screenshot of how you have your "page_body" field setup. Here is an example of the basic body field being used for the Hana Code Text Formatter.

I've probably thought up a dozen different approaches to creating an ideal page builder in ProcessWire but each of them have their pros and cons. It's very difficult to strike a perfect balance for something that suits both developers and editors. There are so many (!) other variables to consider. This isn't just a ProcessWire dilemma, but just the nature of page building itself. There are trade-offs and complexity must live somewhere. In an ideal world, you'd use RepeaterMatrix in a classic way, but if you run that thought experiment, here's what happens: I'll make matrix-types for all the sections in a particular page. I'll write the templates for those matrix-types, so all an editor has to do is fill in the fields and everything just falls into place. I'll drive off into the sunset and be happy. Well, turns out there are some changes that need to be done. MatrixType X needs another field. I'll add that field and update the template. Well now we need another matrix-type, but it's basically identical to MatrixType X except the columns are flipped. Does this warrant a new matrix-type or a toggle option of some sort? ... You start another new project and it needs a page builder like the first site. You realize there's going to be some heavy re-use of matrix-types from the first site, so you now think... hmm maybe I should somehow modularize this approach where there is a shared matrix-type library. (I've done this) ... Many of the matrix-types between site 1 and site 2 are similar, but with slight differences... some have different css class names, some have different field names. Now this shared matrix-type library has a bunch of matrix-types but you feel unsatisfied because you think there is a better way to refactor this. The ideas in your head about how to refactor end up going against the grain of the classic page builder way / repeater matrix approach and now you're frustrated. I've gone through this thought process a bunch of times. I've researched basically every single page builder out there. It's like trying to solve a puzzle without a definitive end result. One thing that happened is reactive frameworks gave rise to the current generation of page builders (think WP Block Editor / Gutenberg, SquareSpace, and few dozen others). This left the classic page builder approach behind (RepeaterMatrix, ACF Flexible Content). But I like the classic approach because it gives more programmatic control and it's the way ProcessWire works... and editors can't really mess things up since it's a more controlled experience. I feel like there hasn't been experimentation and development for the classic approach since the world has "moved on" to the newer generation approach. I think RepeaterMatrix is good, but maybe it can benefit from some experimentation of some sort.

Interesting thoughts indeed ? I have not yet actually used CSS Grid in a real life project yet, because some mobile browsers have just recently started to support them (https://caniuse.com/?search=grid – Date Relative tab) but probably sometime next year it will be"almost safe" to use it even without a polyfill. I think CSS Grid is for the "main layout" of a page and not for the layout of individual components. Sure, CSS Grid could be used for individual components as well (why not?) but it looks like it would be an overkill for that purpose. However, flexbox is still great for individual components. The grid systems in CSS frameworks are pretty useful, but in the light of CSS Grid, in the future I will probably only use them for individual components, and CSS Grids for the layout of the page. Being able to freely and "responsively" move blocks around the page based on viewport size is the real power of CSS Grid, I think: https://www.youtube.com/watch?v=TrLN2YId-5M https://caniuse.com/?search=grid-template-areas This "rearranging-freely power " is why ditching the classic layout grid systems for page layouts is the future ? Not to mention that the various framework grid systems require various levels of wrappers to support their specific grids, while the CSS Grid is standardized, of course.

Hello @bernhard, for the super late reply. I was super stressed around this project and just couldn't get my thoughts together. Thank you for your reply and the work on RockFinder3. I wasn't really able to contain the results I was interested in from RockFinder in an array for further use. I think that's what frustrated me. But it's probably due to my lack of knowledge of PHP rather than the module itself.

1. Change this AOS module setting as you wish: 2. Add templates definitions to that file (as described here or here).

Hey @adrian, thanks a lot, I've tested your modified version. For me, subfields as top level options are totally fine, already adds a lot of possibilites for user references! I found that my columns have type pageAutocomplete and not pageSelect, I think that's why they were exported as IDs only. I added pageAutocomplete to the fieldType checks and this works! – unless I export both "User" and "User.email", then somehow the $subfields indexes are off (Undefined offset ...). So I made one more change where the main page "User" is not added as an option anymore. To cover all cases I also added id as a subfield option. I marked my edits with //@TH SUBFIELDS There is also pageAutocompleteMultiple, that seems to procude other problems I didn't dig into. TableCsvImportExportSubfieldsTH.zip

Just dropping in to say thanks for this module! Saving me soooo much time on a current job. ?

This shouldn't be a problem ?

Hi @Marco Ro – Thanks, I'll need to look into this. It isn't the first time it's happened. Internally, I use a package that generates the sitemap using a 'fluent' interface, and this issue has crept up with that package a few times in the past.

Hi @thausmann - when exporting a table with a page reference field, it should export the title of the selected page(s), and not the ID so I am maybe confused about what you are seeing. The option to export a field from the referenced page would be great for sure. The way I'd envision this working would be for the "Columns / Order to Export" selection to work like Lister does with its ASM parents functionality where you select a parent and then get to select subfields, but I am rushed for time, so for the moment, I've just made it possible to select them as separate top-level items. Please try the not-well-tested version attached. Please feel free to make improvements. TableCsvImportExport.zip

Seems like double-posting worked for you better in this topic, @Jessie) Anyway, please do not double post not to clutter the forum)

@Gadgetto I submitted an issue on github with the accompanying images. A bit late but better than never I suppose... I closed the issue as I realised I just had to add the specific currency field to my template... I don't know why I assumed SnipWire is converting all the currency based on the initial one. ?‍♂️ Anyways, it's all good now.

Hey @adrian! Just wondering: what's your take on extending current panel collection with custom tools on a case-by-case basis? Sorry if this has been discussed already, there's so much stuff in this thread that I can't keep up anymore ? I just had a quick look and it seems that adding new panels is currently not possible without directly modifying the module file(s) and dropping the class file to the panels directory. I was wondering if you'd be open to adding some way of "injecting" custom panels from outside the module? My initial idea was something along the lines of allowing custom options to be pushed into the allPanels array by passing it to hookable methods at certain points and adding support for array values so that custom panel options could contain both name and path. (I didn't actually try this. It's possible that hooks won't work due to load order and all that, so another option would be the Tracy module reading them from config settings; not quite as elegant or robust, but pretty much guaranteed to work.) Anyway, just throwing in ideas. I'm working on some Wireframe related dev tools, and was thinking that it'd be neat to have them available in the admin — and what better way to do that than to introduce them to Tracy... ?

Will second https://www.11ty.dev/ as an awesome static site generator, really great product. For a list of lots of options check https://www.staticgen.com/ Gatsby isn’t really a pure static site generator, it’s more a framework for creating progressive single page app websites with react. It has a heavy reliance on graphql and can handle server side rendering like next / nuxt / sapper. It would actually be pretty overkill to use gatsby just for a completely static site (ie one that doesn’t use a database of any kind). The power of these frameworks is data is pulled in from one or more sources at build time which is used to programatically create pages / populate content. This data can come from the file system, from a csv file, but mostly it is stored in a cms. There are lots of “headless cms” out there (I like to think of these as more cms as a service) that you will read about being used with gatsby. The most promising of these in my opinion is https://www.sanity.io/ which is a pretty amazing product. However there is nothing stopping you from using PW for this. 11ty makes it super easy to grab data from anywhere to use at build time (unlike gatsby where it all has to be ported into its own graphql instance), and if you wanted you could have all your content stored in PW, create some json api endpoints manually or using a module like the graphql one, and use that data to build a flat HTML static site with 11ty that you host on netlify or zeit. Obviously this requires rebuilds when content changes, and doesn’t allow much interactivity, which is where the more complex feature set of gatsby comes in... server side rendering etc. Another project I am really digging at the moment which I think more meets the topic of this post is https://saber.land/ If you are into vue definitely check it out.

@Knubbi - easiest quick fix would be for you to change these two lines: https://github.com/adrianbj/ProcessAdminActions/blob/bb7738c59b62de19ad83bc84e147b2fedde93c2b/actions/FieldSetOrSearchAndReplace.action.php#L123 https://github.com/adrianbj/ProcessAdminActions/blob/bb7738c59b62de19ad83bc84e147b2fedde93c2b/actions/FieldSetOrSearchAndReplace.action.php#L142 replacing the '/' with '#' or other character.

When I started working professionally on web projects... (don't you just love when folks start with that? "oh man, it's going to be another rant!") ... some of the first CMS' I had the pleasure to work with were kind of "static site generators": they generated static HTML files when you saved the content, and if your site had subdirectories, those were literal directories on the disk with more HTML files in them. I believe this was in part because server-side rendering back then was pretty darn slow and clunky, but also because it was easier to build a clean site structure with actual directories filled with static HTML files. "Dynamic" features, comment forms, polls, and whatnot were not quite as important back then, mind you. Now, I get that modern SSG's are a different beast in many ways, and I think they're actually pretty rad. What bugs me, though, is the amount of marketing bullsh... uhm, opinionated information floating around. Things like this gem from the staticgen.com website (emphasis added): I mean... how is this what a "typical CMS driven website" looks like? Any half-decent CMS has built-in caching support, at least to some extent, and caching plugins regularly pop up amongst those lists of most popular plugins for platform X. You don't need to be a rocket scientist to figure out that running a server-side rendered, CMS generated website with no caching whatsoever is a Very Bad Idea™. Comparisons like this may make the SSG approach sound good, but they've also got little to do with how things actually work. Without hopefully being too blunt, I don't think this is necessarily the best question to ask. If you define SSG as an application that reads markdown files from disk and generates a static site from those (that's one of the first definitions that comes up if you search for the term) then I don't see this as a solution most of us could push to our clients. At least not unless the site in question is a static one that doesn't need to update too often, and/or you can convince the client to pay you for each modification on a case-by-case basis. On the other hand if you think of an SSG as something that generates static site from dynamic content managed by some piece of software, well... that software you use to generate the content for the SSG? That's a CMS. It may be a headless CMS, but a CMS nevertheless ? I'm also going to agree with @MoritzLost on the point that ProcessWire + ProCache is indeed a kind of an SSG. Keeping a few potential pitfalls in mind one could definitely use this combination to build a setup that pre-renders the whole site and thus doesn't depend on request time server-side rendering. The web is full of interesting tech: headless CMS', static site generators, APIs, and whatnot. While the "best" choice depends on the use case — you would have to consider the pros vs. cons and figure out what's best for each particular project, client, and team — in my opinion it's also rarely all that important. Websites are created for end users and end users don't care what you're running the site on — as long as it works, serves their needs, is fast (enough), etc. ... and you can get that with any platform ? Sorry, that last part was a bit off-topic. Overall the SSG market is well worth keeping tabs on. Personally I tend to lean on the "dynamic CMS generated content rendered server-side with efficient caching policy" approach, but that's mostly because I feel it makes sense for the kind of projects and clients I tend to work with. Pros and cons ?‍♂️

11ty is great. It's super flexible and doesn't lock you into a certain way of using it or fixed templating. Static site generators make a lot of sense for anything in the realms of corporate or product marketing page. You can keep all the stuff, which rarely changes in plain html. Form submissions and such can just be sent to a different headless endpoint. There's also things like Netlify CMS or similar tools, which allow you to trigger rebuilds whenever something in the underlying data changes. This is nice if you don't want to involve a dev every time some copy changes. For more dynamic content like e.g. comments I'd still not use a static site generator. They make sense if the cost of rebuilding for each change is outweight by the simplicity of deployment / putting the site up somewhere, but not really if you're constantly rebuilding. I don't really subscribe to the idea of having highly dynamic content just rendered client side, but people do use ssg's as an alternative to the dreaded SPA. Dynamic content is still all loaded/rendered in js, but at least it's multi page with some static bits.

Static site generators will probably be 'the next big thing'. You get way better performance and security by default than you could have with any CMS by definition. Which doesn't mean that you can't have dynamic content like comments, e-commerce etc. But instead of bundling that functionality, you're using external services, APIs, serverless functions and build automation to persist data and trigger builds whenever something changes. I'd recommend reading the Jamstack book (created by the Netlify people), you can get the ebook for free and it explains all the concepts related to SSG. By the way, you don't need NodeJS / NPM to have a static site generator. Though many SSG are built with JavaScript, they use NodeJS only as a runtime for the build step, not as an actual server. But there are SSG written in all kinds of languages - check out this site if you want to find one you like. One could argue, by the way, that the ProCache module for ProcessWire is also kind of a SSG generator, even though it works a bit differently than most tools on that list. My current recommendation is eleventy, I'm currently rebuilding a couple of my own sites as well as a ProcessWire-related project that I might release soon with it ?

No worries, I get what you're saying ? The way SearchEngine is built makes it (in my opinion) really simple to use when you basically just want a search feature and are happy with some visual modifications to the form and list of results etc. But once your needs get more complex, there's a bit of a learning curve there. I've tried to keep the complexity to bare minimum, but it can still be a bit overwhelming at the beginning, especially if you're not particularly familiar with the way ProcessWire itself works. You can definitely do the kind of query you mentioned above with SearchEngine. At least for now the index field is just a regular FieldtypeTextarea (or FieldtypeTextareaLanguage for multi-lingual sites), which means that you can perform queries against it just like with your own custom fields. +1 to this right there. Selectors are one of the biggest arguments for ProcessWire: not only do they make complex queries a breeze, but by sticking with them you can easily avoid some of the gotchas you'd have to worry about working with raw SQL (injection attacks, etc.) Behind the scenes almost every field you see in the admin is what one might call a "custom field", and each of those has a database table of its own. ProcessWire makes extensive use of JOIN queries, which do indeed make things more complex if you're trying to write raw SQL, but again: this is something you should almost never do anyway ?

There's no need at all to understand the PW architecture or database structure and relations - or even to think about these things. Stick to using PW selectors (https://processwire.com/docs/selectors/) and all the hard work is done for you. Selectors are one of the really great features of PW! (Note that if you later decide to use RockFinder for the extra speed, it also understands the PW database structure so that you don't have to.)

Hey there! Just wanted to drop a quick comment ? SearchEngine provides two built-in methods for search form rendering: Highly customizable "basic form". You can probably get the best idea of this by taking a look at these lines in SearchEngine.module.php. I'd actually be surprised if there's something you can't customize. Less customizable (unless you really enjoy hooking into form rendering) "native ProcessWire form". I know that some folks prefer these (I don't), so I thought it would be a nice addition. ... and, of course, you don't have to use either one. Bring your own markup. SearchEngine doesn't really care about the form — there's no CSRF or anything involved, it's just a search feature ? As for the results list, there's the "easy way" where you let SearchEngine handle everything for you. Again, this is quite customizable via config settings and hooks, if you've got something specific in mind. JSON is also an option, but this is mostly intended for cases where you want to utilize SearchEngine as a part of an API, or perhaps create a fully customized JS search form feature. The biggest things lacking form SearchEngine (in comparison to tools like Meilisearch, or more heavy-weight indexers such as Solr, Elasticsearch, RediSearch, etc.) are the ability to normalize queries, perform complex lookups from the index (SE is basically just using ProcessWire's selectors and that's it), smart weighting of results based on relevance (this is on my to-do list), and perhaps really snappy real-time results (you can perform asynchronous queries, but they go through your site, which means that they have some overhead; tools like Meilisearch can do this much more efficiently). Anyway, just wanted to let you know that there are different options there. I don't actually know your case well and can't say if SearchEngine is the correct solution, but if it's UI level customization you're after, that shouldn't be an issue. And if it is, please let me know what's missing and I'll be happy to take a closer look; perhaps it's something that others might find useful as well ?

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/

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.

The newest version of Klaro gives you the option if the CSS is included or you provide your own CSS. This is based on my PR.

Had this same issue today, ie get the customised label for a page/template field and tried all the above. They all returned the original field label and couldn't find any reference to the 'true' option when getting 'fields' or 'field' in the API Docs. Maybe PW has moved on or more likely, I missed something. Anyway, what did work for me was: $page->getField("body")->label; https://processwire.com/api/ref/page/get-field/

Yes, it has always been like this since I can remember. I don't think this is a ProcessWire issue, but a CKEditor one. So unless they fix it on their side, a new version will not help unfortunately.