Leaderboard

Both. The goal with ProcessWire is to be attractive web designers/developers with programming skills and those without programming skills. ProcessWire is primarily a CMF, somewhere in between a framework and a CMS, but with the ability to be completely one or the other as needed. The admin UI is an application on top of the API. No action in ProcessWire actually requires the admin UI. The admin UI is there to help you. If you don't like that kind of help, you are likely in the minority, but ProcessWire still has you covered. However, if you want to work purely in code you should also look beyond CMF/CMS and towards dedicated frameworks like Laravel. ProcessWire is fundamentally different from any of the CMSs you mentioned, and if you don't realize that yet then I'd encourage you to get to know the system better, and we're all here to help. While our system is fundamentally different, the web designer/developer side of our audiences are similar to those CMSs. Speaking outside of anything specific, we can't ignore what are likely our largest audiences. Perhaps in your system. Whatever limitations your opinion is based on are not present in ProcessWire. I put together a proof-of-concept here when the request came up a few messages above and I can assure you it works quite well. If there's enough demand for it, I'll finish and migrate it to the core. Though if it's something that less than 30% of people will actually use, then it doesn't belong in the core. This is why I'm more enthusiastic about supporting specific-audience features like this by extending API calls and hooks that help other module developers build these tools. Even when tools like this exist in a stable state, I see their value as being for migration and versioning, not for configuration. I don't believe any developer would choose to configure the rather comprehensive aspects of templates and fields from a text file. ProcessWire is more powerful than the systems you've mentioned. The options available to configure for any given field/template are not predefined like they might be in other systems or frameworks. The options vary broadly depending on what Fieldtype and Inputfield is in use (all of which are themselves plugin modules that define their own options). Options can also be affected by other plugin modules. Dependencies are also in place, meaning the presence and requirements of some configuration options can depend on the values already present in other options. Further, some Fieldtypes can ride on top of others (like some of the ProFields), maintaining their own configuration along with those of their host. All of these things lend themselves extremely well to a user interface, and greatly benefit the developer in many ways, especially with regard to instruction and documentation. All of these things can be configured from the API, and could certainly be configured from a text file. But I would consider myself very lazy and remiss in my responsibilities if I expected people to use text files (YAML or otherwise) as the primarily method of configuration for this. I sure wouldn't be a happy web developer having to use that. On the other hand, if you are dealing with a system that is limited to predefined options that are self documenting, then I'm sure a text file for configuration is just fine. But there's little point in comparing ProcessWire to such systems, because ProcessWire provides a level of power that goes far beyond that, and far beyond what I think anyone would find desirable to configure from text files. We use a user interface here for exactly what a user interface is meant for.

Starter - New Satchel Newbie - Pencil Sharpened Jr Member - Prep School Full Member - Terrible 4th sr Member - 6th Form Hero Members - Graduate Moderators - Prefects Admin - School Bully Edit: Sorry, this is very UK - possibly needs to be a bit more international for Terrible 4th (a St Trinians Reference) and 6th Form, which is the top years of UK secondary schools.

I wrote a little troubleshooting guide for htaccess + pw stuff: https://gist.github.com/NicoKnoll/3c96a3d42f69b21ff923

what is the inputfield selctable pages defined with? $field->attr("value", $field->getSelectablePages(new NullPage)); should work?

@tyssen, @jacmaes: released 0.0.2 which has a pure-php fallback for mysqldump and tar. Give it a go

Worked for me! Though you need to post silly answers too....

Does that mean, if I post a lot of silly questions, I'll be promoted? Well, that's easy ...

alejandro, I have also done a Foxycart / PW integration. This took me quite a while to get my head around too. Quite simply, it doesn't matter which hashing method you choose in FoxyCart (I chose sha256) This was my setup: 1. customer registers in FoxyCart 2. customer pays and datafeed is sent back to PW 3. password in datafeed is already sha256 so I just create a new user in PW with the already hashed password. 4. new PW user is setup which has a password which is sha256 hashed THEN PW hashed. If you are setting up a login form where this user can login to PW, all you have to remember is you must sha256 the entered password, and use that in the $session->login call Hope that is all clear

