kongondo

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

Yes. Works for me. Good catch ?.

Now it does, thanks ?. Thank you very much for the very clear and detailed explanation. My confusion is over ?.

Great timing then @alexmas I recently updated the demo to actually show the available colours and sizes of variants. I will update the repo soon. Later today, I'll also write some code here to look at since the demo one is a bit opinionated.

Thanks @horstfor enlightening me. Some of the confusion is gone. I still don't get why you would version a field or template (not template file) though ?.

Hi @alexm. Just to be clear, do you mean you want to list all the available colours and available sizes of a selected product? E.g Product A is available in Black, Red, Purple, etc. and Small, Medium, X-Large?

I have been reading these posts with great interest but also a great deal of confusion. It seems that there are maybe 3 conversations going on simultaneously. Or maybe they are one and the same (or sides of the same 3-sided coin ?) and it is me who is not getting it. I suspect the latter. #1 Conversation 1: Create fields and templates quickly using a configuration file. #2 Conversation 2: Deploying sites from local to production. #3 Conversation 3: Versioning fields and templates. It is #3 that I don't understand at all. Maybe this is because I always use #2 in my 'deploy to production' strategy. This is not a criticism against #3. I genuinely don't understand why you would need to version templates and fields (but especially templates). I have read most of the posts but it is still not sinking in. Could someone please briefly explain this (i.e., why one would want to version templates and fields)? By versioning a field, for instance, does it mean that if the field label or description, etc. changes, that you need to be able to roll back those changes? Something more complicated than that? Please don't' laugh ?.I am probably exposing my ignorance here but happy to learn ?. Thanks.

Shopify has several APIs for this with multiple SDKs. Have a look and choose one that suits you.

Excellent! Please post (start a new topic) in this new support board whenever you are ready, thanks.

Please note that Padloper 2-related pre-sales support has been moved to its own sub-boards in the open forums. Please read the pinned topic 'About this Board' in the board. Thanks. https://processwire.com/talk/forum/62-padloper-pre-sales/

Done! ? Thanks. https://processwire.com/talk/forum/62-padloper-pre-sales/

This is a temporary board for Padloper 2 pre-sales issues. Is is intended for general pre-sales questions and more specific Padloper 2 topics such as technical/coding questions, bug reports, documentation, feature requests (wishlist) or anything related to Padloper 2. For paid support for Padloper 1, please continue to use the existing VIP Support Board. This open board for Padloper 2 is necessary as it allows non-Padloper 1 users access to a support forum. Please note that once Padloper 2 is officially released, these boards will likely be merged into one. VIP Support will continue but it may happen in an open board with priority given to those with active subscriptions. Padloper 1 topics would be archived (but accessible). Thanks.

Hi @alexm. Pete is currently helping me with this. Hopefully this week, we'll have a 'pre-sales' forum that anyone can access. We'll use that for issues, wish list, etc. Ideally, we could have done issues in GitHub but Padloper is not an open project. Both pagination and lazy-loading have not yet been implemented. They are high on my todo list, especially the latter.

Since you cannot get access to your developer and since it seems you will not be getting a replacement developer for this, I would suggest, albeit with caution/caveats, that you take over the current superuser account. This will mean changing the following: The current superuser password The current superuser email If needed, the current superuser username 1 and 2 are more important. 1, since you need to be able to log in and 2 since you want ProcessWire to send messages (when needed) to an email account you have access and control over. The above requires that you have access to the ProcessWire files. This can be either via FTP or CPanel. In any case, you need to be able to edit at least a template file. Please let me know. Please don't post your FTP/CPanel details here ?. At this point, we just need a yes or no response if you have access to files. By the way, if you'd rather discuss via PM, please feel free to message me here in the forums.