Leaderboard

Hi @ro-bo, Yes it is. See the topic below for starters.

I will send out an expression of interest request nearer the time. I haven't yet decided on a criteria for selection. Current plan is PayPal IPN due to its multi-notifications types. However, I may also do PDT, but not 100% sure at this time. No decisions made yet regarding Stripe's implementation. All frontend implementation is up to the developer. You will have the API at your disposal to do whatever you need to do. In the backend/model, orders can have different status (paid, unpaid, complete, partial, etc). Order line items also have individual status (returned, delayed, refunded, etc). This means you should be able to implement a pre-order feature yourself by, for example, marking an order as unpaid, in progress, etc. Padloper 2 does not render anything in the frontend. It is like ProcessWire. There will be no more in-built Padloper templates. You implement Padloper 2 however you wish using the API. I will, however, as part of the technical documentation, write a tutorial on ajaxifying the frontend. In addition, a separate frontend commercial module (fully functional frontend shop) is in the works. Good question :-). Padloper 2 does not utilise a single ProcessWire field, nor any custom ProcessWire fields, nor any ProcessWire pages (except just the one for the Padloper Process Module). All data is stored in custom Padloper tables. Having said that, it uses ProcessWire selectors just the same way you are used to, offering the same security and ease of use you are used to. You won't have to learn a new syntax. In addition, it is fully multilingual (descriptions, titles, etc). I plan to do a write-up of this when I'm done, a sort of 'the making of Padloper 2', the iterations, decision made, etc. No, you won't be able to do this. Not this way. There are no (ProcessWire) pages in Padloper 2 :-). That said you would still be able to use hooks. You've got some very interesting (albeit very advanced) ideas/thoughts there. Whilst not yet planned, when the dust settles, I'd like to further discuss/explore some of these with you. I cannot make any promises as to the outcome. Yes. There are four types of products (housed under Shipment Type). Physical Products that require shipping. Physical Products that do not require shipping (POS, etc). Digital Products. Products that are Events or Services (e.g., booking system). ---------------------- I hope I have managed to answer all your queries. I decided to just do it inline. I might reference some of the responses in the first post if I need to. Thanks.

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

Yes, I did get that but now I realise my example of repeater fields was not clear enough. By complex fields I also meant page fields (page reference fields). @nabo, By complex fields I also meant page reference fields since they don't just output simple values. Either, way there are no such plans. However, a custom FieldType/Inputfield field should be able to accomplish this. All the field would store are the IDs of the product. The Inputfield would display the title of the selected products. In the frontend you can use the Padloper API to get those products using the saved IDs.

@jploch - I have committed those changes to the Tracy repo - let me know if it needs any tweaks.

There is no such plan currently. With respect to ProcessWire fields, are you perhaps referring to complex fields such as repeaters? Apart from such fields, I can't think of any other reason you would need a ProcessWire field for your products. As an aside, to display Padloper products and to have a 'URL for them' you would need to use a template with URL segments, e.g. /products/my-pl-product where products is a ProcessWire page and /my-pl-product is the segment referring to the Padloper product. These will all be covered in the documentation. Yes but they are connected. In a sense, PL users are an extension of PW users. If your store/shop does not require users to register/log in, then such users will not be PW users and neither PL users. Those are considered guest checkouts. Only their order records are kept as per the law/regulations. If they are registered users, then they will be PW users, with authentication processed and passwords stored by PW in the usual manner. They will also be PL users to the extent that they have extra fields/properties, e.g. addresses, tax exemptions, etc. The extra data is stored on the PL side, not PW.

Hi @kongondo thanks for your work, I really appreciate and have waited for a long time ? I'm really excited to test PadLoper2. I have some questions 1) since PadLoper product are separated by PW pages, are you planning to do an Inputfield for select PL2 product? It could be useful if you want to use a richer product page modeling it with PW fields. 2) PL users are different from PW users?

