Leaderboard

This week we're getting down into some of the smaller details of the Uikit admin theme. We take a look at that in this post, along with a couple of screenshots. Consider this a brief continuation of last week's post. https://processwire.com/blog/posts/more-admin-theme-updates/

My personal opinion is that database layers like dibi tend to make some things a little easier while making corner cases complicated and taking clarity away by re-using existing keywords in a sometimes non-intuitive way. Then, they don't support application features like PW's multi-language fields or status flags, so one has to reign in expectations. And, often overlooked, PW already has a nice extension to the DB layer in the DatabaseQuery* classes. Perhaps that should be put into the spotlight a bit more (and added to the API docs)? A working example: <?php $q = new DatabaseQuerySelect(); $result = $q->select('templates.name') ->select('count(*) as inuse') ->from('pages') ->join('templates on templates.id = pages.templates_id') ->where('templates.name != :tplname') ->groupby('templates.name') ->bindValue(':tplname', 'admin') ->execute(); echo $q->getQuery() . PHP_EOL; foreach($result->fetchAll(\PDO::FETCH_ASSOC) as $row) { echo $row["name"] . " => " . $row["inuse"] . PHP_EOL; }

I just made a textformatter module that allows you to insert dummy content (lorem ipsum style) in text fields via shortcodes. Usage is simple - just type for example [dc3] into a textarea with this textformatter applied (plain textarea or CKEditor) and it will be replaced at runtime by 3 paragraphs of dummy content. It can also be used to populate text fields (for headings etc) using e.g. [dc4w]. This will produce 4 words (rather than paragraphs) at runtime. The actual content comes from an included 'dummytext.txt' file containing 50 paragraphs of 'Lorem ipsum' from lipsum.com. The 50 paragraphs is arbitrary - it could be 10 or 100 or anything in between, and the contents of that file can be changed for your own filler text if you wish. The slightly clever bit is that for any given page, the same content will be returned for the same tag, but the more paragraphs available in 'dummytext.txt', the less likely it is that two pages will get the same content (very roughly speaking - it's actually based on the page ID) so content selection is determinate rather than random, even though only the tags are saved to the db. Update Tags now work like this - [dc3] - Show 3 paragraphs ([dc:3], [dc3p] & [dc:3p] all do the same). [dc3-6] - Show 3 to 6 paragraphs randomly per page load ([dc:3-6], [dc3-6p] & [dc:3-6p] all do the same). [dc3w] - Show 3 words ([dc:3w] does the same). [dc3-6w] - Show 3 to 6 words randomly per page load ([dc:3-6w] does the same). <End update on tags.> If you think it might be useful, you can download it from GitHub and give it a try.

@svsmailus you don't particularly need deep working knowledge of PHP. The API is really simple to use. I came into this with almost zero knowledge of PHP (but a basic knowledge of general programming principles), a year later and I'm doing some really cool things. Not as cool as some of the guys here but this isn't a competition, they are very generous here with sharing the knowledge. In my opinion, if you want to progress in any CMS, this forum is the place to be. Processwire has allowed me to do things in the one year that took me much longer to achieve with the convoluted and plugin dependant ways of other CMS systems, including Drupal 7 & Wordpress. My templates output exactly the HTML I want and no more and querying the database is so simple. This in turn has saved me a bunch of time with the CSS as I don't have to style out classes chosen by the plugin developers thus being able to reuse code a lot easier across multiple sites. In regards to hosting, after changing a few times over the years, I use 'Kualo' now. They have been absolutely outstanding for support and the live chat is great. If you're anything like me, that is, very curious, like to ask a lot of questions and are keen to learn, then there's nothing stopping you! I am also working on a blog with a bunch of basic tutorials for people right at the beginning like yourself, hoping to go live within a couple of weeks (once I have some more content). Good luck ==EDIT== p.s. welcome to the forum!

@JoshoB, the problem is in the first line: $q = str_replace(' ', '|', $q); You are replacing the space character with the selector "or" operator, meaning wherever you use $q you will match fields with any of the words. So you want to remove that line. By the way, your way of matching the author title in the repeater is unnecessarily verbose. You can replace... authors=[authors_name=[title%=$q]] ...with... authors.authors_name%=$q ...because in a selector PW will try to match a string to a Page Reference's title by default. This selector should do what you want: $selector = "template=product, limit=10, title|subtitle|summary|body|product_isbn|authors.authors_name~=$q)";

There's a function in the core for this: function wireRelativeTimeStr($ts, $abbreviate = false, $useTense = true) {...)

No but you can use a hook like this: wire()->addHookMethod('Page::explode', function (HookEvent $e) { $arr = new WireArray(); $arr->add($e->object); $e->return = $arr->explode($e->arguments(0))[0]; // ONE LINER // $e->return = (new WireArray)->add($e->object)->explode($e->arguments(0))[0]; });

Just to clarify to those that might be confused by this line. This module is not a multi-site solution. It is a multi-site helper. You will still be using the official ProcessWire mulit-site solution. The module only helps you to auto-mate some of the manual tasks. The only notable difference is the how index.config.php is structured. I am not keen on splitting the module like this since it can, with a little tweaking, already achieve a standalone(single) installation. The only differences between a multi-site and single site are: multi-site location of site folder - located in same folder as the main site folder (e.g. /www/main-site/site/ for the main site and /www/main-site/site-something/ for the installed site site folder named site-something uses the existing wire folder (/www/main-site/wire/) needs index.config.php single site location of site folder - located in its own folder (e.g. /www/another-site/site/) site folder named 'site' uses its own wire folder (/www/another-site/wire/) does not need the index.config.php This means that all we have to do is (like you suggested earlier) tell the module in which directory on your server you want to install the single site, do the htaccess.txt renaming and copy over the wire folder as well as its index.php, LICENSE.txt, etc. That's all there is to it. The database stuff routines remain the same. So, I am thinking of a radio button to choose whether you are installing a single versus multi site, blah blah. Edit: In respect of selecting ProcessWire versions, the module could check if you have a zip file in a designated folder to unzip from and if not, download the ProcessWire version of your choice, or something along those lines. What is a standard setup ? I am a bit jittery about the module communicating with any URL. I would prefer all that such setups are loaded locally. Maybe I am just being paranoid here . I was thinking of saving this locally. That's what I was intimating by this:

@ryan is usually pretty adamant about extending the core for a feature that very few people will use. So I doubt he'll agree on that. Because it would mean rewriting a good chunk of the core and breaking many 3rd party modules, or having to maintain a separate set of underutilized classes. Feel free to open up an issue, though. If you study PagesLoader class you can figure out how PW fetches fields from their respective tables and maybe develop a module that works aside the current implementation. I, for one, wouldn't mind using something along the lines of: $list = $db->pages->posts->where('title.length>5')->fetch(['title', 'name', 'body']);

Hey everyone. I am at a stage of code cleaning for my first PW profile where I decided to implement some sidebar widget logic that would allow me to remove code repetition. I read about a few widget logic approaches that were working fine but that seemed too complicated for my needs so decided to implement something really simple that would do just that - widget logic that can be changed through the admin but not through code editing. So before I share my idea, I would give you some info of the structures I have: -- Recipes ---- Child 1 ---- Child 2 -- Ingredients ---- Child 1 ---- Child 2 So in my project needs, I wanted to have a solution that would allow me to set through the profile admin one or group of widgets per template (it would allow unlimited widgets as far as I have the code for it). So to achieve this functionality, I took the following steps: 1. Create a template, called widget_logic and set the allowed template for children to be itself (widget_logic) 2. Create a page Site Widgets and assign to it the widget_logic template. 3. Create a field called listing_widgets and set its type to Page Reference. 4. In Details tab select Multiple Page Array to allow multiple widgets to be selected. 5. In the input tab chose Page Auto Complete as input field type. 6. In Selectable pages point the parent to your widgets page name (Site Widgets in this example) and set the widgets_logic as the template. 7. Repeat the steps 3-6 creating another field: inner_widgets (this would allow you to have different widgets per listing template and inner page ) 7. Add manually the child pages with the widgets names in Site Widgets page you just created. 8. Assign the fields to the parent templates that you want the widgets to be pulled from (in this case: Recipes, Blog etc.) 9. In the template code, pull the page parent through API using the loop you use to list the results in the page. For this tutorial I will set the widgets to Recipes template that shows a listing of all the recipes matching my criterias: //Build a selector and limit page results to 5 $result = $page->children("limit=5, sort=-published"); //Pull the parent of the first child-page to be used for widget logic $parent = $result->first()->parent(); 10. Once we know the parent and we know the field names assigned to it containing the widgets, we use a simple loop in each template to get the selected widgets name and include them where needed. Note, for the widgets naming I used: widget-XXX-YYY.php (eg. widget-recipe-top.php). If you prefer other naming, make sure you change the include line to match the new names. //Loop through all the widgets setup in the parent template foreach ($parent->listing_widgets as $w) { //Including all the widgets by file name and order set in the parent widgets field include ('./includes/widget-' . $w->title . '.php'); 11. In the Recipe-inner template I would do the same: $parent = $page->parent(); //Loop through all the widgets setup in the parent template foreach ($parent->inner_widgets as $w) { //Including all the widgets by file name and order set in the parent widgets field include ('./includes/widget-' . $w->title . '.php'); } NOTE: in the inner page template I changed the field name to inner_widgets to pull the widgets for the inner page. 12. Now all that is left is to assign the two fields to every parent and/or inner page template that you would like to use the simple widget logic and select the widgets for each one. It might not be the best approach, however it is super simple to setup and allows me to have different widgets on any template now. The variety of widgets could be extended at any time by just adding the new widget, create the page with the name for it and assign it to the chosen template. Having the Page Auto Select field would allow you to drag and drop the widgets to reorder them so it suited my needs perfectly. Hope it would for you as well. Any code improvements are more than welcome (as usual P.S. On the image of widgets view, I set the size of both fields to be 50% so that they show up on the same line and save the space and scrolling.

Nice one @Robin S, I've never seen that one used anywhere before. It seems to fetch all fields before handing you an ArrayObject. public function getIterator() { $a = $this->settings; if($this->template && $this->template->fieldgroup) { foreach($this->template->fieldgroup as $field) { $a[$field->name] = $this->get($field->name); } } return new \ArrayObject($a); } One thing that I'd like to have with explode() method is to get deeper fields with dot notation, such as $thumbData = $page->explode(['url', 'title', 'images.first.url', 'tags.count']); like underscore.php (or understore.js) does. I guess I should start building a module.

Nice one @abdus ! Just a quick tip for others. You can also test building hooks directly in the Console panel.

Or check out the "Field List & Values" section of the PW Info panel in Tracy, which takes things a step further and explodes values which returns arrays (like images) and provides other details about the fields:

Not what was asked, but if you ever have a need to get all the field values and properties of the page in an array you can do this: $data = (array) $page->getIterator();

Sounds good to me. In fact the default setting were important to me until the feature to import settings.php weren't introduced (see the bottom of AOS config page). For the nav items I could tweak it to enable edit links only for superuers.

This is known bug/inconvenience/annoyance: https://github.com/ryancramerdesign/ProcessWire/issues/1854

No, it doesn't search as a phrase but it does require all of the words to be present in the field, and does not match partial words. So if $q = "red dog" it will match "I have a dog and she loves red frisbees" but it won't match "I have three red dogs". When using the %= operator with multiple words, you will need to explode on spaces and foreach: $q = preg_replace("/\s+/", ' ', trim($q)); // trim and replace multiple spaces with single space $q_words = explode(' ', $q); $selector = "template=product, limit=10"; foreach($q_words as $q_word) { $selector .= ", title|subtitle|summary|body|product_isbn|authors.authors_name%=$q_word"; }

See $files vs $file http://cheatsheet.processwire.com/

This means you've set up the file field to give you an array of files (Pagefiles), you need to get the file using annual_report->first->url. Using annual_report->url gives you the directory. You can limit field to 1 file and return you a Pagefile object instead of an array (Pagefiles) too

Bumped to 0.3.0 - now using the Composer package, as above. There don't appear to be any breaking changes, other that the fact that the Settings class is now a separate entity. Also note that I'm keeping this in alpha for the simple reason that things may change. I don't expect to break anything, but would like to re-work the configuration class a little, add a few more features, and then bump to stable 1.0.0.

Using Database class is actually quite straightforward. It's nothing but a wrapper around PHP's PDO class with some PW specific features. You prepare a SQL statement using prepare() method, then bind input values, execute() it and fetch() the results. <?php namespace ProcessWire; // sanitization $tableName = inputPost()->text('table'); $columnName = inputPost()->text('column'); $id = inputPost()->int('id'); // this is where you'd sanitize user input to prevent SQL injection $table = database()->escapeTable($tableName); $column = database()->escapeCol($columnName); $q = database()->prepare("SELECT `$column` FROM `$table` WHERE id = :id"); $q->bindValue(':id', $id); // always bind values instead of concatenation // $success = false; $values = null; try { $success = $q->execute(); $values = $q->fetchAll(); } catch (\Exception $e) { wire()->log($e->getMessage(), Notice::log); } if (!$success) { // handle error } if ($values) { // use values } To see how PW utilizes this class, check out Fieldtype.php, FieldtypeMulti.php, PagesEditor.php and PagesLoader.php from the core.

ProcessWire's database abstraction is the best of all CMS systems I know.

https://www.baumrock.com/portfolio/individuelles-crm-und-controlling-tool/ I'm happy to share my biggest and most interesting ProcessWire project so far with you It's a 100% custom office-management solution that helps my client to keep track of all their contacts, projects and finance/controlling stuff. Conception was done back in 2016 and the software is productive since begin of this year. My client is very happy with the result and so am I. Some technical insights: Everything is done inside the PW Admin. I'm using the Reno Theme with some custom colors. In the beginning I was not sure if I should stay with the pw admin or build my own admin-framework but now I'm VERY happy that I went with PW Almost all of my custom Process Pages use my RockDatatables module - there are still some limitations but without it, this project would not have been possible For the charts I used Google Charts and chartjs - both play well together with the datatables and make it possible to display filtered data instantly: also my handsontable module was created for this project to have a nice and quick option for matrix data inputs: Lister and ListerPro were no options as i needed much more flexibility regarding data presentation (like colorization, filtering and building sums of selected rows): invoices are highly customisable as well and easy to create. PDFs are created by php and mPDF by the way: all data is dummy data populated via my Module RockDummyData have a nice weekend everybody

Hello everyone, I spend my sunday hacking a playground for the new admin theme together. Unfortunately it took almost the whole sunday, Fortunately it was raining anyway. If you find bugs or annoyances, please feel free to tell me about them. What is it? It is a backend with an integrated skin editor. In this weeks blog post @ryan showed how easily skinnable the new admin theme is. Now that can be done online without having to set up ProcessWire and LESS compilation (I did that for you). Show me http://pwadmin.youbility.de/processwire/ username: admin password: admin123 Why did you do that? I really think the new backend is one of the three key factors for ProcessWires future success (as well as the new website and the documentation; basically the things a user sees first when he's deciding for a CMS). Many many weeks ago, when Ryan introduced the new theme, he said he will need help from the designers in the community to create the best experience possible. As far as I've seen, since then there was not that much input from the community. I hope a ready-to-run theme editor can improve that a bit. How does it work? Right of the search field there's a new icon which opens the editor. Simply create a new skin and start playing with it. The skin will be available throughout all the session, even if you refresh or change to another skin. When you log out or lose your session the skin will be gone, so save your final result somewhere else too!! What other features will come? Probably none, unless there's something heavily requested. I could probably add something to store the skins permanently through LocalStorage. Or I could add more possibilities for customization than just the LESS file. But first I'd like to see if this is used and there's even the need for those features. Can I show my created skin to others? Of course. Right now just "default" and "pw-theme-reno" are public. I would love to show more skins there. Just post the content of your skin in this thread and I will add them to the public skins. I hope you find it useful and it helps making the most efficient and polished CMS backend out there.

First, I really like this admin theme! So what follows isn't meant to be a full picture of my reaction to it because overall I love it - just a few things that could use tweaking IMHO. Fonts Currently users will see completely different fonts depending on what OS they are using. The font-family rule is: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif It's become popular lately to use system fonts like this (was it GitHub that started it?) but the problem is that the fonts in this stack are not very similar. It's one thing to fall back to Arial if Helvetica isn't available because they are so similar that the average audience won't be able to tell the difference. But San Francisco, Segoe UI, Roboto and Helvetica Neue are completely different typeface designs. So for instance there will be no consistency with x-height or position of type within the line-height box across platforms, so what looks pixel-perfect on MacOS might look sloppy on Windows or some other OS. If the desire is to move away from the bog-standard Helvetica/Arial then wouldn't it be better to bundle an open-source webfont kit with PW so there is reasonable consistency across platforms? From the blog post screenshot: From the demo site, Windows 8.1: Search box Like the current default admin theme search box styling, I think this is way too subtle: I have 20/20 vision and I can only barely make out the bounds of the search box - imagine what it's like for users with less-than-perfect vision. The search feature is hugely useful for quickly finding a page to edit in a deeply nested tree structure, so we want users to know that it exists. With the current admin default theme, most of my clients had never noticed the search box (until I boosted the contrast in some custom admin CSS). Tab metaphor For a tab metaphor to make sense there has to be some visual connection between the active tab and the content within that tab. Otherwise it isn't clear what content on the screen is controlled by the tab. On this screen... ...not knowing better, I would expect the tabs to control only the Title, Date and Headline fields. Body looks like it is outside of the tabbed content and so the expectation is that it remains on screen when switching to a different tab. Of course you learn how it works once you use it, but every time a thing works differently to how a user expects it to work there is a little bit of mental friction - a bit more effort required to understand it and a bit less satisfaction. I understand that there is a setting for controlling the border style of different fields (although it is disabled in the demo so I couldn't easily try it) - that's great. But I think the default style should be one that lends itself to the tabbed interfaces that are used throughout the PW admin (i.e. a visible border that connects to adjacent fields that are within the same tab). Breadcrumb separator Getting a little nit-picky here, but I think a guillemet › is a better breadcrumb separator than a slash /. The breadcrumb is supposed to indicate a hierarchy of pages. With the slash there is less sense that Posts is within Blog. It looks like a group of items that are all on the same level. Container width My preference is for some max-width to be set for pw-container (1600px maybe?). On my 2560px-wide monitor the interface becomes too wide for comfortable use. But that's an easy override for me to apply if there's no agreement on that.

Here's a micromodule for you: Save this in site/modules/TextformatterCurrentYear/TextformatterCurrentYear.module. Then refresh modules and install it. Once it's installed, add it to your field's textformatter list. It will replace all instances of `curryear` with the current year (4 digits `2017` for example). You can set it once and forget it <?php namespace ProcessWire; class TextformatterCurrentYear extends Textformatter { public static function getModuleInfo() { return [ 'title' => 'Current Year Replacer', 'version' => '1.0.0', 'summary' => 'Replaces `curryear` with current year', ]; } public function format(&$str) { $str = str_replace('curryear', date('Y'), $str); } }

Please

Simply put: a field is an interface to DB, an inputfield is an interface to user. One does not necessitate the other, but for some complex data types, you may need to build a custom inputfield (like MapMarker). If you're going to store information about multiple books on a single page, then you need to extend FieldtypeMulti class (FieldtypeEvents, FieldtypeNotifications, FieldtypeComments for example), to store information about a single book per page, you need to extend regular Fieldtype class (FieldtypeText, FieldtypeDatetime etc). If you want to allow more than 1 property to be used in selectors, then you need to use multiple table column in DB. This means you need to override getDatabaseSchema() method and specify a more complex table structure. Edit: Based on your description, you expose only one input to the user for ISBN/title, filling the rest is up to you (by fetching from a web service). You have two options: either fetch the data using fieldtype or using inputfield. Using inputfield to do fetch the rest of the data sounds more appropriate, because the purpose of the fieldtype is validation, formatting, sanitization querying and saving data from/to database, i.e. it only deals with the given data. An inputfield, however, collects and prepares all data that needs to be written to the database and presents it to a fieldtype.

GitHub issue opened here: https://github.com/processwire/processwire-issues/issues/399

It's likely just the current PHP instance in FastCGI or the Apache child reaching its maximum lifetime. Depending on the web server and how PHP is invoked, a new PHP instance is spun up every so often. The new PHP instance gets loaded, and if error reporting is active, it just coughs this warning into the next output stream. So it has nothing to do with calling soap methods.

I'd like to make some suggestions about this module, after having used it/installed it and setup on a lot of sites recently: 1) I believe that the module should default to everything off. Many of the changes that this module makes to the admin are potentially breaking, or may totally confuse non tech-savvy clients. I would rather be able to install this, and enable 1 feature at a time and then test each enabled feature. 2) In terms of defaults, i believe the CK editor skin should default to 'default' not to lightwire; because since default is the default, why not let users decide if they want to change to lightwire, instead of assuming they want it. Also, i wouldn't include any plugins by default, especially not justify - one a site i just installed AOS on, it was showing 3 entire sets of text alignment icons in the editor; by removing that plugin, this has reverted to normal behavior. 3) with nav items, that is certainly an awesome feature, and allows you to make a lot of cool shortcuts in the sidebar, also having the option to group some into their own submenu is cool - would be even better if the submenu could be above pages so that you could put your custom shortcuts into it's own top level menu, like "Site" or "Company"; I'm not fully understanding why the menu items have 2 areas, one that links to a bookmark and one that links to the editor; it is very clever that by selecting a page, it knows you mean edit the page (not view); my clients are so technically handicapped that even having 2 areas of a menu item will probably cause a meltdown. Ideally clicking on the item would just take them to the edit page, or maybe there can be some setting for this in case other users like that dual menu item functionality... thanks for considering!

Still haven't resolved this. Some further information which may be of help: PW Version 3.0.62 Formbuilder Version: 0.3.0 WireMailSMTP Version 0.2.5 (was 0.2.2 but upgrading made no difference). PHP Version was 5.4.28 on dev, 5.6.31 on live. Tried switching to 5.4.45 on live, no improvement. Still not sending via SMTP, and still not able to hook WireMail::send on live. Have attached Tracy Debugger but no obvious errors detected. Update: I'm getting a bit closer to the root of the issue. When FormBuilder comes to send, it does a check to see if the wireMail function exists: if(function_exists('wireMail')) { ... $result = wireMail(...) } else { ... $result = @mail(....) } So I put some breakpoints in and it transpires that function_exists('wireMail') is returning false on my newly upgraded cPanel hosted sites. The reason that I can't hook is that it then goes on to use the mail() method directly, bypassing WireMail completely. ... so why would the function_exists() return false all of a sudden? What could change in PHP that would create this issue? I may cross-post this last updated info in the FormBuilder forum; hopefully Ryan can pick it up and provide some insight.

if i understand him correctly this would still not be what he wants, because it would also find this page: title = the red island body = three dogs lived happily... i guess it should NOT find this page? i think proper searching is beyond what can accurately and easily be done with selectors. one forum member recently linked to this search service: https://www.algolia.com/product that is free until 10k records and 100k operations. google custom search could also be an option: https://developers.google.com/custom-search/ and last but not least we have the elastic search module that looks like it could match perfectly for you. i've never used it though, so it would be nice to hear some experiences from others: https://modules.processwire.com/modules/elastic-search/

This still needs to be fixed/addressed. Also that was from the old repository.

@abdus you're right. The other field had a max of 1 on it. This field not. I got it working now. Thanks. I totally overlooked this myself.

What happens if you echo $annual?

@bernhard, that is a really good tip. Thanks!

Because you're using option A. Try other option (B,C) which is not using iframe

While I can't speak for everyone, I think we're all being positive and supportive. We are grateful this now exists. However, I think there is a valid argument to be made in the desire for a paid enterprise level solution that will give us peace of mind in trusting that such a critical component of a website is a high priority with proper attention, development and support. Raising this point isn't negativity, it's just an expression of concern. I work with large organizations that have thousands of members. I need a solution that is rock solid, that I can trust will have bugs and support issues attended to in a timely manner. It just stands to reason that a paid solution is going to receive higher priority than a free one. You're right, it's new and let's see how things are in a few months.

let's see how rainy the weekend will be and i'll do this version of the admin theme.

I fully agree with Lance. Firstly, a HUGE thank you to Ryan for doing this. It was badly needed and the only thing that held me back on converting some of my legacy ModX sites. I love PW and this was the missing piece for me. I can't thank Ryan enough for turning his attention to this sorely lacking functionality that almost every other CMS has. However, I'm very sad that this isn't a pro module. Rather than being part of the core to "guarantee" attention and updates (as others above have indicated), I would have preferred this to be a paid module to ensure such attention and updates. That's not to say Ryan won't be maintaining this module in a reasonable fashion, just that this is a huge enough component of a CMS that it absolutely could have warranted being a pro module and there are many of us that would have gladly paid for it. I will gladly use this module, provide feedback on bugs, questions on customizing, etc. and hope that all such things are attended to in a timely manner. While I appreciate that it is *FREE*, Ryan, please consider making it a pro module. I'm sure you have your reasons for not doing so and I guess I'm just worried it won't get the attention it deserves. It will be critical to many of my membership sites that I will now convert to PW and thus I'm worried about future development on it. Things like images support are crucial and if this was a paid module, may be higher up Ryan's priority list.

Major speed improvement ! I have been in dialog with the Tracy core dev (David Grudl) for the last few hours and he has come up with a way to have all the advantages of the current version ("Master") of the Tracy core (including the AJAX bar), without the potentially huge speed penalty - the old ("Legacy") version was always much faster. On some servers, the new version was painfully slow at times. For those interested, the slowdown was due to the use of $_SESSION to store the content of the debug bar. This was sometimes huge (especially will all the custom panels this PW implementation has). This new version doesn't use sessions for the main bar and because the AJAX bar doesn't show the custom panels, the size of the session is kept MUCH smaller. This is brand new, but so far I don't see any side-effects, but please start using it and let me know if you come across any problems, or just feel free to comment on how much better it is! Maybe even drop David a thank you if you feel inclined.

Ah! I'd not joined the dots—didn't realize that was you Yep, hear you about the frustrating of getting this type of stuff working when it's not core and you have other stuff you need to be doing. Yep, can't complain that Apple has moved to php 7, and v. glad the clamp dev is about to address this with a fix, better than my hack

This fork of AdminBar (https://github.com/teppokoivula/AdminBar) can be very useful in this situation. Style it to match your site and it's a very quick way to give logged in users the ability to edit and add new child pages. It won't ever be as flexible as building your own frontend form and processing using the PW API, but it's very easy when you have complex forms to reproduce, especially if there is image upload and ASM type select fields to reproduce. This screenshot shows that you can add a "New +" child page when viewing the main portal parent. This screeencast shows editing an existing entry:

@blynx In case you still can't get clamp working with PHP 7, this may help, also I see later in the thread that the dev is about to release an update.

Lots more updates today. 1) I have changed the default zIndex of the debug bar panels. In the Tracy core they are set at "20000" and go up from there as new panels are displayed, but these were always above the PW dropdown menus which meant you always had to close a panel to access menu items - very annoying. I have set them to "100" as a default, but this is also now configurable in the module settings so if you find you are having problems (especially on the frontend of your sites), you can adjust as needed. Please let me know though if you think there is a better default than 100. 2) Now if you are editing a field, template, or module in the admin, the Console panel will have access to: $field, $template, or $module, respectively which will be the object for the currently edited one. So if you are editing the "body" field, instead of doing something like: d($fields->get("body")); you can just do: d($field); 3) Again, when editing a field, template, or module, the ProcessWire Info panel now contains a new section at the top with details for the edited object. This is an example of the "body" field being edited. 4) The ProcessWire Info panel now uses the exact name of the PW property, rather than the old capitalized and spaced label. This means you can see what you will need to use in your templates to get a certain property. Cheers!

This is a simple loader for LessQL, an ORM alternative for PHP. It is based on NotORM, and provides a quick way to access and find things in a database, including traversals and back-traversals. As discussed in some earlier topics, there are times when you'd like to store some data away from ProcessWire's pages/fields/templates structure for whatever reasons. However ORMs are sometimes cumbersome and requires a lot more effort to deploy. LessQL offers a quick way to just up and go like you're using an ORM but without the added complexity and configuration files. Module: https://github.com/alguintu/LessQL This modules simply loads the LessQL library into ProcessWire and exposes a $lessQL variable (configurable in settings) that gives access to your database. It uses the same database specified in $config by default, but can be set to use a separate database, along with its credentials. Usage given a table person : $people = $lessQL->person()->select("id, firstname, lastname")->where("firstname LIKE ?", "%alex%")->orderBy("firstname")->limit(10); It uses lazy loading and doesn't execute the query until it needs to. Checkout www.lessql.net for more info on LessQL. Module wrapper is pretty much lifted from @teppo's RedBeanPHP module, but with a few modifications.

Put this in your site/ready.php file: $this->addHookAfter('Session::loginSuccess', null, function($event) { if($this->wire('user')->hasRole("target-role")) $this->wire('session')->redirect("other-url"); });

Swithcing to "selector arrays" might help to workaround this limitation: https://processwire.com/blog/posts/processwire-3.0.13-selector-upgrades-and-new-form-builder-version/#selector-engine-array-support

Thanks for the contribution. I used YAML in past PHP projects outside of ProcessWire a lot and found it very useful. Great to see now support in PorcessWire for it. I also used initially SpyC but found its parsing not as robust and compliant and subsequently switched to Symfony's Yaml component which I found a better parser. For example Spyc does not support correctly anchors with newline folds > (item: > &anchor). Migrating from SpyC to Symfony\Yaml is easy, just replace Spyc::YAMLLoad($sourceFile); with Symfony\Component\Yaml\Yaml::parse($sourceFile);. Should you decide to migrate to the Symfony compnent, use the 2.0.* branch of Symfony\Yaml which still does support mixing list and associative array elements which the 2.1.* branch does not allow any more despite it being correct YAML syntax. If you use composer "require": { "symfony/yaml": "2.0.*" }, will pull in the correct Yaml library.