Leaderboard

@adrian and @thetuningspoon thanks! ? Needed some tweakage as FieldsetPage, although based on Repeater, only has one page, not a number of child pages under the repeater page, in admin. Got it working with: /** * Creates a fieldsetpage field with associated fieldgroup, template, and page * * @param string $repeaterName The name of your fieldsetpage field * @param string $repeaterFields List of field names to add to the fieldsetpage, separated by spaces * @param string $repeaterLabel The label for your fieldsetpage * @param string $repeaterTags Tags for the fieldsetpage field * @return Returns the new FeildsetPage field * */ public function createFieldsetPage($repeaterName,$repeaterFields,$repeaterLabel,$repeaterTags) { $fieldsArray = explode(' ',$repeaterFields); $f = new Field(); $f->type = $this->modules->get("FieldtypeFieldsetPage"); $f->name = $repeaterName; $f->label = $repeaterLabel; $f->tags = $repeaterTags; $f->save(); //Create fieldgroup $repeaterFg = new Fieldgroup(); $repeaterFg->name = "repeater_$repeaterName"; //Add fields to fieldgroup foreach($fieldsArray as $field) { $repeaterFg->append($this->fields->get($field)); } $repeaterFg->save(); //Create template $repeaterT = new Template(); $repeaterT->name = "repeater_$repeaterName"; $repeaterT->flags = 8; $repeaterT->noChildren = 1; $repeaterT->noParents = 1; $repeaterT->noGlobal = 1; $repeaterT->slashUrls = 1; $repeaterT->fieldgroup = $repeaterFg; $repeaterT->save(); // Create the admin/repeaters page (different to standard repeaters) // add more options to the page if you prefer $repeaterPage = new Page(); $repeaterPage->of(false); $repeaterPage->template = 'admin'; $repeaterPage->name = "for-field-" . $f->id; $repeaterPage->title = $f->name; $repeaterPage->parent_id = $this->pages->get("path=/admin/repeaters/"); $this->pages->save($repeaterPage); // Associate the FieldsetPage field with the new admin/repeater page $f->parent_id = $this->pages->get("name=$repeaterPage")->id; $f->template_id = $repeaterT->id; //Now, add the fields directly to the FieldsetPage field foreach($fieldsArray as $field) { $f->repeaterFields = $this->fields->get($field); } $f->save(); return $f; } and example usage: $fsPageName = "fspage_widget"; $fsPageFields = "widget_title"; $fsPageLabel = _("My Widget"); $fsPageTags = "widget"; $f = $this->createFieldsetPage($fsPageName,$fsPageFields,$fsPageLabel,$fsPageTags);

Quick update: version 2.0.0 of this module is now available via GitHub. This version includes updated RedBeanPHP library, various new config settings (including the ability to disable automatic setup of RedBeanPHP, and an option for choosing one of the trimmed down library versions with support for specific database type only), and various other updates to the module. I've also dropped support for PW 2.x and PHP < 5.4, and updated module requirements accordingly. For pre-3.x or pre-PHP 5.4 users the legacy branch still contains old version of the module.

I'd have to back this also. My logic being that it's a familiar set up for users of other e-commerce solutions such as Magento (who now use a sidebar in v2), prestashop, shopify etc. Also if they've all adopted the sidebar perhaps this is from some UX studies? Seems likely.

I put my vote on this one too. Conventions play a big role in usability and people still use computers or large enough tablets to get work done (e.g. managing a shop).

@David Karich , very useful, thanks! I mainly appreciate that there is no need to modify the template. Above you mention the ProCache module. Do I understand correctly that the counting will work correctly even with the standard PW template cache mechanism? One helpful feature would be the ability to display the page hits in the page tree only for given roles, that is using permissions. The reason behind is not secrecy but cleanliness, no clutter. Regards! ~loukote

Hello!!! It is good to hear that you are that far with your shop module. I am waiting for it!!! :-0) I think the second option would be the best. Because it is easy to work with especially on Desktop. I am looking forward for your great module!!! Have a good day! Gerald

I did some testing to see what is needed to get required-if conditions working within repeaters and opened a request here: https://github.com/processwire/processwire-requests/issues/262

