Leaderboard

New "Adminer" database GUI panel just added. A huge thanks to @Robin S for making me take another look at this long forgotten tool and for helping with many suggestions regarding the implementation in Tracy and debugging several issues. There is one outstanding one on his local Windows dev setup that I can't reproduce at all and he also isn't seeing on a live server. He is getting session_start / headers already sent error. Could someone else on Windows (maybe @bernhard) take a look and let me know if you have the same problem as well. Actually Robin - any chance you are running the SessionHandlerDB modules on that local setup? The color scheme is configurable in the Tracy settings. I have used this already on a live server to help debug something and it would have taken much longer to go find the cpanel credentials, and navigate my way to PHPMyAdmin. This logs you in automatically and is virtually instant. I am away for the next 10 days so if you find any problems, they will most likely have to wait till I'm back. Hope you find it useful!

@ryan Could you please dedicate a page or two in the new documentation to Adrian's Tracy Debugger module? His module has become so powerful that it would be a big oversight not to highlight it in the docs. Just look at this brand new feature: ProcessWire + Adrian's Tracy Debugger combo is second to none!

That result in a 500 server error. I changed it to the following and now I'm getting the proper time on backend's creation, modification, installation times etc. $config->dbInitCommand = "SET NAMES '{charset}', time_zone = '+02:00' "; Your DatetimeAdvanced module helped me with that ?

I can't wait to build my first E-commerce site using Padloper ? - Great Job @kongondo

No worries. Big thanks for adding Adminer to Tracy and enjoy your time away.

I think I might have found the source of this issue. It seems to relate to debug mode in /site/config.php. When debug mode is on I get the session warning and when it is off I don't. Can you confirm @kongondo? @adrian, this fix isn't working reliably for me. If I visit the "MySQL" root item in the breadcrumbs, then browse into a database table, then click the database name in the breadcrumbs I get a 404. I wonder if the simplest thing might be to reverse your previous fix and make a small modification to adminer-4.6.3-mysql.php: on line 531 change "&db=" to "?db=". Seems to work well here for both the Process module and the panel. BTW, the adminer-4.6.3-mysql.php file is pretty horrible. I get why the project owner wants to compile everything into one file but it results in some weird encoding (PhpStorm gives encoding warnings when the file is opened and is liable to auto-save the file and mess it up in the process) and it's very difficult to debug. Do you think it would be feasible at all to do a custom compilation of the source to make it a bit more readable and leave out the lzw compression?

I wasn't clear. I meant customer addresses, emails etc should not be editable in the order. However, I now see your point about the need to edit an address, e.g. a customer entered the wrong details and phoned in to amend. If I get you correctly, as for order states, yes, we have that. I posted a few details in this post. Yes, manual order creation is already available. The API is finished. I'll post details soon, hopefully by tomorrow. I just need to finish testing a few other things first. So, manual order creation will be possible for whoever you want. You can take orders over the phone, at the POS, accept cash payments, invoices for goods delivered, etc. The interface is not ready but the API is. This means you can even use the API directly to create orders, not that you would want to do that if you have a GUI ?

Yes, this will be the approach. I've edited my earlier post to be more clear.

Oops, thanks. Post edited.

Done.

I missed this one ? Seems good to me!

I have this fixed in the Adminer panel version, but struggling to get it sorted in the Setup > Adminer version. Not sure I'll get this sorted tonight before I leave I'm afraid. I'll just leave it this way for now then - will tweak when I am back if needed.

Seeing the warning here as well. Tested on Win 10. Will try tomorrow on Win 7 but I don't think there will be a difference. Issue seems to be session_use_cookies, whether 0 or 1 and/or not ob_start() and ob_flush() at the very top and very end respectively...

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

<?php if($tab_size == 'too big') { use \CSS; $to_change->it(); } else { $it_looks = 'stupid'; } ?> When pasting code indented with tabs into the forum the indents are too large. It's simple to fix with a bit of CSS: pre { -moz-tab-size: 4; tab-size: 4; } Could someone with the necessary access add this? The big indent bugs me so much I usually find/replace the tabs with spaces when posting code. And as is universally agreed by all quality coders: tabs are much better than spaces

