Leaderboard

News Update - 10 October 2018 I know many of you are eagerly awaiting the next version of Padloper. I thought I'd give you a couple of updates regarding progress. First, I'd like to thank you for the feature requests and your support. As previously stated, it will not be possible to accommodate all requests and those that may be accommodated may have to wait till other releases. OK, to the update. The following have so far been achieved. FieldtypeProducts A new Fieldtype for storing products including their variants, if any. This allows for easy retrieval and storage of data and and API that makes it easy to filter, search, manipulate, update, etc product details. So..: $foo = $products->find("colour=red,quantity<10"); $bar = $product->first(); echo $bar->size; echo $bar->price; // etc Discounts We have a new discounts class that allows for 4 types of discounts each with generic and specific requirements. Percentage discount Fixed amount discount Free shipping discount Buy X Get Y discount In turn, as applicable, the discounts are subject to generic conditions including customer country,named customers, customers subscribing to your newsletter, global usage, customer usage limits, customers who abandoned carts, start/expiration dates, etc. There are also discount-specific conditions including whether to apply discount to entire order, specific products or specific categories/collections, minimum requirements (purchase amount or quantity of eligible products in cart), etc. Import/Export Products This class allows for importing products into your shop as CSV, JSON or arrays. It is 98% done. It will also allow for exporting products as CSV (and maybe in future, as JSON, if there is demand). MarkupPadloper This is WIP to eventually replace PadRender. This allows for retrieving products, product tags, product categories, etc, either as ready-to-render (i.e. includes the markup) vs retrieving the raw product details so one can use their own markup, anywhere, anyhow, to output products. Other A bit of work on customer notifications (including email templates) and FieldtypeOrders for orders plus some other stuff. I got a lot to do, so I better get cracking! ? Thanks for reading.

Everything sounds awesome! ? Maybe that's unnecessary to say, but please also reserve some time to do proper docs. I'm just afraid that things can get quite complex ? thx!

The reason (at least how I read ryan's responses to questions about the options field type) is that more often than not, a page field is the better (i.e. more flexible and extensible) solution when you want to allow the user to make a choice. Having the field type installed by default would probably tempt users to start using it right away without learning to appreciate the power and ease of page fields. There are a few use cases for the options field type, like simple dropdowns in frontend forms (that's where I use them). But a page reference field supports drag&drop reordering of options for editors, it's easy to give the template for the selectable pages a PHP template too to list all pages with that option, you can publish and unpublish "options" without deleting/adding them, regular editors can do that (and add/remove options) without a need to mess with the field's configuration, and the API side is much more intuitive and flexible too...

Thanks, i just implemented it and it works perfectly. Third day into PW and I'm already sold for good ? Thinking about it, I actually find it useful to use the parent pages to display the available sub-categories, so it's a win-win. I ended up using the following structure: Home |-- People |-- Person 1 |-- Person 2 |-- ... |-- Categories |-- Category 1 |-- Category 2 |-- ... People and children are hidden. Each category page uses a "category" template that displays a table with all people that have a populated field for that category. No custom backend required, just the admin interface - loving it.

Definitely! Good point.

https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/config.php#L184

To answer the question myself, in order someone else may find this useful: It was "convert div tags to paragraph tags" blowing up on me. Thanks nevertheless ?

