Leaderboard

I'd like to contradict. The admin themes we have really need a css overhaul and cleanup (and maybe docs), but a prebuild framework is in my opinion not the way to go. Because it's not developed internally every special usecases the admin does have will feel like a hack to the framework. Framework + custom workarounds will always be bigger (more code / more maintainence) than a customized solution. It's also a matter of branding. True, one can add custom colors to UIKit, but in the end it's probably still noticable enough that it's UIKit. Also consider all the markup in core and 3rd party modules, which are needed to be supported the the admin theme. I doubt any prebuild framework is bendable enough to support that level of custom markup coming from our side.

What situation? That 'how dare they charge a whopping $1 for music'? . Just kidding. Price here is immaterial. Whether $1 or $1000, the facts are: It will have to be paid via some means That means needs to be secure That means needs to be something your musician's fans have access to (e.g. PayPal, etc) Buyers will most likely expect to be able to download music they've bought right after payment has gone through The band will want to be able to track downloads, paid or unpaid Etc... I wouldn't reinvent the wheel with this one. Buying and selling will be taking place, period. I'd invest in Padloper ...(or if really, really, pushed, in some other ready made solution.).

For page creation, I meant that you should hook into the actual page creation process, or just after it. That means hooking into 'added'. I have tested (code below) and it works. Once the new tag has been created, we get the root parent of the 'post' being edited. If it is /blog/, we do nothing. Otherwise, we change its parent to the child of its root parent. Meaning, if editing /development/post1/, the root parent of the new tag will be /development/tags/new-tag/. But there's a catch.... Although the new tag(s) will be created fine, ProcessWire will not allow them to be listed as selectable pages since when setting up your page field, in order to be able to create 'new tags from field', as you know, you have to select both its parent and its template. The former is our problem. In my setup, the parent specified under 'Parent of selectable pages' is /blog/tags/. Since our new tag's parent in the case of development is /development/tags/ ProcessWire will throw an error 'Page 1234 is not valid for name_of_the_page_field'. So, it turns out our problem is not the actual page creation and contextual parent assignment, but the listing! That, from what I can tell, can't be circumvented via a Hook. Is there any reason you cannot use different templates and fields for /blog/post/ and /development/post/? Code to re-assign parent on new tag creation. Posted here in case anyone needs it. This was tested in a module. @note: the code could be optimised to only hook into the 'relevant pages'. public function init() { $this->pages->addHookAfter("added", $this, "changeTagParent"); } public function changeTagParent(HookEvent $event) { // get 'post' page being edited $process = $this->wire('process'); if($process && $process->className() != 'ProcessPageEdit') return; $pageEdit = $process->getPage(); // get the root parent of the 'post' being edited. we use it to determine whether to re-parent the 'new tag' $rootParent = $pageEdit->rootParent; // check root parent by path but can also check by ID, title, etc. if($rootParent->path == '/hook-tests-development/') { // newly created 'tag' page $page = $event->arguments[0]; // change the parent of the 'new tag' to /development/tags/ $page->parent = $rootParent->child(); $page->save(); } }