Wow - I am not very observant today am I I think it likely is the issue: https://processwire.com/talk/topic/4651-cant-delete-or-modify-repeater-item/ There is another post where Nico suggests upgrading to 2.4 and I think that fixes the issue for the OP, but I can't find it right now. Regardless, you should really be running 2.4 - lots of amazing new things

It's about output formatting, which is set off if not in template context. And image fields & output formatting is documented here: http://processwire.com/api/fieldtypes/images/

This should get you started: $f = wire('modules')->get("InputfieldAsmSelect"); $f->required = true; $f->attr('name', 'allowedRoles'); $f->attr('value', $data["allowedRoles"]); $f->label = __('User roles allowed to flag (use spaces to separate entries)'); $f->setAsmSelectOption('sortable', false); // populate with all available roles foreach(wire('roles') as $roleoption) { $f->addOption($roleoption->name); } if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; $wrapper->add($f); I see you are using owzim's config helper, which I haven't used, so let us know if you have any trouble incorporating it into your module.

"Pageimages::getThumb" PageImages is an array, but you need to get one image object $image->first()->getThumb() Or just change you image field to 1 max image ------ Also $this->pages->find("section_img!=''") maybe rather: $this->pages->find("section_img.count>0") since image field is an array, it's not a text

I don't agree. I believe the simplicity of the PW backend metaphors is powerful, easy to understand, and easy to navigate for any level of user. Additionally, it's possible to use the powerful API to bolt on a parallel source-file-based approach (see my earlier post about upgradewire). I'm not done making it complete, but I think then you can have both ways, without disrupting what's in place, oh so zen, and yet accommodating of other development models. I know it's far from complete and it's "different" than most proposed methods here which tend toward being integrated instead of on-the-side (i.e. modules and such, instead of stand-alone PHP), but I was expecting more discussion of my proposed approach here. A little vanity, maybe. Seriously, what am I missing in my proposal which would leave the current integrity of the system in place and allow for alternative development style that meet the requirements this thread is about? Speaking to YAML approaches, I thought it would be simpler and more functional to have an API like the one I made in upgradewire, where the model changes are expressed functionally instead of statically. It's about finding the middle way to expressivity, to have a lingo that's both declarative and functional.

Yes, it can be like ten people round a table all trying to swat the same fly ..... fun though

Only in this thread Joss went already from 1853 to 1855 Distinguished has to do with the access to the payed modules forum.

Hi Rodwyn, Welcome to PW forum Hopefully the example below help you out: Deleting $page->of(false); $itemToRemove = $page->Body_Repeater->eq(0); $page->Body_Repeater->remove($itemToRemove); $page->save(); Editing $itemToEdit = $page->Body_Repeater->eq(0); $itemToEdit->of(false); $itemToEdit->body = "My new content"; $itemToEdit->save(); Things you need to remember with Repeater is that Repeater Item is an actual page in processwire but being hidden in the tree and obviously Repeater field is an array of pages (wirearray). For documentation please refer to this page: https://processwire.com/api/arrays/ Hope this helps

Feasibly it's possible, but it's not desirable. Making wire('var') aware of context involves pre-compiling the template files to replace wire('var') with wire($this, 'var'). So it's something we do to provide backwards compatibility in template files. We won't be providing that backwards compatibility outside of template files, so people will have to use $this->var, $this->wire('var') or wire($this, 'var'); elsewhere. Also, a Static::syntax implies dealing with a framework that only has one context, which gives the appearance of a weakness that isn't there, something I think we'd want to avoid. While I'd really like to limit statics in ProcessWire as much as possible (just because they are more than often a bad programming practice), that syntax is perfectly fine for static functions where context doesn't matter or where you are passing the context into it. For example, $sanitizer functions would not need to have different behavior in different contexts. I've even seen some frameworks that do use statics for sanitization functions as well. In the end though, IMO they would still be better served by providing the same functions non-statically. The plan is that when you do this... $main = new ProcessWire('/site/'); $intranet = new ProcessWire('/site-intranet/'); ...everything in each of those two instances will be unique to those instances and whatever site files are stored in /site/ or /site-intranet/. That means that when a module is initialized, it is only initialized for the instance (whether main or intranet). When a module refers to $this->var, it's referring to API variables that are part of its instance only. This enables you to have multiple sites talking to each other. Currently this isn't possible precisely because PW uses statics for API variables behind the scenes. But the fact that we've kept that behind the scenes is a good thing because that means it doesn't matter how our API variables are stored. We can switch them to a stronger storage mechanism that would be tied to an instance. This is one reason why I deprecated the Wire::getFuel() syntax (that appeared in early versions of PW2) early-on... though you might still see it appear in a few core spots, which will need to be changed. But we've really tried to keep the public API clear of static calls so that the API would not have to change as PW continues to grow as a framework.

