Leaderboard

Lister Selector A Process module that uses Lister/ListerPro, but with a selector string input instead of the normal InputfieldSelector filters. Features For power users, typing a selector string is often faster and more intuitive than fiddling with InputfieldSelector. It also lets you copy/paste selector strings that you might be using somewhere else in your code. Allows the Lister rows to be sorted by multiple fields (not possible in Lister/ListerPro) Allows the use of OR-groups (not possible in Lister/ListerPro) If ListerPro is installed you can run ListerPro actions on the listed pages - the available actions are defined in the module config. Bookmarks can be configured in the module config and accessed via the flyout menu for the module page. For your convenience you can copy/paste a bookmark string from the note at the bottom of the Lister Selector results. Usage Type your selector string on the Selector tab. The selector is applied when the "Selector string" field is blurred, so hit Tab when you have finished typing your selector. Unlike Lister/ListerPro, you can't sort results by clicking the column headings. Control the sort within the selector string instead. Superusers can jump to the module config (e.g. to create a bookmark) by clicking the cog icon at the top right of the module interface. The module is mostly intended for use by superusers, because in most cases site editors won't understand the ProcessWire selector string syntax. If you want another role to be able to access Lister Selector then give the role the "lister-selector" permission. Only superusers can define bookmarks because in ProcessWire module config screens are only accessible to superusers. Screenshots Process page Module config (when ListerPro is installed) Advanced If for any reason you want to create dynamic bookmark links to Lister Selector for a given selector you can do that like this: /** @var $pls ProcessListerSelector */ $pls = $modules->get('ProcessListerSelector'); // Define selector $selector = "template=foo, title%=bar"; // Define columns (optional) $columns = 'title,modified'; $pls_link = $pls->getProcessPage()->url . '?bm=' . $pls->urlSafeBase64Encode($selector . ':' . $columns); echo "<a href='$pls_link'>My link</a>"; https://github.com/Toutouwai/ProcessListerSelector https://modules.processwire.com/modules/process-lister-selector/

Hey everyone, there is a new module AppApi available which is based on my original RestApi module but has some additional features which are really cool! I have been struggling to find time for the RestApi module over the course of the last 1+ year, so I'm really glad @Sebi is stepping in and doing work in this area. I think it would be a good idea, to see AppApi as a successor of the RestApi module and put all focus and development efforts there. What do you guys think?

https://maquiladorademuebles.com/ Here I did a very rough integration of the Shopify Js SDK with ProcessWire, so that I could add more specific things to each product, when I talked to the client it was more important to have the potential to have more flexibility when uploading the product's content so we went this way of using Shopify inside PW. My first mistake was rolling my own Js integration when I could have just used the Buy Button SDK (instead I used the Js SDK with Vue). Second mistake. One thing I didn't anticipate that turned into a mess: discounts. I had to setup fields in Pw where I had to set the discounts (after setting them up on shopify), so a lot of double data entry on some cases. I've done also things the other way around, setting up ProcessWire as an application that launches within Shopify, so that I could use PW pages as extra content management for Shopify product pages. (very complex product descriptions) unfortunately the project I did this for never launched. Agree with @Pixrael the Shopify API is really easy to work with.

Thanks for alerting me to this. In v0.1.0, if you didn't supply a limit as part of the selector string then all the matching pages are listed, which strictly speaking is the correct result. But it seems that Lister doesn't expect this scenario and renders pagination numbers as if a limit of 25 was supplied. Clicking these numbers doesn't do anything though because actually all the pages are already listed. But I think for most cases it's best to for Lister Selector to apply a default limit of 25 if none is supplied in the selector string - that way it's more in line with how Lister and Lister Pro behave. So I've changed to this in v0.1.1. And if you want a different limit you can supply it in the selector string (and you can use limit=0 if you want to see all results at once, but be aware that Lister will then render the incorrect pagination once again).

@Robin S Excellent module! Thanks. I have just tried it, and I noticed that the pagination doesn't work. It still works with all other Lister Pro instances. Is this intentional (same as with not being able to sort by clicking on table headings) ? Clicking on any of the pag. numbers actually loads the AJAX file, i.e. I see XHR finished loading: POST "https://mysite.com/admin/setup/lister-selector/page2". Google Chrome, Win 10, latest PW version, no JS/console errors.

@MoritzLost No more doing codes past 3am for me that's for sure. hahaha. Thanks, Moritz.

Hey Thomas, first of all: thanks for your all the effort you put into the RestApi Module. I've seen the AppApi Module recently and I think it would be good to focus on it. keep it up.

The multi-step form option is already in the module, so it can definitely be used for implementing surveys with relative ease.

Love ya! Thank you so much!

This is fixed in the latest release (SearchEngine 0.25.2).

I got this too, and it seems to happen when passing fraction values to getBlurhashDataUri() - these were calculated for an image ratio (e.g. $height = $width * 0.35). If you're doing this, try passing whole numbers, or rounding the calculated dimension first (using floor, round, ceil functions): $image->getBlurhashDataUri(95, floor(95 * $ratio));

Hello @Roych, Ryan was working on a multi-step/page enhancement to form builder here. I don't know what the status is since I haven't used form builder. Maybe this is a good starting point for your requirements.