@David Leon Hello, I'm sure you are aware that this forum is for ProcessWire and not Wordpress. There is probably someone here who has some experience of running Wordpress, but that's not me so I can't help directly. Have you had any success asking about your issue on any Wordpress forum? Hope you manage to get this sorted out.

Ok, it works now with this code: <?php foreach($page->children() as $child) { echo "<div class='column column-block'> <div class='row'> <div class='large-12 small-12 columns'> <div style='border: 1px solid black; padding: 0px !important;'> <div style='width: 100%; background-image: url({$child->projekt_main_image->url}); background-size: cover; background-position:center center; height: 400px;'></div> <div style='text-align:center; background-color: black; color: white; padding: 10px 10px;'> <h4><strong><i>{$child->title}</i></strong></h4> </div> <div class='row' style='margin-top: 20px; margin-bottom: 20px;'> <div class='large-4 small-4 columns' style='padding: 10px; border-right: 1px solid black; text-align: center;'><div style='text-transform:uppercase;'>Tops gesamt</div><div style='font-size: 3.5rem;'><strong>{$pages->count('template=tops')}</strong></div></div> <div class='large-4 small-4 columns' style='padding: 10px; border-right: 1px solid black; text-align: center;'><div style='text-transform:uppercase;'>Tops zu mieten</div><div style='font-size: 3.5rem;'><strong>{$pages->count('template=tops, projekt_top_vermietet=0')}</strong></div></div> <div class='large-4 small-4 columns' style='padding: 10px; text-align: center;'><div style='text-transform:uppercase;'>Tops zu kaufen</div><div style='font-size: 3.5rem;'><strong>{$pages->count('template=tops, projekt_top_verkauft=0')}</strong></div></div> </div> <div class='row'> <div class='large-8 small-centered columns' style='text-align: center;'><a href='{$child->url}' class='button expanded rounded' style='background-color: black;'>Alle Informationen</a></div> </div> </div> </div> </div> </div>"; } ?> Now the fields are summed up, which are supposed to be summed up. This means he sums up the fields from all pages under "Projects". Home - Projects - - Project 1 - - - TOP 1 - - - TOP 2 - - - ... - - Project 2 - - - TOP 1 - - - TOP 2 - - - ... - - Project 3 - - - TOP 1 - - - TOP 2 - - - ... How can I differ between the different pages under "Projects" by its parent? I tried it with "has_parent=$child", as the template is set in "Projects"! Thanks a lot!

Thanks @kongondo. It works both ways, but it's better to use your way, because then I can load the PDF module only when I need it.

@adrian Currently the page tree doesn't show if a page is protected, is it possible to show this information somehow? Maybe add a locker icon or something? Similar to Unpublished pages that are striked through to show that they are, well, unpublished.

Hi here, I think I misunderstand how it works. I just saw that google crawled a website, and all page title look like that in google: `inherit | mysite.com` ?‍♂️? In first instance I had that code in _init.php : // page title fallback $title = $page->get('my_seo.meta_title|title'); // fail, it output 'inherit' modified to : // page title fallback $title = ($page->get('my_seo.meta_title') === 'inherit') ? $page->title : $page->my_seo->meta_title; // ofc it works How other dev do ?

Here is a script I made for the import of thousands of customers. You have to save this as shell script (f. e. sync-customers.php.sh), make the script executable and execute it via command line (./sync-customers.php.sh).

@jploch - can you try the attached version please. Sounds strange, but it's actually a bit more complicated than expected just because there are a few ways that the bar can be enabled / disabled / hidden. I think I might have them all taken care of, but would be good if you could help test. Thanks. BTW, the class I added to body is: has-tracy-debugbar TracyDebugger.module.php

@Philipp It's only a timestamp if you choose no output-formatting in the datefield settings, otherwise it's a formatted string. That's why I always use getUnformatted(). It always works and I can use the standart formating set in the settings.