kongondo

No there isn't. I just fixed it in MM 012 as it was a very minor fix. Could you please check around line #42 of this file site\modules\MediaManager\configs\fields.json. If you have a "fileSchema": 7, entry please delete that whole line.

Use ProcessWire's Pages Export/Import module. In the demo below, we are exporting everything. In your case, instead of selecting Media Manager as the parent, select Media Manager: Document (since you are only interested in the PDFs). It might take a while depending on the number of media pages you have. Once the zip downloads, import it using this same module (use the import from zip option). Job done. Note that sometimes you might have to repeat an import in case some files were missed. I've seen this especially with images. If you are running out of memory, you can switch to importing batches instead (use the find pages to import using selector option in that case). Edit: Demo was supposed to show here; but forum doesn't like gifs (old problem). I have thrown the file in this archive instead. export_media_manager.zip Hmm. I am not sure. I'll have a think. Hope this helps.

Thanks for the purchase :-). Sorry the notes weren't clear. It must be the adjacent (immediate previous) column. So, yes, 'its previous column'. Please see the docs here, especially the introduction and the section on column relationships. This is because both the 2nd and the 3rd columns are related to the first. The duplicate values getting shown in 3 are due to the JavaScript which determines the select to populate based on the trigger. In your case, your target selects 2 and 3 have an identical identifier (built off the field name 'background_colour'), hence both get populated. No, you are not missing anything. What's happening is expected behaviour. The cascade is strictly one-to-one (trigger-dependent selects relationship). Incidentally, I am soon reworking Dynamic Selects to use htmx. That will open new possibilities. I'll have a think around your issue, as a feature request. Hope this helps.

Aha :-). What's the difference between this site and the other non-problematic one? If they are different with respect to ProcessWire versions and/or PHP versions, then best to file a bug report, thanks. If they are not different in this regard, then we'll need to keep digging; maybe a third party module interference, etc.

He can see the comments if logged in, so might not be a CSS issue but an access one ?. I see. Given that everyone can see other parts of the page even if not logged in (e.g. blog title, etc), this seems to suggest an access/view issue with the comments field itself. Have you checked the 'Access' tab in the comments field?

It's right there in your settings ? (as per your screenshot). Under Comment moderation, your setting says All comments must be approved by someone with page-edit access. Hence the 'Pending' comments you are seeing. You need to approve them in order for them to be visible on your site for your 'guests' (commenters). Edit: If you specify an email under Admin notification email, you will get notified every time someone (or something -> spam) posts a comment on your blogs. You will be able to approve/disapprove the comment directly within your email (if you wish).

I haven't looked at your code but the comments field is where I'd look first (with respect to comments visibility). As for a logged in user seeing all comments, you are logging in as a superuser, hence can see everything (including the comments field).

Interesting. So, with this approach we only need to register the template via a setting (on the template edit screen) and that same template can be used to output either HTML or JSON, right?

It might also be a 403 (permissions changed in your file or the folder it lives in). As stated above, have a look at the console for any errors (if a module refresh did not resolve your issue; including clearing your browser cache or viewing in incognito).

Quite likely.

Yep. Padloper2 ?.

Yes. There are these alternatives though: ☝️this has never worked for me though. Will at best return an empty array and at worst throw a SQL error. Works fine for me, except for URL. I get ratio, width, etc. https://processwire.com/api/ref/pages/find-raw/

Hehe. In fact I had started adding the below but thought to save it for another day. But I'll add it here and then stop this OT business! I was saving above for a Blog post when Padloper stable is released...but oh well. And now, I shut up ?.

Quite an interesting concept you got here. I am wondering though if it would introduce more complexity? For ProcessWire, like you mentioned, posts, pages, customers, orders are all the same things. Maybe the difference would be users, i.e. $users. Other than that, all the other stuff after /api/v2/ could be query strings as per @lokomotivan's suggestion ?.

Why? Were you not aware of findRaw()? For me it has been one of the biggest game changers in ProcessWire in recent years ?. Sorry, OT.

Could you please explain how this would look like? E.g you visit /mysite/admin/rest/ ? and that responds with JSON? My feeling is that we already have the tools to do this. Just trying to think of the practical implementation.

Double posting is not allowed. You could have edited the title of your first thread ?. I'll delete the other thread.

Flutter on Windows demo

OK. What is cast_language? The select options field. What is array you need to add to?

@teppo Do you know if this was affecting the frontend as well. weekly.pw has in the recent past been quite slow to load for me. I've just checked now and it loads very fast.

I read this quickly and I don't understand it fully. One thing to note: this <?php if (user()->language->title == 'English') { // } and this <?php if (user()->language->title == 'Deutsch') { // } Will never be true at the same time since $user can only have one language at a time. Why not use if / else if? Even better, since your site is bilingual, the language can just be one or the other, i.e. <?php if (user()->language->title == 'Deutsch') { // German } else { // must be English here } Other than that, I have no idea what you are trying to accomplish ?, sorry.