Hi all, I have posted this in the VIP support forum of Padloper as well. Some of you do not have access to that board so posting here as well. Hopefully it doesn't count as spamming?! In June 2018, Antti announced that he was looking for a new product owner for Padloper. Sometime after, I had a fruitful discussion with him about my vision for the project if I was to take over. We agreed that commitment, motivation and a concrete plan were all important ingredients for the continued success of Padloper. I would like to officially announce that I am now the product owner and lead developer of Padloper. For those who may not know, I am the author and maintainer of several ProcessWire modules, both free and commercial. I am also a moderator in the ProcessWire forums. I would like to share with you a number of things regarding what’s going to happen next. This will be a long read. First, I would like to thank Antti for developing a great product. A lot of man-hours, dedication, passion and love has gone into making Padloper what it is today. Secondly, I would like to thank all users of Padloper. A great product is nothing without active users utilising it, putting it to the test, reporting bugs (even offering possible solutions) and proposing new features. So, thank you for helping make Padloper great! Support Thousands of hours have gone into developing Padloper. Although the code is well-written and easy to follow, Padloper is a big application with many moving parts. As such, it will take some time before I can fully grasp its inner workings. To make this transition as smooth as possible, Antti will help me with support for Padloper for some time. Currently, Padloper has a dedicated support forum. This is an arrangement between Ryan and Antti. The support forum works great as it allows the opening of multiple support threads to cover different issues. I have yet to speak to Ryan whether this arrangement can continue. However, given that I have other pro modules that I support in the open forums, it is unlikely that I will be requesting Ryan to let Padloper’s dedicated forum carry forth. A dedicated forum for one of my pro modules and open forums for my other pro modules will lead to confusion and questions from users of those other modules. Hence, Padloper support in the forums will move to the open forums. The disadvantage here is obviously the fact that support will be offered in one single (and maybe massive) support thread. To get around a ‘single thread support forum’, I am thinking of developing a simple online support queue system for all my modules. Meanwhile, support will continue in a new single thread and via email. Roadmap This list is neither exhaustive nor cast in stone. Its aim is to give an overview of my plans for Padloper. · Padloper 2 – a new major release · New backend for Padloper · Optional pro frontend module for Padloper · Documentation · New payment modules Let’s talk a bit about this list. Padloper 2 Release Padloper 2 will be a major release that incorporates a new, central backend shop for Padloper. This will be a new process module that pulls from the existing parts of Padloper (data models, etc) into one interface (more on this below). This version will also be extensible in the frontend, allowing for the plugging in of a new, optional, commercial frontend shop (full featured shop profile). Padloper 2 will not support the current ‘any page can be a product’ paradigm. Technically, products will still be pages. However, all products will utilise the same Padloper template. These will be invisible to the shop users themselves (e.g., hidden in admin tree). Only superusers will have full control of the Padloper system stuff. Support The current Padloper will continue to be supported until the new Padloper 2 is released. New features will be included in Padloper 2 only. Once Padloper 2 is released, legacy Padloper will only receive security fixes. All other support will cease. Upgrade There will be no upgrade path from the current Padloper to Padloper 2. Although their underlying architecture is the same, making sure that everything works in different setups and environments will be time consuming. However, for those who really need to migrate, if time allows and for an agreed fee, I could develop a custom script for the migration. Backend A new backend interface will be the major visual difference between the existing Padloper and Padloper 2. It goes beyond visual differences though. The new backend will be the single gateway for managing all shop-related features, both current and new ones. The backend will unify and include: · Easily add shop products. · Ability to add as little or as many custom fields to products as required (title, SKU, price, discount field, image/photo, description, categories, tags, etc). · Discounts manager (including auto start/expire discount codes). · Customers manager. · Invoices manager. · Taxes management. · Payment gateways manager. · Improved digital products management. · Stock management. · Manual order creation. · Graphical sales report. · Customer support. · Access-controlled shop editors/staff. · Dashboard for shop metrics. · Shop settings. · Product variations. · Import/export products as CSV or JSON. · Products search/filter. · Etc. Users will be able to turn off backend features that they do not need. This will enable a more streamlined experience for users. I plan to release Padloper 2 within 4 - 6 months, hopefully sooner. This is a major undertaking, hence the timescale. Please note that the first release of Padloper 2 will not include all of the above planned features. The idea is to build incrementally, adding new features in minor updates, focusing on stability, usability and security. Frontend Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy. The frontend shop profile will feature an ajax-powered shopping cart and a customisable ready-to-go theme. Pricing Model There are no plans to change the current prices of the 3 Padloper licences (Single, Developer and Agency). However, in order to continue to provide Padloper as a stable product with great features, it is also important that it remains a competitive and financially sustainable project. In order for this to happen and to also bring Padloper in line with my existing pro modules, the pricing model itself has to change. Starting from Padloper 2, the pricing model will shift to an ‘annual subscription’ model rather than the current ‘lifetime licence model’. I am fully aware that there are different opinions for and against annual subscriptions. However, I believe that this model is the most equitable approach that suits both the developer and the clients. The annual subscription will allow users (licence holders) to get 12 months of free VIP support for Padloper as well as future updates available within that time period. After the 12 months, users will be able to renew (online) their subscription at a discounted cost (worked as a fraction of the full purchase price) for a further 12 months (perpetually). Users will be able to continue to use Padloper for life even if they don’t renew their subscriptions. Upgrading current licences to Padloper 2 will be a paid upgrade. Current users of Padloper will get an attractive discount. This will be a time-limited offer (maybe a couple of months) that will start with the release of Padloper 2. New customers will pay the full price for Padloper 2. I hope the planned features are reason enough for you to consider upgrading to Padloper 2. Payment Modules I will be taking over as the maintainer and lead developer of the existing payment gateways (Payment base class, PayPal and Stripe). New payment modules are also planned. Payment modules will continue to be free. However, only ProcessWire 3+ support will be provided going forward. Padloper Domain and Future Downloads I have also taken charge of the Padloper domain. Within the next 12 months, purchase and download of Padloper will shift to processwireshop.pw. Please note that this is not the official shop for ProcessWire! It just bears a name that reflects its product offerings ?. Eventually, traffic to padloper.pw will redirect to processwireshop.pw. Feedback I would love to hear your thoughts about the upcoming changes and any feature requests you might have for Padloper 2. Whilst I cannot guarantee that any request will be implemented, I can promise that I will thoughtfully consider all feedback. Thanks for reading and thank you for supporting Padloper! kongondo