Just added a new "Email Batcher" action, which has the following features: Select recipients by user role, or using a pages selector for any pages on the site Parsing of field tags in the body so you can do something like: Dear {first_name} Option to send a test email HTML body, with automated text only version also sent Special {fromEmail} and {adminUrl} tags. Ability to hook EmailBatcher::parseBody to apply other custom replacements Don't forget TracyDebugger's Mail panel when testing - it will capture the outgoing emails (so they won't actually be sent): http://processwire.com/blog/posts/introducing-tracy-debugger/#mail-panel

The beta of UIkit 3 is out now. Sadly there is no Sass version yet, but I think it is on the way.

count('$child->children') remove the quotes.

As it says: "use pageName instead" /** * Format required by ProcessWire user names * * #pw-internal * * @deprecated, use pageName instead. * @param string $value * @return string * */ public function username($value) { return $this->pageName($value); }

Welcome @DarsVaeda, you could try to solve this layout with the recently introduced repeater depth. For example depth 0 are your rows and depth 1 are your cards. In combination with the commercial RepeaterMatrix this could be an pleasing solution for editors. Regards, Andreas

It will fit with anything. If you want it small, it will stay small. If you want a full e commerce solution, you can make it that. Shopping functionality can be added later or during, or before. It is not a pre-made solution. You get the same freedom as when designing your ProcessWire site. See more comments below. No. Padloper does not store credit card info. You would have to use one of the available payment gateways. Currently, there are two, PayPal and Stripe, both of which are available as free modules (by the same author of Padloper, @apeisa) The connection is seamless. With Padloper, you will have to be willing to 'construct' your shop so to speak. There is no ready-made template or anything like that. With this though, comes total freedom to code your shop just like any other ProcessWire template file since any page can be a product in Padloper. I suggest you read more on the product's website. There's also a public forum here where you can post further questions. I use Padloper myself here.

@szabesz I trialed a few years ago and didn't really like the interface as compared to Winmerge on Windows. Didn't realise they have a OS X Client now. @adrian Thanks for the head's up. I've discovered something called SyncThing so I'll probably look at this first. If I'm not happy with it, I'm definitely getting a commerical solution.

Actually, no. I ended up doing that, since it was the least cumbersome way of doing it. Other methods requires going through hoops to modify core behaviour, which I wanted to avoid doing too much in the first place. I created created another field "devTags" and renamed the original to "blogTags" and created a new template for posts under /dev named "work" /blog (template: listing) /tags (template: tags) tag1 (template: tag) tag2 post1 (template: post, field: blogTags) post2 post3 /dev (template: listing) /tags (template: tags) tag1 (template: tag) tag2 work1 (template: work, field: devTags) work2 then without changing the templates, I created a new property hook that redirects $page->tags to correct tags field (blogTags or devTags) depending on the name of the rootParent of the post/work. // return pages referenced with tags field depending on the rootParent wire()->addHookProperty('Page::tags', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; // check if field actually exists if (!$page->fields->get($fieldName) instanceof Field) { throw new WireException("{$page->template->name} template does not have $fieldName field."); } $event->return = page("$fieldName"); }); I also created another hook that lets me get the pages tagged with a specific tag, for when listing posts/works under the url /blog/tags/tagName // return posts tagged with the current tag page wire()->addHookProperty('Page::tagged', function (HookEvent $event) { $page = $event->object; $fieldName = $page->rootParent->name . 'Tags'; if ($page->template->name === 'tag') { $event->return = pages("$fieldName=$page"); } else throw new WireException('Only pages with tag templates can use tagged property'); }); # EXTRA: A bit of overengineering: change field name when rootParent's name changes // rename tags field depending on its rootParents name wire()->addHookBefore('Pages::renamed', function (HookEvent $event) { $page = $event->arguments(0); // check if page cant have tags template under it if ($page->template->name !== 'listing') return; // check if actually has tags template under it // if(! $page->hasChildren('template=tags')->count) return; $oldFieldName = $page->namePrevious . 'Tags'; $tagsField = fields()->get($oldFieldName); if (!$tagsField instanceof Field) return; /* @var $tagsField Field */ $newFieldName = $page->name . 'Tags'; $tagsField->setName($newFieldName); $tagsField->save(); wire()->message("Renamed $oldFieldName field to $newFieldName", true); }); Thanks a lot for the insight!

It's still a beta release and I'm not sure why they should worry about a sass version as it's ever been a less project and it's not yet a stable release. But the marketing strategy of replacing the whole website at this stage truely is strange.

Honestly I'm disappointed on what I see on UiKit3 release. I personally find it as @szabesz said as an "alpha" release... As an example : no more 12 colums for the width component (just 6...what?!), confusing grid classes (at least for me, but it's something I can learn quickly) and no sass version....