With the Changelog activated I start receiving out of memory errors with the PW Backup: Fatal error: Allowed memory size of XXXX bytes exhausted (tried to allocate 20480 bytes) in //www-office/wire/core/WireDatabaseBackup.php on line 1269 Uninstalling Changelog makes the backups run fine again. ProcessWire 3.0.125 , Changelog 1.5.5 PHP 7.2 Apache 2.4 256 MB Memory Is anyone else seeing this? Update: I found out from a backup (when it worked) that the plug-in can collect huge amounts of data. I moved the info over to GitHub, with the details.

Awesome - glad you got it working and thanks for sharing the solution!

Okay I found it. The problem was that i was searching for "Page Clone" but I am using a german language pack in the backend. Since the module is already included in the core it was translated into german. So instead of "Page Clone" I had to look for "Seite klonen". ?

You need the files AND the database for a working processwire installation, so if you don't have a database dump anywhere, you'll not be able to run pw. Maybe you have a dump in /site/assets/backups/database ?

Not sure about 3.0.98, but with 3.0.123 its simple to add from Modules->Install. In the dropdown select "Process" and there you hopefully find "Page Clone".

Hey @ryan. I'm wondering if it would be possible to set up a repository for the new site, so that we could submit pull requests and report issues there? Personally I'd still like to suggest some usability / accessibility related changes and fixes, but currently that's a bit difficult to do – and it basically requires me reporting the issue, and then you having to figure out how to fix it for the site. If there was a repository, we could a) reliably keep track of issues that have been fixed or closed for other reasons (avoiding duplicate reports), b) submit changes so that you don't have to do everything yourself, and c) experiment with the site with ease. If the site has features that can't be made public, a repository containing partial site profile would of course do, but the best solution would imho be a full site that we can install locally, makes changes to, build, test for regressions, and so on. Or perhaps you could only share access on a case-by-case basis, since even GitHub now supports private repositories? ? Thanks for considering this!

Here are some minor glitches whenever you use <pre> for mixed HTML + PHP code: https://processwire.com/blog/posts/functional-fields/ html probably shouldn't be visible before <button> ...

This week we take a closer look at the upcoming ProMailer module with a lot more details and screenshots. Plus an update on next steps with the new website and development schedule in the weeks ahead— https://processwire.com/blog/posts/promailer-preview/

Same feelings also. I think Teppo really said well how I felt also when read the latest post (and discussion about api examples). That kind of optimization is nice per project, but it is really confusing for a platform that we use to maintain and build hundreds of websites and applications with multiple developers. I'm all in for introducing breaking changes for 4.0. That would get rid of compiler also.

I couldn't agree more - this was also my reaction with this latest version. I was thinking of mentioning this idea myself, but I love the fact that so far we've never really had any breaking changes in the evolution of PW. But unfortunately I agree that in v4 it's time to strip out lots of the experimental ideas that just haven't taken off. Think back to: $pages("template=basic-page") Has anyone here ever used that "variable as a method" approach for finding pages? I'd much rather spell it out with a get() or find() method. I know early on I was given some grief over all the shortcut methods in Tracy, but I think that's a different situation - those are temporary bits of code that don't stick around. For production stuff I like self documenting code over shortcuts that save a few keystrokes. I have no idea how it would be determined would would stay and what should be trimmed, but I think it's needed.

I must agree as well with all those alternatives and multiple ways for the same thing.... should really stop. I lost track long time ago and 99.99% never use any of them and really don't care at all. It's utterly confusing and I completely don't understand the reason behind it. It makes it harder than it should be. So many things goes against it...