This might be relevant:

Uh, I'm not sure I follow. The new Padloper can already do all the things I listed above as achieved :-). We already have a fully functioning discounts class. I've edited my post above to be more clear.

This issue reminds me of a similar one: https://github.com/processwire/processwire-issues/issues/650 What created dates do you have in the database for the missing images? Do you have records in the field's table for those images at all?

+1 I'm also the kinda guy who does not like any bloat. I think one readable "dark theme" and one "light theme" would be enough to choose from.

Status update: Release 0.1.3 I finally managed to implement hiding libraries from the page tree as requested in the issue tracker. This can be enabled in the module configuration and optionally extended to superuser. Deletion of libraries is now possible through the Media admin page.

Thank you for the information! I used the "LDAPsignin" module as base and extended it to work with an Active Directory - including group assignments and some other upgrades. I think it doesn't make sense for me to publish the changes because it is customized for our AD environment ?

$page->fieldgroup->getField() does work for me. And no, $page->title is a property that does return a string and is not the field object. Since the field is in context of the template/fieldgroup it seems natural you get the field settings through it.

$page->fieldgroup... ?

That should help https://gist.github.com/somatonic/8323844

Great news. Thanks Kongondo!

For me: No, sorry. I don't get it or maybe I'm misunderstanding it. Do you want to add some css modules on the fly in the frontend when you are using some markup (eg add slider.css when using a slider html block)? Markup regions could then be a solution: <region id="slider"> <div>your slider markup</div> </region> <region pw-append="styles"> <link rel="stylesheet" type="text/css" href="slider.css" /> </region>