I've released v0.2.3 to add some support for this. v0.2.3 1. Adds a setting to the module config: "Name stub classes for compatibility with custom Page classes". This option names the template stub classes using the same format as for custom Page class names. A side-effect of this is that your IDE may warn you that multiple definitions exist for your custom Page classes. This is because the stub class files generated by this module will always be distinct from any custom Page class files you create (overwriting the actual Page class files is not on the table for this module). If you enable this option then you'll indicate the class name for $page in your template files like this (using the home template as an example): /** @var HomePage $page */ 2. For new installs the default path for stub files is now "/site/templates/AutoTemplateStubs/". This path is still configurable though.

... ...and show it visually! Following is a snippet, not a tutorial. But maybe it is useful for someone. Everyone knows the possibility to define a checkbox as required. However, a submit button would then visually execute the click movements and show the active color on hover. Depending on the status of the checkbox, you can either disable the functionality of the submit button via CSS ( pointer-events: none; ), or display a not-allowed cursor. But IMO, each of the two is asking for the other. If you embed the button in a wrapper element, you can marry both of them together. <fieldset class='gdprconsent'> <input type='checkbox' name='gdprconsent' id='gdprconsent' required='required' autocomplete='off' /> <label for='gdprconsent'>I agree to the privacy policy.</label> <div class='submitWrapper'> <input type='submit' name='submit' id='submit' value='Submit'> </div> </fieldset> #gdprconsent:not(:checked) ~ div.submitWrapper { cursor: not-allowed; } #gdprconsent:not(:checked) ~ div.submitWrapper > input[type='submit'] { pointer-events: none; } #gdprconsent:checked ~ div.submitWrapper > input[type='submit'] { cursor: pointer; }

I really have a Shopify class implemented, but basically you can do this as simple as: // https://shopify.dev/tutorials/authenticate-a-private-app-with-shopify-admin $key = "yourkeyhere"; $pass = "yourpasswordhere"; $store = "yourstorename"; $data = array( "since_id" => "632910392", // Retrieve all products CREATED after the specified product (by ID) "fields" => "id,images,title", // include only this attributes in the response ); // Is better to use try/catch here $http = new WireHttp(); $response = $http->getJSON("https://{$key}:{$pass}@{$store}.myshopify.com/admin/api/2020-01/products.json", true, $data); // True to get an array, False for object $products = $response["products"]; if (count($products) > 0) { foreach ($products as $product) { echo $product["title"]; // direct output or save to a custom array to use in views, etc. } } // use the id field for the Buy Button js code in order to have the cart/checkout in your site

Yes, of course ... check the documentation page, you can get all or just one product, create a new one, modify it or delete it etc. PRODUCT: https://shopify.dev/docs/admin-api/rest/reference/products/product You can do this simply using WireHttp, I think if you want to add much more information to the product than Shopify allows or to relate it directly to other PW pages, then it makes sense to have a copy in PW and keep the synchronization between them, but if you only want to display products in a section of your website like a regular store only for selling, then you can simply query the API from your template file and process/display the answer on your website. When you check the DOC page you will see very clear examples of how to use the queries, you will see that you can use filters, and the answer is JSON that you can easily manipulate in PW. For the synchronization issue you can export the list of products to a CSV file and import it in PW, in my tests I used Ryan's module and it worked perfectly. Shopify also has Webhooks that allow you to update PW from Shopify according to events in the store such as new product, modifying or deleting it, new order etc. WEBHOOK: https://shopify.dev/docs/admin-api/rest/reference/events/webhook In other words, there are many ways to interact with Shopify and they are all very simple, well.. it seems to me, that I'm a graphic designer and not a professional programmer.

I hate hate hate hate (repeat however many times you would like) to say this, but WooCommerce is my weapon of choice for eCommerce. For the level of my client base, they are on the understanding that if I say I am not doing that with this software and you would need something more highend and secure, then they are ok with the functionality. That will be the only time you will ever hear me talk WordPress on here (until the new Padloper comes along). But, I did check out the module by @Gadgetto that @bernhard was talking about, and it is impressive. Yes you can plug everything into the frontend yourself with Snipcart, but the backend integration is lovely. If you are worried about the fees, then in my experience, you have a product that has too many competitors and there will always be somebody out there undercutting you. Just roll something out with a slightly higher price otherwise, test the water and adapt from there.

@ceberlin @3fingers As of 0.12.0 SearchEngine now supports multi-language indexing and searching. This is based on the native language features, so the results you see depend on the language of current user etc. While I don't have a good test case at hand right now, I did some quick testing on one of my own sites and it seemed to work pretty much as expected – though please let me know if there are problems with the latest version ? What you need to do to enable this is convert the index field (which is by default called search_index) from FieldtypeTextarea to FieldtypeTextareaLanguage.

I have not used Padloper yet, but I built a custom shop lately and it's a LOT of work ? The problem is not the payment integration, the problem is handling all the user interactions (shopping cart, taxes, product variations etc). So it depends a lot on your scenario. If you only want to collect donations without any other features, then you might not need padloper (but then you could also just use a payment button from one of the providers)