Around PW 3.0, I'm looking to make PW multi-instance compatible so that you could have multiple ProcessWire instances (each connected to separate databases) running from the same PHP code. This opens a huge amount of flexibility. But it also means that any kind of static references will have to disappear because function calls like Wire::getFuel('var') and wire('var') make the assumption that there is only one instance of ProcessWire running. This is one of the bad things about static calls in general. When that time comes, we will be able to apply contexts to our template files so that calls like wire('var') still work. But the reality is that non-static calls like $this->wire('var'), $this->var, and $var are technically superior when it comes to a multi-instance environment. So my opinion would be that it's not good to introduce new static calling methods when they may soon be obsolete.

Hi there, remember my Knowledge Base Site Profile? In there, I implemented a simple "internal bookmarking system", but hard-wired it into the templates then. In order to start rewriting this mentioned profile I made a module out of this page flagging thingy: https://github.com/marcus-herrmann/FlagPages/ With this module, a logged in user can flag/unflag pages, on whose template the flag link (see below) has been placed. These flags serve as "personal bookmarks" and are not a site-wide sticky setting. It's a proof of concept and not heavily tested, still! So please use with caution. Usage On the module's config page you can set the user roles allowed to flag pages. Per default this ability is restricted to "superuser". If you are adding further roles, please seperate the entries with whitespace: superuser editor foorule On the markup side, FlagPages module consists of two parts: Rendering the link and rendering a list with your current bookmarks. First of all, load the module via: $flag = $modules->get("FlagPages"); Rendering flag toggle linkThen, use the renderLink method and place the output in your template. By adding the link to all or just certain templates, you can control which templates can be flagged and which can't. echo $flag->renderLink(); The default output will be "Add {Name} to flags", or "Remove {Name} from flags". You can override these labels with parameters. For example: echo $flag->renderLink("Add %s to my bookmarks", "Remove %s from my bookmarks"); Rendering the flagged pages list echo $flags->renderList(); This will output a simple unordered list with links to pages the currently logged-in user has set a flag to. Installation Requirement: ProcessWire 2.4 (although I haven't tested it in older versions, frankly) Manually Download or git clone, rename the module folder to "FlagPages" and put it into your site/modules folder Go to modules overview page and click "Check for new modules" Install the module. The module will appear under "Flag" section. Download here Have fun! edit: Simplified renderLink param logic according to teppo's advice

This is an inputfield module integrating Trumbowyg WYSIWYG editor into ProcessWire, quickly hacked together after some discussion at the Redactor thread. Trumbowyg is a light-weight alternative to more feature-rich editors, such as CKEditor or TinyMCE. Both this module and Trumbowyg itself are still in alpha state. Customisation options include only a subset of what Trumbowyg provides, more will be added in the near future. Also, link and image features as seen in other RTE modules (TinyMCE and CKEditor) are not implemented yet. The module is available at https://github.com/teppokoivula/InputfieldTrumbowyg.

EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal... Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible. Repeating all the changes by hand on the live site is simply not an option I'm willing to consider. Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too. I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem. Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another. So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look: https://gist.github.com/b7269bb7bd814ecf54fb If you install this, create a "data" folder under the module's folder - migration files will be written there. Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them. How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice. I'm more concerned about the whole idea of capturing changes and repeating them this way. Any thoughts? Is this approach wrong for some reason? Would this even work?