Hi, I wouldn't include all the themes, I think 135 kB is already too much to add to the TracyDebugger. Like I said it was only a case of changing a few color combinations to take away the harsh look of it for someone's set of eyes. Tweaking the theme-tomorrow_night.js was all I needed and I am happy with it. (maybe a hint where I can change the font-size ?) I agree, I would leave out showing comments about code documentation. A 2 Mb payload is way too much and besides I don`t see it will add effectively to the coding learn process. I guess it will only be consulted for some details. I reckon that effective resources for a coding learn process will always be snippets, the forum, http://processwire.com/docs/----- and http://php.net/manual/en/------ Remember that some time ago there was a discussion in the forum what strategy is being used for keeping an online website in sync with your local laptop copy ? All kinds of strategies were discussed and one of them is editing the online website parallel with the local copy on your laptop. So when something is edited in the local copy, all that is needed is to copy and paste your edits into the editor of TracyDebugger. I think that is still one of the fastest ways of keeping a website in sync.

That's perfectly fine. It doesn't matter and it is not an issue. Devs do this all the time. That's OK. By the way, you'll find that 'all PW fields' are in a sense custom DB tables :-). By this is meant that there is no field that is actually required (yes, even the Title field, although by default it is marked as a required field in templates :-)). I get your point though - you don't want to create a custom field. Definitely! At its most basic usage, a page is basically an entry (a row) in a database table called 'pages'! :-). Yep. I suggest you read this classic post: OK, some code (untested). Example code to use in your Results page template file. // results page // will hold our output $out = ''; // get categories {limit and use pagination if you have lots of categories} $categories = $pages->find("template=category,limit=10"); // make sure we got categories if($categories->count()) { foreach($categories as $category) { // @note: use limit if you have lots of 'people'. // assumes the page field in the 'people' template is called 'category' $people = $pages->find("template=person,category=$category"); // skip category if it has no 'people' OR you can just output below 'no people/users', etc if(!$people->count()) continue; $out .= "<h2>{$catergory->title}</h2>"; // list users under this category // newish pw api rather than another foreach here. // @see: https://processwire.com/api/ref/wire-array/each/ $out .= '<ul>'; $out .= $category->each(function($c) { // append any applicable data you wish here; e.g. $c->bio (if people have a textarea biography field, etc) return "<li>$c->title</li>"; }); $out .= '</ul>'; } } // print out the output echo $out; That should result in something akin to: <h2>Category 1</h2> <ul> <li>Person 1</li> <li>Person 2</li> <li>Person 3</li> </ul> <h2>Category 2</h2> <ul> <li>Person 1</li> <li>Person 3</li> </ul> <h2>Category 3</h2> <ul> <li>Person 2</li> </ul>

Hi @zoeck Sorry I missed your post previously. If you are still looking for LDAP integrations there are 3 that I know of... LdapSignIn from Conclurer. KreativMonkey's LDAP Helper. JimYost's LDAP Authentication module posting on the forum, though you might want to go with Apeisa's implementation further down the thread. ...but I suspect you've written your own by now ? Hope that helps.

Just go to Modules > Admin and install the Select Options Module, then you can select it in the list of available Fieldtypes

Hello, there is also one "alternate" solution, using Node.js and Puppeteer with headless browser. In this case, export to PDF is only one segment what can be done with that tools (remote login, automated processing, deep testing, etc...). If you have Node.js on your machine, here is example (Windows) where project directory "printer" is in C partition (C:\printer). C:\> mkdir printer cd printer npm i puppeteer easy-pdf-merge After this, inside project directory are all required node modules (Puppeteer, Chromium browser, Easy PDF). Last step is to create index.js file and place it inside project directory ( C:\printer ) // index.js const puppeteer = require('puppeteer'); const merge = require('easy-pdf-merge'); // configuration // *** EDIT THIS: var admin_url = "http://my_site.com/admin_url"; var user = '*****'; var pasw = '*****'; // desired pages // *** EDIT THIS: var pdfUrls = [ "/page/edit/?id=1054&modal=1", "/page/edit/?id=1016&modal=1", "/page/edit/?id=1019&modal=1", "/setup/field/edit?id=1#inputfieldConfig", "/setup/field/edit?id=1&modal=1#inputfieldConfig" ]; var pdfFiles = []; // START async function main(){ const browser = await puppeteer.launch({headless: true, args:['--start-maximized']}); const page = await browser.newPage(); await page.setViewport({width: 1366, height: 768}); // login await page.goto(admin_url, { waitUntil: 'networkidle0' }); await page.type('#login_name', user); await page.type('#login_pass', pasw); // login submit await Promise.all([ page.click('#Inputfield_login_submit'), page.waitForNavigation({ waitUntil: 'networkidle0' }) ]); for(var i = 0; i < pdfUrls.length; i++){ await page.goto(admin_url + pdfUrls[i], {waitUntil: 'networkidle0'}); var pdfFileName = 'page' + (i + 1) + '.pdf'; pdfFiles.push(pdfFileName); await page.pdf({ path: pdfFileName, format: 'A4', printBackground: true,margin: {top: 0, right: 0, bottom: 0, left: 0}}); } await browser.close(); await mergeMultiplePDF(pdfFiles); }; const mergeMultiplePDF = (pdfFiles) => { return new Promise((resolve, reject) => { merge(pdfFiles,'processwire.pdf',function(err){ if(err){ console.log(err); reject(err) } console.log('Success'); resolve() }); }); }; // run all this and exit main().then(process.exit); *** Note: edit this script and write your login parameters and desired urls. After all, run script (inside C:\printer>) node index.js After a while (for this example, ~10 sec.) you will find PDF files in project folder (partials and 1 merged with all). As example here is attachment. Regards. processwire.pdf

It doesn't look like they are massive (size), so, maybe yes, one or two more. I'm happy with the dark theme, so I am biased ?.

...thanks for sharing, diogo, beautiful site.

This one's not really new, but I forgot to post about it when I did it, plus there are still some unfinished aspects. I have a minimal personal invoice setup allowing me to have multiple identities for my invoices, to represent the different aspects of what I do (it's not all PW)... The child pages of an identity represent permissible payment methods for that identity... Of course, there are multiple clients under which invoice pages are stored, with highlighted status in the page tree... Invoices use repeater fields to store line-items and expenses. The line subtotal is calculated on save. The whole invoice value is worked out too. Profit and Loss is yet to be finished. And here's the result... I like PW!

Really love this function

I also changed the permissions of the /tmp folder to 777 just to see if that would fix it. Still not working.

Last night my cat bit my hand for no apparent reason while he was sitting in my lap. He's a very friendly cat, but also very old and I think may be getting a little senile. It was a deep bite, though didn't seem like all that big of a deal. But this morning my hand was hurting pretty bad, then it swelled up, and then a swelling red line appeared on my skin that went from my hand to my shoulder. I went to the doctor and he said it was a bad one, and if I hadn't come in today I would have been in the hospital tomorrow. Apparently cats have some mean bacteria in their teeth and these kinds of cat bites can get pretty bad, quickly. They shot me with a bunch of antibiotics and now I've got to go see another doctor and get an x-ray because they think that there's a possibility the cat's tooth broke off and may be stuck inside my hand (I hope not!). If the antibiotics do their thing, all should be fine in a few days. I'd planned on writing a blog post today about ProcessWire 3.0.115, but it looks like that's not going to happen (and one of my hands doesn't work so well), so I'll write about it next week in combination with 3.0.116 updates. But if you want to see what's new in 3.0.115 before that, be sure to check out the dev branch commit log. Thanks for reading and have a great weekend!