As you found, you can't change the $parent_id variable inside the InputfieldPage::processInputAddPages method using this type of hook because $parent_id is neither an argument to the method nor a return value of the method. I think you would have to use a replace hook - copy the whole InputfieldPage::processInputAddPages into your hook function and change as needed. Bear in mind that doing this means that any future core changes in InputfieldPage::processInputAddPages will not take effect while your hook is in place.

This is a Leaflet version of Ryans Google Maps marker module. @Github

Custom Inputfield Dependencies A module for ProcessWire CMS/CMF. Extends inputfield dependencies so that inputfield visibility or required status may be determined at runtime by selector or custom PHP code. Overview Custom Inputfield Dependencies adds several new settings options to the "Input" tab of "Edit Field". These are described below. Note that the visibility or required status of fields determined by the module is calculated once at the time Page Edit loads. If your dependency settings refer to fields in the page being edited then changes will not be recalculated until the page is saved and Page Edit reloaded. Usage Install the Custom Inputfield Dependencies module. Optional: for nice code highlighting of custom PHP install InputfieldAceExtended v1.2.0 or newer (currently available on the 'dev' branch of the GitHub repo). The custom inputfield dependencies are set on the "Input" tab of "Edit Field". Visibility Show only if page is matched by custom find Use InputfieldSelector to create a $pages->find() query. If the edited page is matched by the selector then the field is shown. Show only if page is matched by selector As above, but the selector string may be entered manually. Show only if custom PHP returns true Enter custom PHP/API code – if the statement returns boolean true then the field is shown. $page and $pages are available as local variables – other API variables may be accessed with $this, e.g. $this->config In most cases $page refers to the page being edited, but note that if the field is inside a repeater then $page will be the repeater page. As there could conceivably be cases where you want to use the repeater page in your custom PHP the module does not forcibly set $page to be the edited page. Instead, a helper function getEditedPage($page) is available if you want to get the edited page regardless of if the field in inside a repeater or not. $edited_page = $this->getEditedPage($page); Required The settings inputfields are the same as for Visibility above, but are used to determine if the field has 'required' status on the page being edited. https://github.com/Toutouwai/CustomInputfieldDependencies http://modules.processwire.com/modules/custom-inputfield-dependencies/

Thanks @adrian Useful new features as always. You cannot help it but help us

Bandcamp might be a good option for the selling part?

Hello @cyberderf, there is not an tutorial available for this profile, except the blog post about the new demo site. In this blog post there are some of the new functions explained, which were used in this profile, but if you wan't to know more, you will have to dig through the code. Keep in mind, that this an advanced site profile. If you haven't worked with delayed output before, you should first read this tutorial. Regards, Andreas

I don't understand exactly what are you trying to say. I think it is, that for web based IDEs you don't need an powerful machine and only an fast internet connection? For people who travel a lot and only have a netbook on their hands that is helpful. As I am working only on one place with a desktop computer, I am obviously not the target group. But everybody should use what fits best to their needs. Some people also prefer to code only in the command line. Recently I discovered this funny editor: Code in the Dark. Wait till you get to POWER MODE! There is also an extension for Atom available.

Here is a more detailed blog post about the release of the Beta with an explanation, why they launched UIkit 3 this way. In my opinion the docs are already good, but if you don't like them, you can report an issue on the GitHub repository of the docs. The width component is new in UIkit 3 (see the blog post), but if you meant the grid component, in UIkit 2 it only had 10 columns max. That is still more than 6, but personally I can't remember any use case for such small columns. Yes, it is a Less project, but they had support for Sass since 2.11.0. They also said it is planned, but not done yet. As already mentioned, picking a framework isn't always about being lazy or trying to avoid custom code, it can be about finding common components for every contributor to make contribution much easier. I would welcome if ProcessWire would implement UIkit as framework for its back end.

Ok, some further delving. After removing the line: $(".hide_when_crop").hide(); Then going to page where the image is, click 'Crop', click the crop icon button... The original values for me were like the above. See this second screenshot below, the dimensions have changed. They are the actual size of the image as shown on the screen in the modal window. I wondered why these numbers were so random until I did it a few times resizing the window. The dimensions on the right are correct (and the overlay size with the draggable handles), this image should be cropped at 2400 x 630. Could the script use these values instead? This is where I think the script poos the bed. It sees 644 and says "wait, it's supposed to be at least 2400px!". However, the source code for the field that says 644 above shows different: <input title="Width:" name="width" id="input_width" class="input_pixels" type="number" size="6" step="1" min="2400" max="2400" value="2400"> ...so, I clicked on this field and try to modify the width setting which would usually be hidden by the above javascript (causing the 'not focusable' error because it's hidden). In my case, the value automagically changed to my desired width setting of 2400 and could not be further changed (because less than that violates my min-width, more than that violates my max-width). When this window first popped up, the value of width for me was ...click 'Apply'. Bingo. The height above of 1800 clearly isn't the real height of the resulting cropped image but this didn't cause me an issues because I haven't set a min or max height. So, I conclude that it's still not working as intended, but I guess we're moving in the right direction!

I have committed a new version which: adds a new "From Name" field setting so that the email new users receive comes from your name/email, not just a raw email address. adds support for HTML body text. A plain text version will be generated automatically from this and both sent with proper headers. makes the parseBody method hookable, so you can define more complex field tag replacements. For example, this will accomplish @Timothy de Vos's needs: $this->wire()->addHookBefore('EmailNewUser::parseBody', null, function($event) { $page = $event->arguments[2]; $pageId = $page->location; $replacement = "http://".wire($pageId)->parent->name.".".wire('config')->httpHost; $event->arguments(0, str_replace('{location}', $replacement, $event->arguments[0])); }); Please let me know if you have any problems with this new version! Thanks to Timothy for helping to test this new version and as he noted, if you want full HTML support in the supplied CkEditor body input, you'll need to set: config.allowedContent = true

More info here: http://processwire.com/api/ref/session/csrf/ In addition, excerpt from /wire/config.php. Emphasis here is on PW forms (on by default) /** * Protect CSRF? * * Enables CSRF (cross site request forgery) protection on all PW forms, recommended for improved security. * * @var bool * */ $config->protectCSRF = true;

I think what @tpr says is right, I guess it could be super complex. I am also still a newbie in Processwire and don't know that much about programming as tpr, adrian etc etc I am always available if anyone needs some help. In a few weeks my internship is over and school starts again for me, hoping to have time left then for PW...

I like that VPS gives the advantage of the whole Linux tool chain (if using linux) , now including wireshell. With the disadvantage that, I never want to work on shared hosting that has no shell access lol. That, plus ServerPilot to set up the whole deal, just makes my life much easier.

i would not see this as a problem. but i also don't want to discuss this further - uikit is just a personal preferation of mine. ryan will have to weigh all pros and cons and i'm sure he will take a great decision

@LostKobrakai Lots of valid points, still... I think this option should at least be considered by taking a close look at it. What if the chosen framework can be extended, rather than hacked?

no, don't have enough time to follow the forum atm. i just saw some nice previews of uikit3 and was supposing that uikit 3 is as solid and awesome as uikit 2 was whatever framework it will be... I'm with you that any kind of framework will make it easier to collaborate and/or to get the context of how everything works in the admin more quickly.

uikit 3 is now available as beta: http://yootheme.com/blog/2017/01/09/uikit-3-beta-released would be a perfect timing for a new admin *dreaming

Ryan mentions UIkit in his comment here but reading it again he is only considering this.

Where did you pick up that information?

To pick a capable "Bootstrap like" framework is not just about supporting non-CSS-ninjas, it should be more about teamwork support. An easy to use, reasonably well documented framework is something everyone can pick up easily so more contribution can be expected in this regard. UIkit v2 seemed to be a good choice, however at this stage I'm not so sure about v3, but let's see what the future holds After all, it is still "beta".

Quick update. Removing the line: $(".hide_when_crop").hide(); from ProcessPageEditImageSelect.min.js reveals a possible problem. When clicking apply, a popup shows [! Value must be greater than or equal to 2400px] pointing straight at the 831. Not sure if this is related to the original error, haven't got enough time right now to look into it further.

Thank you guys, I've posted this issue on GitHub.

There is continuation of this discussion with some solutions on github. This seems to be the problem with locale settings.

I mean you have an extra checkbox field in your template and when you give someone the unlimited minutes plan you check the checkbox. This adds another step in your code though, as you have to verify if the checkbox is checked for every plan. // isUnlimited is the checkbox fields name // numberOfMinutes is the field that holds the number of minutes if($page->isUnlimited == 1) { $plan = "unlimited"; } else { $plan = $page->numberOfMinutes; } // so if the checkbox is checked the plan becomes unlimited regardless of what the value of numberOfMinutes is Might be possible with a custom sort function, but what you could also do is have one variable for -1 and one for the rest $plans = ""; foreach($page->numberOfMinutes as $minutes) { if($minutes == -1) { $plan = "unlimited"; continue; } $plans .= "{$minutes} <br>"; } echo $plans . $plan; // or echo $plan . $plans; Or you could simply add a huge number for the unlimited plan like 999999 (that's about 694 days in minutes).

The custom PHP behaviour was changed recently with v3.0.45, PW no longer allows using custom PHP in frontend, it asks you to use a hook. https://processwire.com/blog/posts/pw-3.0.45/

I had a few minutes for a quick look and searched the forum about showing the child of a child. Found some very resourceful info and decided to organize the things elegantly. To do this, I created a new template calling it articles-categories and assigned to it the articles fields. After playing with $render I was able to pull up the list of articles including the children (software etc.) Then it was just a matter of moving the child pages to software and allowing the articles template for the new child to be articles-categories. Then I came up with the idea to list only the child-cattegories in articles so that a visitor can choose what he is looking for and click on the proper howto group. Once I get back home I will share the code I used as I still need to work on it a bit in order to make it fully working. Having this approach eliminates the page duplication as if you browse the /articles/ you will only see the child but not their children. For sure, if you click on the children in Articles, then you will see all the parent-name related articles. Let's see how that goes and hopefully there will be no more surprises on this. To make the theme looking better I will remove the date and time of adding from the articles template as it would only lost the groups and it is not needed to show such info

https://getuikit.com/v2/ It is hard to believe that they just replaced the frontend of the old site at this beta stage. The new docs looks alpha and is rather hard to read too. I hope v3 will be a great success, but this is such a dumb launch

Last year I discovered Processwire (after the summer). I don't know why, but I had an immediate connection with it. Now I produced my new website with it. You can check it here: http://www.projectweb.be

v0.0.2 released - a complete overhaul of the module. Custom Inputfield Dependencies now does the same thing but in a completely different way (thanks to a great idea from @adrian) The module no longer requires Hanna Code and inputfield dependencies are now set on the "Input" tab of "Edit Field". See the first post for all the details. If you are using v0.0.1 of the module then this is a breaking change and you will need to redefine your dependencies (sorry ). But the new approach taken in v0.0.2 is so much better that hopefully you'll find the change worthwhile.

Field import/export is even in recent processwire versions declared a beta/experimental feature to be used with care. So while this might sound harsh your issue is not more of an security issue than any other one a developer might introduce by uncareful actions. Especially the more complex fields like repeaters / pagetables are prone to miss-matches for some of the plain id values they're using, which is probably the no1 reason, why the feature never made it into stable form by now. The things to consider on processwire's side would be to make the import process customizable by fieldtype so that the repeater fieldtype can force an update of the parent_id on import. This can only work for repeaters, as the parent pages are not user changeable. The other thing to consider would be to make the pagefiles directory be lazily created, so that pages without actual files do not create directories. This wouldn't have prevented your infinite loops, but at least the part of filling up all your disk space.

This is an old PW version. Repeaterfields have gotten a complete overworking and additional features since then. Does the new version (PW 3.0.45+) behave the same?

Just to chime in: Fantastic Module @adrian

Thank you @adrian! It is amazing to watch something being created with such an amazing pace by people like you and ryan. And so much to learn from. I recommend everybody to go through these guys' code to learn how you can be really powerful using ProcessWire. Another little idea. Not sure it is necessary, but seems logical to me to separate "core" actions and those specific to the site. Like core ans site modules. I can see this module to be a base to easily create little things that would other way need their own process modules. In that case, most of the time I would use only custom actions... A filter option or a tab. What do you think? I know, that for everybody but admin I can achieve about the same with by-action role assignment. But as I almost always login a superuser myself...

Small Website for German Food Magazine Subscriptions - according to design guidelines from the client. https://rezeptemitherz.de/ It's more of a web application than just a website. Lots of code under the hood. Has a flip-book catalogue (see "Magazin") Collecting subscriptions and individual orders and forwarding them condensed in daily reports to the distributor as csv files according to their guidelines. Timed drawings with automatic selection of the winners, and more... Heavily relies on/and extends the FormBuilder PRO module.

Check out advanced mode in config.php and you'll have this for each template: Maybe doesn't take care of everything you need, but remember that the status can also be changed from the Page List view via the extended (after the arrow) action buttons.

First of all, my examples were not right - not at all, sorry. Now they're fixed. The problem is that you're limiting pages under each "subchild" separately, not all grandchildren at once. Here's one way to get there: $limit = 4; $cats = $pages->get("/mypage/")->children; foreach ($cats as $cat) { $menu .= "<div>"; $menu .= "<h2 class='titlebg'>$cat->title</h2>"; $grandchildren = $pages->find("parent={$cat->children}, limit=$limit, sort=-date, sort=title"); if($grandchildren) { // if they have GRANDchildren $menu .= "<ul>"; foreach($grandchildren as $child) { $menu .= "<li><a href='{$child->url}'>$child->title</a></li>"; } $menu .= "</ul>"; if($grandchildren->getTotal() > $limit) $menu .= "<span><a href='{$cat->url}'>See More</a></span>"; } $menu .= "</div>"; } This would give (with the example structure again): cat1 cat2 child2.1.1 child2.1.2 child2.1.3 child2.2.1 See More cat3 child3.1.1 This trick to get grandchildren ("parent={$cat->children}") would not be the way to go if there were a lot of "subchild" pages under any "cat" page. This is because the selector expands to something like "parent=1234|1235|1236|1237|...|1507|1508" giving a too long selector string at one point. But assuming there aren't more than a couple of dozen of them, this would work just fine. I also added a little condition to show "See more" only if there are more grandchildren to see - just as an example.

trackChange() is a method on every Wire derived object, which includes most of ProcessWire's objects. The question would be what you are calling trackChange() on and whether the change tracking state is on or off? Also, there are related methods, also accessible everywhere that trackChange() is: // turns change tracking ON or OFF $obj->setTrackChanges(true|false); // returns TRUE if change tracking is ON or FALSE if off $bool = $obj->trackChanges(); // returns an array of changes that have occurred $array = $obj->getChanges(); // tracks the change, only if change tracking in ON $obj->trackChange('field_name'); // clears the list of tracked changes $obj->resetTrackChanges(); // hook that is called anytime a change occurs: only useful if you want something to be notified of a change $obj->changed(); My best guess is that you may need to call $page->trackChange('field_name'); rather than the form itself. That's because the form is managing most of that on it's own, and may be clearing/resetting the trackChange call you did. Also, a page's changes are cleared after a successful save(), if that matters.