Hey all Since the topic of backups comes along every so often I decided to write a module to encapsulate some code I use for backups on Linux installs. It's not quite ready yet as I want a fallback option for Windows as well as an option for Linux that will work on shared hosting where you usually cant run system commands, but it is 80% complete for stage 1 and Linux backups work nicely. The general idea is that you set the number of days to store backups (I standardised it to 1 day, 3 days, 1 week, 2 weeks, 1 month, 3 months, 6 months and 1 year rather than having it as an integer field because I think these fit the most common scenarios and I wanted to have a dropdown in my module config too It defaults to 1 week, but depending on the size of the site and how much space you have you might want to increase or decrease the retention period. The idea is that you are given a URL with a unique hash (generated at install) which you then pass off to a cron job or Windows Scheduler and this generates the backups. It will be expanded on once I've got the backups working across different environments but the initial plan is to release a version that simply backs up the site and database, then a version that has a page where you can download backups from as well as an option to FTP/sync them to another server. I don't want to tackle restores though as this would be difficult - you are logged into the admin whilst running the restore so I think the first thing it would do when it has restored the database is log you out, plus I don't want to make assumptions about replacing a user's /site/ folder so I think restores require some manual intervention to be honest. An alternative would be to do this anyway but rename your /site/ folder and take another database copy before restoring, but I'm getting into the realms of trying to be too clever then and anticipate what people are trying to do and ProcessWire is all about not making assumptions Fortunately I have access to a site with several gigs if uploaded files as well as a reasonably large database so I should be able to monitor how well it handles that on Linux and Windows, but smaller sites shouldn't take more than a minute to backup, often a matter of seconds. I shall keep you posted.

Hi i just finished website that i build on processwire. Im a frontend developer and noob with php. But with processwire i managed to build this site, so i want to thank you for giving us such a great tool for building websites. Here is website in Polish, and in a month or so i will release english version of the site. http://hejtuje.com english version will be avaible in here : http://hate.it Some feedback would be nice . Thanks PW!.

Now available in the modules directory: http://modules.processwire.com/modules/password-force-change/ For anyone who might have downloaded early on, please grab the latest version. There was an important fix two days ago that now prevents users from simply navigating away from their profile page to another page in the admin. Now they can't do anything in the admin until their password has been changed.

Have a read here as well for 'Best practices before upgrading' https://github.com/ryancramerdesign/ProcessWire#upgrades

> We use a user interface here for exactly what a user interface is meant for. Agree - however... > I would consider myself very lazy and remiss in my responsibilities if I expected people to use text files (YAML or otherwise) as the primarily method of configuratio I don't think anyone has proposed or suggested that? We're proposing a supplement/alternative, not a replacement. At least I would never suggest that, and I don't think that's what rajo was trying to imply. Ryan, do you have any thoughts on what I mentioned a couple of times earlier - changing the API internally to use a command pattern for changes to the data model? If every change to the data-model had to be submitted to a command processor in the form of an object, and those objects could be serialized, and assuming the command processor was hookable, that would make it trivial to implement all kinds of synchronization / change management / logging / recording modules. The problem with manipulating schema directly, is you can't only tell whether something changed, not how it changed or why - you are already working around this fact by introducing things like change-tracking internally in the objects, which need to know what changes were made. For example, when a field gets renamed, there are methods to capture that change and work around it's side-effects. When dealing with schema, I find it safer to have a centralized facility through which detailed records of change pass through - rather than manipulating individual aspects of the schema independently here and there. Template changes and Field changes, for example, are closely related because they are components of the same schema model - yet these changes are completely unrelated at the API level. A command facility could provide a central API point where all schema-related changes would be exposed, even future (and even third-party) changes would pass through it, so for example a synchronization module could work with future/third-party extensions to the data-model...

Going back to the idea of some sort of badge for modules in the directory, maybe instead of saying "certified" it could say "approved" instead, which gets around the issue Joss mentioned in the last paragraph of his post. I think as long as there is some clear wording accompanying this then it would be fine. I like the idea of something like this to say it has had some sort of check anyway, as well as something to distinguish "approved" modules in the admin. It would also lead people to post to the modules section more as there are some modules that only end up linked from the forums which is a shame. @pwired: they have 32,411 plugins for Wordpress - I suspect if we did then we might encounter the same problem (though I hate the idea that we might have 1,327 of those with the word "gallery" in the title like WP do - lots of duplication there!).