Hi @pmx, Welcome to the forums and to ProcessWire. Another alternative is to use what can be referred to as template partials. I use Tailwind myself. Recently, I faced a similar situation to yours, with <div> seemingly having to be appended to $content. Below, I'll explain how I got around this. First, to answer your questions: Technically possible but sort of goes against the idea of a delayed output. Also, not easy to maintain if you have to chase your 'echo's when debugging. This is because in the delayed output, /site/templates/_init.php is prepended to the output and /site/templates/_main.php is appended. When you echo in your template file, e.g. basic-page.php, the output of echo comes before the output of _main.php. The idea with delayed output is that you don't echo anything in basic-page.php but defer it for later echoing in _main.php, hence the name, 'delayed' output. Back to the alternative I mentioned above, it might seem a bit complicated and also will result in extra files but it will definitely lead to the separation of the markup, so that you don't have to deal with <div>s in your templates. I have used this approach recently for a demo site for an ecommerce module that I am developing. The demo site can be found here. Please note that the demo site will require Padloper to use. However, I am pointing you to it as an example of the 'partial templating' I am talking about. I don't know how comfortable you are with PHP so, let me know if you want me to explain things further. Below, is an example of how a template products.php is calling and getting markup for a single product. This is the products template. https://github.com/kongondo/Padloper2Starter/blob/main/products.php On this line it calls and gets the markup of a single product to be rendered and appends it to its $content. This line calls a function renderSingleProduct() available in /site/templates/_func.php, which is a shared functions file called in /site/templates/_init.php here. The important part here is that renderSingleProduct() sets a number of variables that the partial template of single product, i.e. single-product-html.php will need. These are $product, $totalAmount, etc. This is achieved by using the ProcessWire class TemplateFile(). For example: <?php namespace ProcessWire; $totalAmount = 7895; $foo = 'foo string'; $bar = 'bar';// could even be a value from a field of some other page $file = "single-product-html.php"; $templatePath = $config->paths->templates . "partials/" . $file; // CREATE A NEW 'VIRTUAL' TEMPLATE FILE /** @var TemplateFile $t */ $t = new TemplateFile($templatePath); // SET/PASS VARIABLES TO THE TEMPLATE // here we create variables and set their values $t->set('foo', $foo); $t->set('bar', $bar); // here, the variable $testVariable will be assigned the value of $totalAmount $t->set('testVariable', $totalAmount); // ------------- $out = $t->render(); // ------ // in a function, return $out. // It will be appended to $content in your template file Written in a hurry and not tested ?.

@thetuningspoon, massive thanks for the POC! @ryan If I am editing a page with lots of repeaters on it (hundreds), would the new lazy loading improve (ProcessPageEdit) performance? This is aside from the current ajax-loading of repeater fields. Are you able to share (a gist maybe?) the script you used to automate the creation of fields, templates and fieldgroups please? It might help others quickly replicate your test install in order to help with testing this new feature. Thanks.

Announcing Flutter for Windows Stable release!

There are various ways to approach this. First, the concepts (being verbose below to help others as well). Everything is a page. Attributes are pages. For instance, Colour, Size, Grade. They are not tied to any product. This makes them reusable and translatable. Attribute Options are pages. For instance, Red, Small, Premium. They are not tied to any product. This makes them reusable and translatable. They are children of the respective attribute pages. Products are also pages. After you enable variants on a product page, you are able to select attributes (Colour, Size, Grade, etc.) that will make up the variants you create. Attributes are added to a product page via a multi page reference field (padloper_product_attributes). Variants are pages. After enabling variants on a product page and saving it, then subsequently adding attributes to the product and saving again, you are then able to generate variants. Variants are generated in a modal. In this modal, you select the attribute options for each of the attributes on the product itself. After generating the variants based on your choices, the attribute options are saved to the variant pages' multi page reference field named padloper_product_attributes_options. This field is not directly editable. Variants are child pages of product pages. Based on the above relationships, as you can probably tell, there are various approaches to finding the available attribute options for a product. The most straightforward way is to go through the variants as they have the exact colours and sizes you want. Things to note here are that there could be lots of variants (like in your case ) and there will be duplicate options to deal with, e.g. Red x Small and Red x Large. <- Two reds. Since you are dealing with lots of variants, I'd go for findRaw(). Below, some example code: <?php namespace ProcessWire; // PREPARE ATTRIBUTES // fields in attributes that we want $fields = ['id', 'title']; $attributesValues = $page->padloper_product_attributes->explode($fields); // get attributes as $attributeID => $attributeTitle pairs $attributes = []; foreach ($attributesValues as $attributeValue) { $attributes[$attributeValue['id']] = $attributeValue['title']; } // ------- // PREPARE OPTIONS // fields in options that we want // @note: for some reason the syntax in the docs pagefield=>['id','title'] always throws an error for me // so, we use the longhand version $fields = ['id', 'title', 'padloper_product_attributes_options.title', 'padloper_product_attributes_options.id', 'padloper_product_attributes_options.parent.id']; $variants = $padloper->findRaw("template=variant,parent={$page}", $fields); // array for final attributes and their options // in our case we expect only colours and sizes $coloursAndSizes = []; foreach ($variants as $variant) { foreach ($variant['padloper_product_attributes_options'] as $options) { $attributeID = $options['parent_id']; $optionID = $options['id']; // ##### $coloursAndSizes[$attributeID]['attribute_name'] = $attributes[$attributeID]; $coloursAndSizes[$attributeID]['options'][$optionID] = $options['title']; } } // your attributes and their respective option are in $coloursAndSizes