Spot on!

I'd vote strongly against that. Like who's to decide which 3rd party modules are worthy to be featured in the (1st party) docs? Who's job is it to maintain those docs if things change? Will modules be removed if they loose popularity? When exactly would that be the case? — I doubt we should put even more work on ryan's shoulders especially for stuff he might not even know very well. As afaik the module directory does not track downloads we cannot have a most downloaded modules listing, but imho that would be a more useful way to highlight modules, which are popular and not to be missed. We could also have a modules of the month poll or something like that for gathering information on module usage. As for documenting what a module does and how it's used; that should be up to the module maintainer and/or the community. Maybe the api docs could pull them out of the source code automatically like it does for the core (how it could work [1]). The point is the core docs are certainly not the place for providing information on 3rd party modules. 1: hexdocs.pm (try searching for e.g. phoenix or ecto for the best maintained examples) Each package of the hex package manager does automatically generate it's docs on publish and they will be published to hexdocs.pm. The docs are generated from the package's source code by a similar system to how it works for processwire. From my experience with it I've to say that having one platform for hosted docs, which are autogenerated (in 99% of the cases even by the same generator) is a real incentive to write (good) docs.

Done. Knowing very little about the subject or the website, I had to guess about 10-20% of the items, e.g. I have no idea what "RAAF C-17 Globemaster" actually is (of course, I could have googled it, but I'm a bit short on time right now...)

Since every hosting company can basically configure their servers as they wish, it would be wise to ask them directly. On some hosting environments, you can add PHP/Apache customization via control panel, on others you have to add a user.ini file in your site's root directory. With others you have to use .htaccess. But which methods are allowed or not, can surely be answered by their tech support team.

@adrian when you get back, please take into account $config->dbPort setting. I'm using non-standard port and this should be honored in ProcessTracyAdminer.module something like that: $port = wire('config')->dbPort ? ':'.wire('config')->dbPort : ''; ... new AdminerProcessWireLogin(wire('config')->dbHost.$port, wire('config')->dbUser, wire('config')->dbPass, wire('config')->dbName),

User-specific timezones is on Ryan's todo list: https://github.com/processwire/processwire-issues/issues/270

I can confirm same warning on Win 7.

I know what you mean. I see order data as a kind of artifact data which is only relevant to that specific order. Basicly it is stored in the two places, but if the order address changes for the user? You wouldn't want old orders to change the address as wel. So the single source of truth is stored on the user. See my quickly drafted visual:

The idea is to generate the page name from field values and not from labels. I will not change this. But I added support for dot syntax for the options fieldtype which should feed your needs. // no fallback to default language if not set. Options should be populated in each language my_options_field.title my_options_field.value my_options_field.id // always fallback to default language. If values are set pagename is pulled from the value, otherwise from title my_options_field

All those points sound ok to me. I just request a simple addition (maybe you just forgot to add but still...): Since I maintain a webshop which is set to "guest only checkout", I'm pretty sure there is a need for that too ?

Personally I'd rather open Adminer in a new tab and have the whole screen dedicated to it. Is there a way you could make it configurable whether to have the PW menu or not? Or perhaps there could just be a small link back to the PW admin root?

I think it would be good to add this - I'd use it. Either option would be okay, but my preference would be to see Adminer in the Setup menu.

After testing on a few more local sites I can't reproduce the error, so must be something specific to that one site and nothing to bother with. But one new issue I noticed is that it seems Adminer expects its root url to always include a query string. So in the Tracy implementation it can form invalid URLs that lead to a 404. For example, the link back to the database view:

Quick note to let you know that it's also possible to run Adminer directly via: /processwire/setup/adminer/ which may be preferable if you have lots of work to do and want it open in a more "permanent" way. At the moment I set the page as hidden so it actually won't appear under the Setup menu - I can change this, or perhaps I can have a link from the Adminer Tracy panel to open it this way. Any thoughts on which would be best?

Just released the new Tracy Adminer panel: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&amp;comment=175420

Here's a teaser - no prizes for guessing what the panel wrapping the interface is from ?

I can't recall atm, but I tried Adminer in the past and something didn't work so I ditched it. Aha. Keenly watching this...?

Am going to ditch phpMyAdmin in favour of Adminer. It's a great tool, especially when used in the Adminer Custom theme/plugin bundle: https://github.com/pematon/adminer-custom The JSON preview plugin rules: No problems with refeshing row edit views in Adminer. Was working on my own PW integration but I think @adrian might have something exciting for us all soon... ?

Customers discussion: I've had a bit of a think and I think I'm probably complicating matters. With your input and a bit more thought, for now, I'll go with this approach: Registered customers are ProcessWire users. We'll give them some role to distinguish them from other users + they never see the backend. The will have a record of their details in User template (address etc). These records are editable, e.g. change of address, etc. Guest users will only have a presence in their respective orders, their records saved together with their order For registered users, their orders will reference their ProcessWire user ID as well. To satisfy legal requirements, their data (the minimum required) will also be saved with their orders. As was pointed out, if their ProcessWire user account gets deleted, we still have their data in respect of their orders The backend will have a dashboard/page for managing users, both registered and guest customers. For guest customers, the data shown will be what is in their orders. They will be clearly marked as guest customers. There will be a global shop setting to allow either both guest and registered customers or registered customers only or guest checkout only Shop owners will indicate what information they want collected from their customers. It will be their duty to inform customers why they need the information Registered customers will have frontend login and customised dashboards Orders will still be filterable - unpaid, abandoned, etc. Orders will have records of customers, both guest and registered customers. These records are permanent and un-editable (and decoupled from any other similar/identical records in the case of registered users) ONCE AN order has reached a finalised state. Before the finalised state, the order can be amended, e.g. an address was entered wrongly and needs editing, etc.. Order statuses and any changes made will be accompanied by chronological order notes (same as we currently have them). I hope I haven't forgotten anything...

PageListSelect is different because it doesn't get pages via Pages::find, but rather gets the children of individual pages if they are listable. This is what I came up with: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; // Page is listable if it is the Users parent or a user page and the current user has a given role if(($page->id === 29 || $page->template == 'user') && $this->wire()->user->hasRole('editor')) { $event->return = true; } }); $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector = $event->arguments(0); $page = $event->arguments(1); // Don't check access if getting children of the Users parent and the current user has a given role if($page->id === 29 && $this->wire()->user->hasRole('editor')) { $event->arguments(0, $selector . ', check_access=0'); } });