Hi Adrian I'm using version 2.3.0 Do you think that's the problem? Exactly Horst. Do you think that's the problem?

He uses 2.3.0

Oops - nice catch horst. That's what you get for copying and pasting from different things in a hurry I would recommend removing the first one. The approach in the second one insures you won't get an "Undefined index: allowedRoles" error before any roles have been chosen.

@adrian: doesn't you populate two times the value here? $f->attr('value', $data["allowedRoles"]); and: if(isset($data['allowedRoles'])) $f->value = $data['allowedRoles']; Which one should be used with the ASM ?

That's what I am aiming for, but I'm not quite sure how to do it (sure - using $this->modules->get("InputfieldAsmSelect") - but then, no idea, really). Frankly speaking I'm not sure if even the comparison of allowed roles array vs. current user roles array is done elegantly. It works, though. Since this is my first module, I wanted to take only tiny steps forward But if anyone point me to the right direction I would be very thankful.

What Soma is getting at is that because you are in a module context, the "image field to 1 max image" setting doesn't work to convert the image field from an array to a single image, so you must use first(). eg: $bgImg = $s->section_img->first(); Here's a worthwhile read: https://processwire.com/talk/topic/1125-images-field-returning-array-even-when-max-files-set-to-1/

I doubt it's your fault. Behaviour of copying pagefield content is actually something I am struggling with for Migrator (and the main reason I haven't "released" it yet). The current behaviour is to automatically create the required templates and pages for any page field that is part of a page that you chose to migrate. The problem is where to put these page field pages. If they are not within the page tree that you are migrating, or if the parent they are under is not available on the destination site - what to do? I think the desired behaviour may be different depending on whether you are migrating content from a dev version to a live version of the same site, or whether you are importing content from one site into another one that doesn't already have the page field content in its structure. I hope that makes sense - even I am having trouble understanding what I just wrote That definitely sounds like the issue. It's not the importing of users/roles that created the content (Migrator handles this well), but rather the problem of trying to re-create the users that are selected in that select page field. I'll obviously have to revisit my current approach to migrating page field content, especially for scenarios like this. The problem is that if the page field pages are not under the exported parent and you don't include them, then that will result in broken page fields on the destination site. What to do ? I'll marinate on this for a bit, but I'd also really appreciate any thoughts! Macrura - if you feel like testing, I'd really appreciate knowing if everything works fine if you remove that page field from the site before you export. It should work fine with other page fields, but the linking to users must be the issue. Thanks and sorry for the hassles! EDIT: Would you mind PM'ing your exported json file so I can see exactly the structure of the page field? I am thinking that maybe an option would be for the export to contain the full page path to the pagefield's content pages and if that path exists on the destination PW site then use that. If not, then create these pages under the Home page. Hopefully this can be solved in a logical way that works in all situations.

The following titles can be reached by simply posting on the forums: Starter: 0 Newbie: 2 Jr. Member: 10 Full Member: 50 Sr. Member: 100 Hero Member: 500 These are just the defaults I think and could be renamed to something more fun perhaps?

OK cool - thanks for the advice, I will try upgrading PW and PHP and let you know if it solves the issue.

For all of you who want the model stored in files, maybe you should have a look into Bolt CMS. In Bolt you can configure your content types in YAML files and import them via a migration tool integrated into the CMS. In my opinion this is by far the best approach. This enables... versioning of data structure easy deployment working in teams (because branching/merging in Git workflows is now possible) much faster editing of data structure (for professionals) than clicking through UIs What I miss in this discussion is, what is the audience of users of Processwire? Do we want to be attractive to professionals working for clients (I would count me to this group) or is Processwire just another CMS that will blow up its backend UI (like Joomla, Drupal, Wordpress) because it wants to be attractive to users without any programming skills? My personal opinion is you cannot combine both groups in one system.

If I understand it correctly, this is not yet possible in a native way, but part of Ryan's plan for the future, see: https://processwire.com/talk/topic/6514-implement-yet-another-way-to-access-pws-globals/?p=63773

Hi! Is this applicable on managing data? specifically editing. Our app will not render any data on template file. This mean that all of our data will be fetch by another framework. So I will not put any code on the template. And I will only use this idea on editing a page on admin side. Is there any way processwire can do this without any APIsh approach? By the way. Nice idea

The Table fieldtype doesn't support files or images. Of course a link to an image is really just a file path so you could theoretically store these path in a table field, but you'd have no way to upload the images to the server. Depending on the size of the gallery and what information you want to record for each image, I would actually recommend using an individual child pages for each image. Otherwise, the new PageTable field might also be a good solution. There isn't much documentation on this yet because it is only available in the dev version, but it is very powerful. It is a core module in the dev version, but not installed by default. Some links for you: Gallery tutorial from Joss which uses a single images field: http://wiki.processwire.com/index.php/Simple_Gallery_System Another tutorial from everfreecreative: https://processwire.com/talk/topic/3990-another-simple-photo-gallery-tutorial/ Post from Ryan about the advantages of having one image per page for its ability to store whatever metadata you wish: https://processwire.com/talk/topic/417-extending-image-field/?p=6982 Remember that a "page" in processwire is really just a row in a database file and show shouldn't be considered as being a workaround - it is actually very efficient and effective.

I've seen this before and if I recall correctly in our case this was due to a PHP version below (<) 5.3.8. When we updated the problem was gone.

As for feature set: my aim is not to solve each and every e-commerce situation there is. I would consider this more for "small shops" at this point, haven't tought about scalability for hundreds thousands orders for example. Here is short feature lists what I have so far and what I am planning for release: E-Commerce modules: Shopping cart Support for different delivery modules (these changes whole checkout process, what fields to ask from customer, what to show after payment success / fails etc. Currently I have done "DeliveryEmail" which only asks email address from customer and then sends email confirmation with possible download links. I will implement more general "DeliveryPostage", where we ask postal addresses also) Support for different payment methods (currently stripe implemented, looking for paypal too for the release - payment methods are independent, so they can be used in other projects too than only this shop) Admin page to manage downloads Fieldtype to attach downloads to products (products are always pages) Since products are pages, support for variations etc are easy: just use repeaters or PageTable. Admin page to manage orders: printing packing slip, mark them as delivered etc... (50% done) Admin page for simple monthly reports (todo) Multiple taxes and taxes for products (todo) These E-Commerce modules are planned in a way that first you build your product catalog (just using ProcessWire) and then install these modules (only those modules you need). So in a way these are quite a "transparent" glue there. Shop profile (might implement this after the beta period): Starter profile for "full featured" shop: product template, categories, tags, product search, related products etc... Can be used as a standalone shop or just for educational purposes (look how certain features are implemented and add them in own store).

I hope to open beta testing soon - planning to open it first for just one or two person and then after that start selling it with 50% off beta pricing. Yes, this is totally new system, no single line from current shop module used. Yesterday I got file downloads working. Couldn't use PW:s pagefiles, since those would have been public (because product page is public). So I ended up having general "downloads" section, where shop admin can add/edit/remove file downloads, and then new "downloads fieldtype", which allows attaching those downloads to page. This method has one drawback: adding file downloads is two step process (first add file into downloads section, then go edit product to attach it). There are some good sides also, especially if same downloads are found from mulptiple products and the files are updated every now and then. File downloads work by "codes", which are unique for each file and each order. You can set rules how long codes are active: for n or unlimited downloads or until certain date or always. There is also possibility to "re-deliver" digital downloads order from shop admin, so customer gets new email with fresh download links.

@Mike Very pro and clean!

What about certificated modules? Like every module in the modules section should be checked and afterwards gain a link containing a code. If you cick on it the certificate is shown containing module version release date and source and the md5 key to check if something is modified. Something like this. So you would know if you're using a safe module (with serialization, etc.)

As harsh as it may sound, I'd say that this isn't something we can affect, and thus not something we should worry about. The best we could do in this regard would probably be adding some sort of indicator to admin whether a specific module is found from the modules directory or not, just to make it obvious that you really are on your own there

I'm the last person to stand up for WP (seriously), but still have to point out that neither of these are really issues with WP itself. In fact most of WP problems I've seen have been related to 3rd party plugins/modules. I'm not saying that it's not the fault of the system in some way, as they really should provide a safe platform for 3rd party extensions to build on (and clearly that's not always true in the case of WP), but they (WP core developers) can't be held responsible for whatever crappy code people implement on top of the good parts of that platform. .. oh, and my main point is that this should really serve as a warning for us too: it's entirely possible, if not exactly easy, to create modules with vulnerabilities on top of ProcessWire. As the amount of modules grows, issues like this become more likely and thus we (module authors and users alike) really need to take an active role on preventing them. IMHO.

If I understand correctly I don't think there is a built in way of doing this, but I have done something like this programmatically in front-end forms, so you could do the same with a hook on an admin form template. Curious though what your use case is. Couldn't you just have two page fields with the different parents? If not, one solution might be to hook on ProcessPageEdit::processInput and take the value from a text field (child_new) that would be where you'd enter the name of the new page, and then have a select for choosing which parent you want it added to (whichparent). I would actually disable the allow new pages to be create from field option to avoid confusion. Then after you have created the new page from the value of the text field, set it to blank so it can be used again. Sorry I don't have much time right now, so this should be considered pseudo code and ugly pseudo code at that, but maybe it will get you going! class NewPageCreator extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'New page creator', 'summary' => '', 'href' => '', 'version' => 1, 'permanent' => false, 'autoload' => true ); } public function init() { $this->addHookAfter('ProcessPageEdit::processInput', $this, 'addToParent'); } public function addToParent($event){ // ProcessPageEdit's processInput function may go recursive, so we want to skip // the instances where it does that by checking the second argument named "level" $level = $event->arguments(1); if($level > 0) return; $pp = $this->post->input->whichparent; if($this->input->post->child_new == '') return; //if no child_new entered, leave now $newchild = new Page(); $newchild->template = $this->templates->get("template-name"); $newchild->parent = $pp; $newchild->of(false); $newchild->title = $this->sanitizer->text($this->input->post->child_new); $newchild->save(); // Save the new child $pp->test_page = $newchild; //add it to the list of selected pages for the page field $pp->child_new = ''; //empty the child_new field - it is now in the main child field $pp->of(false); $pp->save("child_new"); } } I revised this significantly and did a little testing. This should now pretty much work, although note that field names for child_new and whichparent are hardcoded.

Thanks for posing this Kyle! A few things to mention: For even more security with the activation code, you might want to use something completely random that isn't influenced by the username. We have something built-in that will do the trick: $p = new Password(); $hash = $p->randomBase64String(100); // 100=length of string See here how it works: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Password.php#L154 (code is originally from Anthony Finta's password_compat library). Make sure that you are using $sanitizer->pageName("username"); for your username sanitization. Using $sanitizer->text(); is not adequate for sanitizing usernames or any selector values. In your function that checks for duplicate usernames, check for duplicate emails as well. When you check for users or emails do $users->get("name=$username") rather than $users->get($username); as this will ensure it's checking for only the username, and not potentially confusing a numeric username with a user ID. I recommend using $input->get->var rather than $_GET['var'] because the $input->get version makes it so that you never have to worry about PHP's magic_quotes setting. Last thing to mention is that it might be good to include what type of fields the user_real_name and user_activation are. I believe these are supposed to be text fields, but wasn't sure (especially for user_activation) until later.

I recently had to setup front-end system to handle logins, password resets and changing passwords, so here's about how it was done. This should be functional code, but consider it pseudocode as you may need to make minor adjustments here and there. Please let me know if anything that doesn't compile and I'll correct it here. The template approach used here is the one I most often use, which is that the templates may generate output, but not echo it. Instead, they stuff any generated output into a variable ($page->body in this case). Then the main.php template is included at the end, and it handles sending the output. This 'main' template approach is preferable to separate head/foot includes when dealing with login stuff, because we can start sessions and do redirects before any output is actually sent. For a simple example of a main template, see the end of this post. 1. In Admin > Setup > Fields, create a new text field called 'tmp_pass' and add it to the 'user' template. This will enable us to keep track of a temporary, randomly generated password for the user, when they request a password reset. 2a. Create a new template file called reset-pass.php that has the following: /site/templates/reset-pass.php $showForm = true; $email = $sanitizer->email($input->post->email); if($email) { $u = $users->get("email=$email"); if($u->id) { // generate a random, temporary password $pass = ''; $chars = 'abcdefghjkmnopqrstuvwxyz23456789'; // add more as you see fit $length = mt_rand(9,12); // password between 9 and 12 characters for($n = 0; $n < $length; $n++) $pass .= $chars[mt_rand(0, strlen($chars)-1)]; $u->of(false); $u->tmp_pass = $pass; // populate a temporary pass to their profile $u->save(); $u->of(true); $message = "Your temporary password on our web site is: $pass\n"; $message .= "Please change it after you login."; mail($u->email, "Password reset", $message, "From: noreply@{$config->httpHost}"); $page->body = "<p>An email has been dispatched to you with further instructions.</p>"; $showForm = false; } else { $page->body = "<p>Sorry, account doesn't exist or doesn't have an email.</p>"; } } if($showForm) $page->body .= " <h2>Reset your password</h2> <form action='./' method='post'> <label>E-Mail <input type='email' name='email'></label> <input type='submit'> </form> "; // include the main HTML/markup template that outputs at least $page->body in an HTML document include('./main.php'); 2b. Create a page called /reset-pass/ that uses the above template. 3a. Create a login.php template. This is identical to other examples you may have seen, but with one major difference: it supports our password reset capability, where the user may login with a temporary password, when present. When successfully logging in with tmp_pass, the real password is changed to tmp_pass. Upon any successful authentication tmp_pass is cleared out for security. /site/templates/login.php if($user->isLoggedin()) $session->redirect('/profile/'); if($input->post->username && $input->post->pass) { $username = $sanitizer->username($input->post->username); $pass = $input->post->pass; $u = $users->get($username); if($u->id && $u->tmp_pass && $u->tmp_pass === $pass) { // user logging in with tmp_pass, so change it to be their real pass $u->of(false); $u->pass = $u->tmp_pass; $u->save(); $u->of(true); } $u = $session->login($username, $pass); if($u) { // user is logged in, get rid of tmp_pass $u->of(false); $u->tmp_pass = ''; $u->save(); // now redirect to the profile edit page $session->redirect('/profile/'); } } // present the login form $headline = $input->post->username ? "Login failed" : "Please login"; $page->body = " <h2>$headline</h2> <form action='./' method='post'> <p> <label>Username <input type='text' name='username'></label> <label>Password <input type='password' name='pass'></label> </p> <input type='submit'> </form> <p><a href='/reset-pass/'>Forgot your password?</a></p> "; include("./main.php"); // main markup template 3b. Create a /login/ page that uses the above template. 4a. Build a profile editing template that at least lets them change their password (but take it further if you want): /site/templates/profile.php // if user isn't logged in, then we pretend this page doesn't exist if(!$user->isLoggedin()) throw new Wire404Exception(); // check if they submitted a password change $pass = $input->post->pass; if($pass) { if(strlen($pass) < 6) { $page->body .= "<p>New password must be 6+ characters</p>"; } else if($pass !== $input->post->pass_confirm) { $page->body .= "<p>Passwords do not match</p>"; } else { $user->of(false); $user->pass = $pass; $user->save(); $user->of(true); $page->body .= "<p>Your password has been changed.</p>"; } } // display a password change form $page->body .= " <h2>Change password</h2> <form action='./' method='post'> <p> <label>New Password <input type='password' name='pass'></label><br> <label>New Password (confirm) <input type='password' name='pass_confirm'></label> </p> <input type='submit'> </form> <p><a href='/logout/'>Logout</a></p> "; include("./main.php"); 4b. Create a page called /profile/ that uses the template above. 5. Just to be complete, make a logout.php template and create a page called /logout/ that uses it. /site/templates/logout.php if($user->isLoggedin()) $session->logout(); $session->redirect('/'); 6. The above templates include main.php at the end. This should just be an HTML document that outputs your site's markup, like a separate head.inc or foot.inc would do, except that it's all in one file and called after the output is generated, and we leave the job of sending the output to main.php. An example of the simplest possible main.php would be: /site/templates/main.php <html> <head> <title><?=$page->title?></title> </head> <body> <?=$page->body?> </body> </html>