I'm probably a well-known nay-sayer around here already, but I'm still going to add my +1 to this discussion. I feel that (particularly when it comes to API design) one clean and consistent solution should be preferred, unless an alternative approach provides major benefits. Multiple options only tend to make things more fragmented and more difficult to grasp, and doubly so when you're a new user. As such, I'm always thrilled when an update enhances the core somehow (performance, security, scalability) or makes something new possible or more streamlined (in this update valid() and validate(), plus the whitelist feature) ... but I cringe a bit when a new way of doing the same old without (seemingly) notable benefits is added. Personally I wouldn't mind seeing the core get leaner in the future, perhaps in 4.x. There are, and always will be, features that should be added to the core (shameless plug: FiedltypeDecimal), but on the other hand alternatives without major benefits or major user base, and modules that may not be particularly often-used should, in my opinion, be stripped out. A module I've been working on recently has an "alias" feature (that isn't even that important to the module, to tell the truth), which was getting way out of hand. You could provide its arguments in five different formats, at least, which all required their own handler methods. I was working on this feature on Sunday (once again), and finally got fed up with it, stripped all those alternatives out and replaced them with one unified solution: callbacks. Sure, a bit of syntactic sugar might've been lost in the process, but I also got rid of probably 75% of the required code, and the documentation page is now actually readable. So, yeah – I know exactly what you're talking about ?

Afraid I also agree with everyone here - too many options which I'll never remember - I'll be sticking with the traditional approach - verbosity FTW ? I feel like we are on a very slippery slope here and once you go down, you can't climb back out because you might break someone's code. I have always trusted Ryan's instincts about this stuff in the past (or he has at least convinced me in the end), but this time I am not so sure. I hate to come across as critical or unappreciative because I know that even in my own relatively simple modules I sometimes get caught up in going with too many options, so I do realize it's a tricky balance. I think this is a super important point!!!

<div id="result">Ajax</div> <script type="text/javascript"> $('#result').click(function () { var ajaxUrl = "https://example.com/ajax-page-name"; //not template path $.ajax({ type: "GET", url: ajaxUrl, success : function(data){ var markup = $(data).find('#result'); $('#result').html(markup); } }); }); </script> You need to call the URL of the page itself, not its template path. ?

It's been some time since I read the blog-post, but I really need to ask if we need the magic functions for the sanitizer, especially the grouped ones. They're hard to document, harder to be used for automated setups – where used sanitizers are aggregated by some coded means – compared to having them as parameters and I would say they're hardly simpler for manual usage over proper parameters. Personally I'd really vote for one clear way instead of having even more ways to do the same. For me there's also the reason that I find it way cleaner to work with data a.k.a. an array of sanitizer names vs. some magic naming, but that may just be me, but I think we really need to be aware of the backdraws of having to many options to do a thing in general.

Version 1.2.3 as new master version available All information about the changelog and bug fixings in the first post.

Just noticed that ProcessWire is listed at the new RedBeanPHP website's "frameworks" page, with a link to this module: https://www.redbeanphp.com/index.php?p=/frameworks. On a related note I should probably update this module to a newer version of RedBeanPHP ?

Hi Tester. Welcome to PW and the forums. Not sure what you want to achieve in the end but users in PW are also stored as pages. Hence, they come with a template. You can add as many fields as you like to the user template to store your data and retrieve and display these like any other field using your template file - hence extending "user". To view the "user" template, go to Setup->Template. Then under filters panel, under show system templates, select yes. Scroll down to the now revealed "system" templates. Select the "user" template and you are ready to start adding your custom fields to it . If you wish, you can then hide the system templates when you are done... About IDs, users are automatically assigned IDs when you create them Edited for clarity...

I added this to the dev branch last week, so that you can now pass additional things to $page->render(): https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/PageRender.module#L212 One of the things I wasn't thinking about before is that $page->render() was already capable of accepting an array of options (though not commonly used, mostly internal). So we weren't starting from a blank slate, and had to make something that was compatible and complimentary to what was already there. In terms of API calls, you can now do any of these: $page->render($filename); // $filename assumed in /site/templates/ $page->render($pathname); // $pathname is full path, but must resolve somewhere in web root $page->render($options); // array of options and/or your own variables $page->render(array('foo' => 'bar')); // same as above $page->render($filename, $options); // specify filename and options/vars, etc. The $options variable was already something that $page->render() accepted before. Only it was used to specify some little-used modifiers to render(). Those are still there (and they are necessary), but now the utility of $options has been extended. When you want to specify options (outlined in the link above) you only need to specify the ones you want to change from the defaults (of course). Typically you don't need to change them, so I'm guessing that most would use $options to specify their own variables. Every rendered template now receives a copy of that $options array locally scoped. That $options array contains any variables you passed to $page->render(). It also contains PW's default options, should you want to examine any of them. If you made this render() call: echo $page->render('myfile.php', array('foo' => 'bar')); myfile.php could access the 'foo' variable like this: echo $options['foo']; // outputs "bar" One other addition that I'm thinking people might like is $options['pageStack']. That is an array containing a stack of pages that called render(). So if you are doing any recursive rendering of pages, any template can access $options['pageStack'] to see what page is rendering it, and any others before it. Previously this was not possible, and the only way a template could tell what other page was rendering it (if any) was for that renderer to tell the renderee, via $mypage->caller = $page; or something like that.