There might be a way to workaround this though. What I really don't want to do is write a plugin for the forum software since they change stuff so often and I've seen plugin module developers over there get ticked off as they don't get any warning when core functionality changes or is removed. What I could potentially do is add a button that only the topic starter and moderators can see (easy enough logic in the templates - survives upgrades usually too which is something you have to worry about with this software) that then sends an AJAX request to a standalone script with a standalone table that stores "useful answer" information. It should then technically be possible to check that table using as little forum-related code as possible. It needs some looking into, but the question I asked here needs some debate first I think: Again, still not making any promises. I find that when I make promises sometimes years go by without me actually doing what I said I'd do ? The rare exception being the Dev Directory actually happening ?

Hi @quickjeff It should work out of the box. Just put the code after the LoginRegister execute() function call, done. Nope, no reason ?

@kixe I've updated the module to 2.1.1 and now I can't even save the page. I'm getting the following error: Method SelectableOptionArray::getLanguageValue does not exist or is not callable in this context

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.

@kixe I want to use an Options field as part of the pagename but I don't get anything. On the Name format for children I tried with: title my_options_field and with title my_options_field.title but I only get the pagename from the title field.

Nice, seems you had more time on this than me on my very similar module If you (or someone else) could devote enough time I can share my module that I have already started to polish. Perhaps you could merge the two or get ideas from it: