Leaderboard

If you render the value of the field you get the table rendered by class TableRows. It's nothing to do with the Fieldtype or Inputfield render. So you can simply use the render function of the value == TableRows object and add your options. $value = $page->mytable->render(array("tableClass" => "uk-table")); Though nothing wrong with you str_replace. I don't get how that is bad but anyway.

https://processwire.com/blog/posts/new-module-configuration-options/

Hello Friends… New Version 0.4.0 released. I try to answe a few questions. How the theme works: PATHS ARE OUTDATED - THE CONCEPT MORE OR LESS THE SAME. (will update soon) The variations & Ryans work: It uses the built in uikit feature to create themes. Theme variations can be defined in uikit/themes.json. In my case, I define 3(+1) themes: black, blue and vibrant blue. These relate to "entry points" found under ./uikit/custom/antrypoint.less » like uikit/custom/pw.less or black.less or vibrant.less Each one of these basically only defines the custom accent colors and include all other general variables and some overrides: // uikit source @import "../src/less/uikit.theme.less"; // main accent color: // pw color @theme-primary-color: #3584EA; @theme-primary-color-rgba: rgba(53, 132, 234, 0.6); // Original Theme @import "../../AdminThemeUikit/pw/_import.less"; // AdminThemeBoss Custom Styles @import "fonts/fonts.less"; @import "theme/main.less"; In the newest Version (0.4.0) I actually grab ryans code (uikit and other custom stuff) and include my own customizations (variables etc) after that, this should ensure that the theme stays as compatible as possible. Of yourse if ryan changes major stuff, this needs to be addressed sperately. The Main File is uikit/custom/theme/main.less Ryans stuff can be found under ./AdminThemeUikit/ – it's a copy of the custom folder of his Module. There is a new ./upgrade-theme.sh that automates that stepp… Compiling the css Compiling is done using npm or yarn using webpack from the uikit folder. It's easy: $ cd uikit # grab node modules: $ yarn # compile $ yarn compile-less # or for development: $ yarn watch Injecting the css: Before 0.3.0 I search and replaced Ryans CSS in the html using a hook. Since 0.3.0 i only set parameters of AdminThemeUikit: cssURL and logoURL So no messing arround with unstable HTML… Why not an actual Theme? Tldr; For compatibility & flexibility reasons Longer Version: Because if I make AdminThemeBoss an actual standalone theme, I lose compatibility with Ryans AdminThemeUikit … By only working on top of his theme, all new features he includes will still (and instantly) be working with AdminThemeBoss without an upgrade because my theme is mostly only css. Also, I can not hook into his functions for example to extend the breadcrumb if I build my theme as a standalone theme. Why these color variations? Now there are 4 ? » Black: Because I our basic Corporate Design is mostly black and white » Processwire Blue: Because obvious I it would be cool to retain some relation to PW CD » Bright Blue: To have something fresh and because I like it ? » And a new Happy Pink version because of C43H66N12O12S2

So happy to follow this reborn of Padloper!

You can add a markup field there via array in your module config: [ 'type' = 'markup', 'value' = 'your html', ] You can also group/collapse etc several fields. There is a blog post about the new module config. Sorry on mobile ?

I'm sorry, I did not get it. Here it comes: Note that tooltips of the options are usually informative and helpful.

You can do that using the multi-instance feature of ProcessWire 3. Have a look here.

There isn't anything inefficient about this (or at least there isn't really a more efficient way of doing it). The value of a Repeater field is a PageArray. When you do anything with a Repeater field value then the whole PageArray is loaded to memory. It doesn't matter if you only want a single page from it - you can't avoid loading all the pages if you get the Repeater field value.

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

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.

MediaLibrary Update: MediaLibrary can now be found in the official module list. Out of necessity, I've started to implement a simple media library module. The basic mechanism is that it adds a MediaLibrary template with file and image fields. Pages of this type can be added anywhere in the page tree. The link and image pickers in CKEditor are extended to allow quick selection of library pages from dropdowns. In the link picker this happens in the MediaLibrary tab, where you can also see a preview of the selected image. In the image picker, simply select a library from the dropdown at the top, everything else is handled by standard functionality. I've put the code onto github. This module is compatible with ProcessWire 3. Steps to usage: Download the module's zip from github (switch to the pw3 branche beforehand if you want to test on PW 3.x) and unpack it into site/modules Click "Modules" -> "Refresh" in the admin Click "Install" for MediaLibrary For testing, create a page with the MediaLibrary template under home (give it an expressive title like 'Global Media') and add some images and files Edit a differnt page with a CKEditor field and add a link and an image to see the MediaLibrary features in action (see the screencap for details) Optionally, go into the module settings for MediaLibrary Note: this module is far from being as elaborate as Kongondo's Media Manager (and doesn't plan to be). If you need a feature-rich solution for integrated media management, give it a look. Feel free to change the settings for MediaFiles and MediaImages fields, just keep the type as multiple. There are some not-so-pretty hacks for creating and inserting the correct markup, which could probably be changed to use standard input fields, though I'm a bit at a loss right now how to get it to work. I've also still got to take a look at error handling before I can call it fit for production. All feedback and pointers are appreciated (that's also why I post this in the development section). Edit 09.03.2016 / version 0.0.4: there's now also a "Media" admin page with a shortcut to quickly add a new library. Edit 01.05.2016: Version 0.0.8: - The module now supports nested media libraries (all descendants of eligible media libraries are also selectable in link/image picker). - There's a MediaLibrary::getPageMediaLibraries method you can hook after to modify the array of available libraries. - You can switch between (default) select dropdowns or radio boxes in the module configuration of MediaLIbrary to choose libraries. Edit 10.10.2018: Version 0.1.3: - Dropped compatibility for ProcessWire legacy versions by adding namespaces - Allow deletion of libraries from the Media overview admin page - Added an option to hide media libraries from the page tree (optionally also for superusers)

Hello @j__, using a Repeater field for this use case may be nice on the back-end but as you have already experienced difficult to output. One possibility could be to build yourself a new PageArray, where you add all repeater items and sort or filter them however you like. Or you could reconsider and use regular pages for your events. ? Regards, Andreas

Are you looking for docs in modules for the superuser or docs in admin pages for the client?

@adrian Hi Adrian, I know you have done the latest version of this module. I'm having a few issues using your folk on 3.0, not entirely sure if it's me. 1. You mentioned that it sets a sleep value of the page ID, so if the URL is to ever change it will be update. This doesn't seem to be working at all. I can set it to a local url but it does not update if I change the url. 2. It doesn't seem to store ID's at all on a local install. I think both of the above is because it's installed on a folder: I mean the domain is http://dev.agency.com/client - so the url is /client/link/to/page and exactly why I need 1 or 2 for when it goes live. I'm going to do a folk and fix that. Let me know if you want to merge.

Maybe this one??

I wrote that on mobile, maybe you missed it? It was related to your post.

Received, thanks.

I believe so :-).

Please find them in your inbox. Thanks!

The overlapped header button and the CodeMirror black font color issues should be fixed in v2.0.4. As for the latter, if you set a light CodeMirror theme then you should manually override the font color with a custom CSS. I also made the CodeMirror editor text a bit larger and force word-wrapping.

@kongondo Happy to hear that a lot of work has been done already. How do you see real terms of initial release? 3-5 month?

This might be relevant:

Ah, I see, thanks. I have the discount GUI sorted but not yet implemented (looks similar to shopify), but no harm in considering an alternative. So, yeah, I'm happy to look at some screens ?

Is this a personal site? You can use the API to upload images as well as resize them.

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 ?

I don't care about those 135kB, but I also don't care about any other theme than we currently have ?

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...

A couple more settings to help out those of us with "tired" eyes ? These will be pushed in the next few days. I am still messing around with the code completion stuff. Unfortunately I don't think showing the doc comments like I posted above is going to be a good idea - it's a 2MB payload and even though I am not really seeing a slowdown here on local dev, it still feels wrong and will probably impact performance on a live server. I do like the idea though of an API learning interface like this, so maybe it's something for a dedicated panel where speed doesn't matter. Any thoughts?

Thx for the heads-up noel. I just tried your theme again and found this little bug: Very nice! Why are there three colors? Could you describe a bit how you created thos color variants? What is necessary to add a new custom color? Is everything replaced by hand in the css? Or is there some less/sass files? The reason why I'm asking is because it would be great to have the option to change some colors just by selecting one.

...Or if you use _init.php, define $homepage there and it will be available in all your template files :-).

Not really. Since you have to store the value, you also need to load the page it is attached whenever you want to read it. PHP provides no built-in persistent storage that reaches across sessions and is shared between individual threads/processes. If you want to avoid the overhead of loading $homepage and the counter for every page view, you could however use a memory cache like memcached or APC, update that when the counter is incremented and read from it when viewing other pages (or fall back to $homepage if its not yet set, e.g. after a server restart).

Just for display in the repeater label? That can be done with a little hook in site/ready.php: wire()->addHookAfter('InputfieldRepeater::renderRepeaterLabel', function (HookEvent $e) { $label = $e->return; $page = $e->arguments('page'); $label = preg_replace_callback('/\\[([a-zA-Z0-9_]+)\\]/', function($match) use($page) { return number_format($page->{$match[1]}, 2, ',', '.'); }, $label); $e->return = $label; }); This looks for a field name between square brackets (something like "[price]" in "#n: {title} - {item} - [price]") in the label and replaces it with the formatted value of that field.

$today = date('Ymd'); $start = date('Ymd', $single->getUnformatted('Start_date')); $end = date('Ymd', $single->getUnformatted('End_date')); if($today == $start AND $today == $end) echo "<div class='Dates-text'>TODAY!</div>"; elseif($today >= $start AND $today <= $end) echo "<div class='Dates-text'>ONGOING!</div>";

Thx @Robin S, I had a look to those fieldtypes and you where partially right. I removed sleepValue and deletePageField since they should never get called on a non-db fieldtype. But your runtimeonly field does actually have too few methods if you want to keep it completely out of the db. Your fieldtype creates an empty db table. Not sure if that is intended? I've invested some more time and really like this approach of building new Fieldtypes! Is really simple, see this example of a new Fieldtype called "FieldtypeNow": I renamed the base fieldtype to "BaseFieldtypeRuntime" and it really does not do anything other than providing the boilerplate. It does not even show up in the list when you create a new field in your pw installation (screenshot later). This is the current code: Actually it does only define the inputfield and add some hooks to replace the render and renderReady methods by our own implementations and define all the functions necessary to keep the db out of the game: Simple, right? ? This is how the installation screen looks like: The BaseFieldtype is set as dependency, so FieldtypeNow can only be installed when the Base Fieldtype is available. Once installed, you can easily create a new field of that type: Notice that there is no Fieldtype "BaseFieldtypeRuntime" in this list as I mentioned above. You can then add your field to a template and edit any page of that template: <?php namespace ProcessWire; /** * Demo Fieldtype Extending the Boilerplate Runtime Fieldtype * * @author Bernhard Baumrock, 03.10.2018 * @license Licensed under MIT * @link https://www.baumrock.com */ class FieldtypeNow extends BaseFieldtypeRuntime { public static function getModuleInfo() { return [ 'title' => 'FieldtypeNow', 'version' => '0.0.1', 'summary' => 'Fieldtype showing the current time', 'icon' => 'code', 'requires' => ['BaseFieldtypeRuntime'], ]; } public function render() { return time(); } } Another Fieldtype rendering the content of a php file named like the field (very similar to the existing modules by @kongondo RuntimeMarkup, @Robin S RuntimeOnly and @kixe FieldtypeMarkup). You actually only have to implement the render() method, and if you need you can load scripts in the renderReady() method... This fieldtype loads files that are named like this: site/templates/FieldtypeRenderFile/{fieldname}.{templatename}.[php/css/js] site/templates/FieldtypeRenderFile/{fieldname}.[php/css/js]

You could just create a template called logout.php (and a page called Logout using that template), and link them to that page to logout. /site/templates/logout.php: <?php namespace ProcessWire; $session->logout(); $session->redirect($pages->get("/")->url);

Maybe I am not reading this correctly, but why do you need a Hook? The code is from the default site profile that ships with ProcessWire: <?php if($user->isLoggedin()) { // if user is logged in, show a logout link echo "<a href='{$config->urls->admin}login/logout/'>" . sprintf(__('Logout (%s)'), $user->name) . "</a>"; } else { // if user not logged in, show a login link echo "<a href='{$config->urls->admin}'>" . __('Admin Login') . "</a>"; } ?> Or maybe you mean you want them to login from a page other than the admin page?

Hello, this line would only get one item. $items = $pages->get("template=portal-files")->portal_bestanden; may be with this would work $items = $pages->find("template=portal-files"); foreach($items as $item){ foreach($item->portal_bestanden as $document){ echo $document->name; } }

Could be interesting if you can integrate this as an option: https://omnipay.thephpleague.com/ because it has several implementations for gateways by the community: https://omnipay.thephpleague.com/gateways/community/ and can be extended easily... It will be perfect if you can check the backend of Shopify (14 days free trial), is really easy to use and understand for the customers. The workflow concepts and the organization of product information, collections, discounts, inventory, etc is very simple and concise, minimal enough for a regular store. My personal recommendation is to stay away from Magento like UI and concepts. Maybe the backend could use some ideas similar to your Media Manager or Visual Page Selector, I like the visual look and the user interaction.