Leaderboard

I think this is an important topic and @pideluxe makes some useful suggestions. The subsequent discussion provides insights into what is attractive about PW and what people think is missing. I am a relative newcomer to PW and am only an amateur - in two senses: (a) as a retiree, I can do stuff for for friends and family without commercial pressures and (b) I have never had any training (and it shows ? ). What attracted me to PW was the ability to build custom apps integrated into a website and give others the ability to manage the content. Having used WP (aargh - customisation is a nightmare and the admin is really clunky), CodeIgniter (well-designed, but hard work!) and some simple CMS solutions, I wanted something that was easy to use and took out a lot of the hard coding work, but was flexible and capable. PW ticked all the boxes. As well as straight CMS, I have now built two quite complex apps - a club management system and a self-catering cottage management system. PW has been a great tool for the job. So the question is, why is it not more widely known and used? I think there are two issues, both of which have been mentioned by others: The project does appear to be very reliant on Ryan (albeit maybe less than previously owing to some of the excellent contributors to the ecosystem). This was not a problem for me (in fact a positive, because it has meant a clear vsion for the project), but is a negative point for some. My daughter, who is tech director of an e-marketing company, prefers WP even though it is technically inferior because of the greater assurance of continuity and the larger pool of people with relevant skills. The OP suggests some ways in which this perception could be changed, but I suspect that may not be possible without @ryan's active involvement. Over time, the user group has become more technical so that the appeal is narrowing. In some ways, this is a consequence of PW's success in enabling some pretty sophisticated sites/apps - this has attracted technophiles whose needs have further driven it in this direction. This has happened without any active decision on anyone's part. Some may feel very comfortable with this and think that it is a perfectly viable niche. I am not so sure - the risk is that the ease-of-use aspects are increasingly downplayed so that ultimately the comparison is with, say, Laravel, rather than WP. The bottom line is that PW's initial attraction of being both a 'simple' CMS and a sophisticated app-building tool risk it ending up being between a rock and a hard place. That would be a great shame because IMHO it is better, technically, than the competition. You may infer from my comments above that I think that part of the 'problem' is that the project is largely technically-driven - inevitable given the nature of those involved. This is not a critcism, just a fact of life. But perhaps the community needs to get more input from outside and think about PW's marketplace more broadly. FWIW, I agree with many of the suggestions above, including Pretty much all of @OllieMackJames's initial post. BTW, this one - is one of the few things that actually irritates me about PW, which is why I am trying to do something about it (see https://processwire.com/talk/topic/25307-oh-no-not-another-migration-module/, but I really think something like this should be in the core).

No ? _init.php is the file that you PREpend to the template rendering (just like _main.php is APpended). /site/init.php and /site/ready.php are something different and the place where you want to attach your hook.

I'm in the former category - to now, but a couple of projects have got me thinking how the second option might be useful to me as well. I've built a couple of sites (or I'd prefer to call the apps) on top of ProcessWire that have potentially a much wider market than just the clients I've built them for, however I'm just a single developer and having to manage hosting, billing, deployment, won't scale well the way I'm currently working, and although if I take the time I should be able to automate nearly everything, there's also the issue of discoverability, whereas if there were an option where people could people just click to sign up and choose an app of their choice with installation and billing all taken care of I think there could be a use case. At least, I think the modules directory needs to support commercial modules from any developer, and also at install time, I think the choice of site profiles should be able to query the modules website and offer paid or free profiles other than just those bundled with ProcessWire. Obviously ProcessWire should get a percentage of any sales, just like big app stores.

Like @bernhard mentions I think Snipcart is a great option, I also feel depending on how simple the selling part is, you could use FormBuilder + Stripe.

Looks like I have. Found a classic case of shoot-your-foot in the affected installations where I generously added some JS in a ProcessPageEdit::execute hook, my InputfieldFile change was wholly innocent. What I did find was a race condition between the first few added files, so there was one upload more active than configured in the beginning. I believe I caught that with a setTimeout. I still have to tweak that timeout, run a few more test drives and meditate over reasonable defaults, inline documentation and such, but it's taking shape.

Well, yes and no. Two migration modules already exist in ProcessWire, but neither suited my needs: “Migrations” by @LostKobrakai seems effective but quite onerous to use and has been deprecated in favour of “RockMigrations” RockMigrations by @bernhard is simpler and has a nice declarative method: migrate(). However, it is ideally suited to “headless” development, where the API is used in preference to the Admin UI. This is great for professional PW developers, but for occasional developers like me, it is much easier to use the UI rather than just the API. In addition there @adrian's ProcessMigrator which is designed for migrating page trees. Concept I wanted something to achieve the following: To allow development to take place (in a separate environment on a copy of the live database, or on a test database with the same structure) using the Admin UI. When finished, to permit a declarative approach to defining the migration and implementing it (again in the UI). To allow testing of the migration in a test environment on a copy of the live database. To allow roll-back of a migration if installation causes problems (ideally while testing rather than after implementation!). To provide a record of changes applied. Although not originally intended, the module I developed also allows the selective reversion of parts of the database by exporting migration data from a backup copy. Also, if changes are made directly on the live system (presumably simple, low-risk mods – although not best practice), it allows reverse migration to the development system in a similar fashion. I should emphasise that what I have built is more of a 'proof of concept' than a fully-fledged module. The code is pretty hacky and uses some stuff outside of the module itself. Lots of validation is missing. However, I have used it successfully in a number of small tests and a medium-sized live migration. If there is sufficient interest, I will tidy the code and make it available, but it would still need input from better coders and PW-savants than me to make it into something more widely usable. EDIT: Please note that the module has moved on a bit from this original post - the design has changed somewhat to make it more robust and flexible and additional features have been added. Please see the help file for full details. I still consider it to be at alpha stage, however, so use with care - test before making migrations and always take backups first. Design The module has the following principal components: A PW module “ProcessMigrateData”, bundled with a bootstrap migration in the same ProcessMigrateData folder, to be placed in the site/modules folder; A Page Class “MigrationPage” to be placed in the site/classes folder; Php files migrationActions.php and migrationControl.php to be placed in the site/templates/RuntimeMarkup folder (and migrationActions.js to be placed in site/templates/RuntimeMarkup/scripts). There are also a methods which need to be put in class DefaultPage and a functions in the init.php file. The module requires the FieldtypeRuntimeMarkup module. Migration definitions are held in .json files in the ProcessMigrateData/migrations/{migration name} folder (I might move this). This folder contains up to 2 sub-folders - “new” and “old” which each contain a file called a migration.json file, which defines the scope of the migration in terms of fields, templates and pages, and also one or more of fields.json, templates.json, pages.json and remove.json. The first 3 of these files contain the field, template and file definitions within the migration scope and the remove.json file simply lists fields, templates and pages to be removed. These migration files are mirrored by pages of template “Migration” under a parent /migrations/ of template “Migrations”. The mirroring happens in two ways: If a new migration is created in the module (from the Setup -> DB Migration menu), then initially no json files exist. The json files are created, after the scope of the migration is defined on the page, by running “Export Data” from the eponymous button. If json files exist, but there is no matching migration page, then the latter is created by the module on accessing the DB Migration admin page. In this case, we are in the “target” database so there is no “Export Data” button, but instead “Install” and/or “Uninstall” buttons. Migrations therefore either view the current environment as a “source” (type 1) or a “target” (type 2). Installation The module creates templates called Migration and Migrations and a page below the root named ‘migrations’. Open the admin page “Setup -> DB Migration” to create a migration. One (“bootstrap” is already installed) and cannot be modified. The pic below illustrates the DB Migrations page in the source environment. The status of a migration (as a source page) can be ‘pending’ or ‘exported’. ‘Pending’ means either that the migration data have not yet been exported or that the current export files differ from the source database. On opening this page in the target environment, the individual Migration pages (type 2) are created from the definitions in their respective /new/migration.json file. The pic below illustrates the DB Migrations page in the target environment. In a target environment, a migration status can usually be ‘indeterminate’, ‘installed’ or ‘uninstalled’. ‘Indeterminate’ means either that the migration has not yet been installed (so no ‘old’ files containing the uninstall definition exist yet) or that the current state matches neither the ‘new’ or the ‘old’ state. ‘Installed’ means that the current state matches the ‘new’ definition and ‘uninstalled’ means that it matches the ‘old’ definition (i.e. it has been actively uninstalled rather than not yet installed). When carrying out development work, you keep a note of what fields, templates and pages you have added, changed or removed. The module does not track this – it is a declarative approach, not a macro recorder. Also, it does not handle other components such as Hanna codes and Formbuilder forms. These come equipped with their own export/import functions. You can update a migration page as you go along, rather than keep a separate note of changed components. The migration page also allows you to document the migration and add any number of “snippets”. These snippets do not do anything, but can be a convenient place to store (for example) Hanna code exports for pasting into the target environment and help to make the page a comprehensive record of the migration. See example below: Note that migration pages just define the scope of the migration. It is entirely feasible for other parts of the dev database to be changed which are outside this scope and which will therefore not be migrated. After sync'ing code files to the target environment, the new migration will be listed on the setup page. On the migration page, in the target environment, there are “preview” buttons to see what changes will be implemented. The migration can then be 'installed'. See example of the migration page in ‘installation’ mode below: That's the gist of it, but inevitably there are complications. Happy to discuss and share further if there is interest in this.

From the recent discussion about the roadmap & wishlist for 2021 and some other posts by @ryan, it comes to my mind that developing and coordinating the whole project for one person is becoming harder and harder and leads nearly to the reverse of expanding the ProcessWire ecoysystem. This is not against Ryan, i think everyone here knows how engaged he is about ProcessWire, but he has only 24/7 (sometimes i think he's got far more than that...). We as the community could support the project (financially) to relieve Ryan and could take over some tasks from him. This could be, but is not limited, to: Building a Foundation/Association/Company to ensure the persistence of the project and to fund the work put in ProcessWire of Ryan (and others). Nearly every other CMSs i checked has something like this (Drupal Association, Typo3 Association, Joomla Foundation, Wordpress Foundation, Contao Association, ...). This also puts more trust in the project, if someone new will check on his engagement in ProcessWire. Assigning persons/teams to work on things: Extending the core (when necessary) Developing and maintaining major modules (e.g. page builder, admin themes, internationalization, marketing, ecommerce system, ...) Testing and inspection of modules developed by others Making translations of modules (translation of the core is mostly covered, i think) Working on PRs & issues submitted on github Working on the homepage Coordinating the community efforts I know, some resorts are already covered by others (e.g. @Pete for the forum, @horst for images, ... ), but there are many other areas where this ist not the case. By joined efforts by the ProcessWire community this hopefully will also attract new developers to the system and by a growing number of users this assists in the things above in a circular process. What do you think?

https://snipcart.com/ can be a great option - it's as simple as it can get to setup a store (at least as long as you don't need any complicated tax/inventory/coupon/shipping/etc-stuff) and it integrates greatly with processwire, because snipcart is based all upon custom markup and that's where processwire shines. A "buy" button can be as simple as that: <button class="snipcart-add-item uk-button uk-button-primary" data-item-id="<?= $page->id ?>f" data-item-price="<?= $page->price ?>" data-item-url="<?= $page->url ?>" data-item-description="<?= $page->description ?>" data-item-image="<?= $page->image->url ?>" data-item-max-quantity="3" data-item-name="<?= $page->title ?>"> <span uk-icon="cart"></span> Buy this product </button> As you can see you can even define some basic cart logic via markup (eg max item quantity, that means the user can not add more than 3 items of this product to the cart).

Bern hard u.can does $wire->addHook('/mymodule/{foo}/{bar}(/{baz})?/', function($e) { return "<pre> foo: $e->foo bar: $e->bar baz: $e->baz "; }); @ bern berna hard @ @bernhard

Funding Processwire, Here are my thoughts, I think it could be a really good cash cow for many people, but only if they focus on something so many people out there want. Mind you I am not a developer, but an end user who needs developers to build stuff for me. Two of my sites are: www.rugpijnweg.nl and www.backpaingoodbye.com both made by people here on the forum. For me, like many others, my sites have to make me money. Therefore speed is important, hence I use procache on all my sites. Building blocks are important for easy building of pages that generate the action I need. Backpaingoodbye is good with that, all repeatermatric things in there. What I love about processwire is the speed and that anything can be built. The last part is also the problem, if I want something new, it has to be built. What I think processwire needs is something like www.thrivethemes.com, which is a separate company with an offering on top of wordpress, like there are more, but I particularly like many of the things they are making. What I hate about my sites with processwire, is that if I have some changes added to a site of mine, it just is a stupid nightmare to port new stuff to other sites that use the same profile. I guess rockmigrations would be great for that, but there you go, I need a developer to run things again, and I now have 4 sites running the same profile. For that reason I am now even considering moving over to wordpress, I got me a subscription to thrivethemes, but I HATE wordpress with a vengeance... all these stupid updates all the time. Thrivethemes itself is buggy and does not make sense, it produces slow sites, but hey I can get a lot of functionality. The underlying problem with processwire and its funding is that it is IMHO too much tech oriented, brilliant minds who build incredible things, but the huge market out there is just forgotten, and wordpress gobbles it up. And then people build stuff on top of wordpress and make a very good living. So here's what I believe would work: - get a group of people together and decide on & build a basic site structure that has all the fields anyone needs, with upgrade paths in place should the structure be extended - on top of this site structure build a storehouse of repeateable blocks with a page builder like thrive themes is using, but then better, more processwire like - then have the designers go crazy on developing a number of front end variations that change the look and feel of the whole site, just by pointing the whole show to a different css file - have some developers working on creating more building blocks focused on different niches, par example the coaching business would require agenda booking, same for hairdresser salons. - this way it would be possible to offer niche specific sites, including hosting I have ideas how this could work, and would like to hear if people are interested to develop these ideas further Let me know

Thank you, Robin S! That was exactly what I was looking for ?

Sorry, I haven't been able to reproduce the 0 issue and I have a module with a custom namespace and anonymous hooks. Perhaps it's because my dev setup is PHP8? Anyway, if you're willing to take a look, that would be great. You can see the code I have been working on here: https://github.com/adrianbj/TracyDebugger/commit/a600310a62aed42c16d1079ffa11728e02336c60#diff-470f7296769058027980e4975f92bc567bb7cb7ae07bb1d238136759b913001d It's all about PHP's reflection features. You just need to handle whether things are a closure, function, object etc. As I mentioned above, I was relying on the PW core's debug code which also does a lot of this, but I needed to recreate some of it to get the file and line number for closures. Let me know if you have any questions and I'll try to help.

You can use the hasRole method to test whether the current user is "admin" to determine if a field should be required.

@bernhard - please try the latest committed version. I have removed the namespace when it's ProcessWire but it shows for all others, so hopefully that reduces the clutter without losing the useful information. Hopefully the undefined $rc is now fixed. Regarding the order, it's by priority and the name. This is how the PW core debug info handles it so I assume that means it's not possible to show in the order they are triggered, but maybe a question for Ryan. Anything else I've missed?

That's a good point. Version 0.3.0 reverts field settings during uninstall. Seems that altering data is not necessary: even if the field contains multiple values (in database), only one is returned with the new settings. I'm not 100% certain that this won't cause any unexpected side effects, but for the time being it seems to work fine... ?

I hadn't developed a website for a while, but here we are. It's a very simple minimalist website to showcase the latest work of Dominican Artist Patricia Abreu Mota. Site: https://patriabreu.com Modules: Procache ❤️ Seo Maestro Profiler Pro Lister Pro ProcessRedirects

Hi, you may try to copy the complete wire/modules InputfieldFile folder with all files into site/modules InputfieldFile. Then PW should ask you in the admin that there are two modules and which one you want to use. But please better first try this in a backup copy. I used this sometimes in the past, but not with newer PW versions.

I'm not sure he will. Generally, a new feature needs to be used by an estimated 30% of users to be accepted into the core. There are, however, exceptions to the rule - especially where hosting issues are concerned. I'm not happy with my adaptions yet, though, since they work on some installations here but not on others. I'm still on the lookout for the issue there. However, once I work out the kinks, and if the change doesn't have to get more complicated, I think it could have a good chance to be accepted (adding a feature request at processwire-requests and finding others who vote for it would certainly help).

I've reworked this slightly, based on the helpful suggestion of @Kiwi Chris. The individual migration items are now entered in a repeater field and so the sequence can take into account any dependencies. Each item can be either 'new', 'changed' or 'removed'. When a migration is uninstalled, the sequence is automatically reversed and 'new' items are changed to 'removed' and vice versa. Example below shows a migration testing a page reference dependency (it works!). This is the appearance in the source database (pre-export): If you click 'Preview' you see what changes are proposed to export (see below). This feature also operates to review (in the target database) what changes will happen on install or uninstall - or, if the install has failed, what changes remain (either by modifying the migration or applying a manual fix if all else fails). Export is shown as 'no object' in the above, because the migration has not yet been exported. I think this all seems to work as designed, but am grateful for any futher thoughts on the design. I will now work on tidying the code a bit and doing a bit of documentation. There may still be a few bugs. There are some at the moment that I can't pin down but they are cosmetic rather than fundamental - I think I may need some help from those who understand the inner workings of PW better ( @adrian ?). Promises of help will encourage me to get on and release some code ? Meanwhile, I am happy to answer any further questions.

Are these website all on the same server ? Or on shared hosting ? Or do you also have the issue locally ? I have this issue with one of my websites where sometimes the TTBF drops down. Can't say for sure as I did not investigate much yet but I assume it's because there might be other websites on the shared hosting taking too much power. Sorry I'm not helping much so here's a screen of the timings I had for your website, looks pretty normal to me :

What we need is really easy ways to contribute and build motivation towards contributions. - slack/discord for real-time Comms - merging PRs in the Processwire repo instead of the weird closing the PR and copy pasting it in. I raised a PR years ago, got no feedback and was told it may have fine in via copy and paste. I closed the PR myself to reduce noise and haven't entertained the idea of contributing since. Unless this has changed, start treating it like a modern open source project - roadmap on the GitHub board - indentified maintainers on the GitHub repo - a backlog / causal kanban style agile setup - monthly maintainer video calls to go over backlog etc. Maybe anyone can join. Maybe video recorded. - a patron or way to donate to the PW project. This pot can be used to pay maintainers to work on critical features etc. E.g. through donations with have enough money to fund 1 week of work, what should Ryan / another maintainer take time off their normal work to work on. - key goals established for the core maintainer team. We should as a whole be marching the same direction. (Though obviously people can work on what they want, but has to pass review) - a plan that @ryan is comfortable with to slowly distribute the reigns. We don't want to move too fast and over burden the core. - some sort of backlog voting system, instead of posts on the forum. - Id really like to modernise the process around Processwire. That scares anybody larger than a sole freelancer away from the project. Bigger users mean more support. More pro modules being sold etc. - on that note. Can we have the shop not just be Ryan's modules but extended to other pais for modules. I don't like that they are strewn across the web. (And Ryan charge a fee.)

I just had to do a site-wide replacement on a word this morning, so this may be of use to others in a similar situation (in my case a product name had to have a capital letter in the middle instead of lowercase). Stick at the top of your homepage template and be careful with this - always take a database backup before playing with anything that's potentially destructive. function searchReplace($page) { foreach ($page->children('include=all') as $child) { // Skip admin page if ($child->id != 2) { foreach ($child->template->fields as $field) { $child->{$field} = str_replace('search_word', 'replacement_word', $child->{$field}); } foreach ($child->children as $grandchild) { searchReplace($grandchild); } $child->setOutputFormatting(false); $child->save(); } } } searchReplace($pages->get('/'); exit; It essentially iterates every page under the homepage, goes through every field and replaces the search term with the replacement. It is case sensitive too. Comment out the code when you are done and see the changes live on your site. This might be a nice one for a quick module that only targets things like text, textarea and image/file descriptions as that's pretty much the only fieldtypes that are relevant I think. Settings could be added to skip certain pages (and therefore their children) entirely, but I don't have time for building a module at the moment.

Just edit the url of the "Admin" page in the pagetree.

Hi Vin, I'm guessing you'll want to handle this in the front-end using the API. There are quite a few posts out there with this same scenario. In a nutshell you'll want to receive your form data and sanitize it, then create a new page and a new user with this data. <?php // was form submitted if ($input->post->my_submit_button) { // check for errors with form // if no errors, add a page and a user // first add the page $p = new Page(); $p->of(false); // sets output formatting to false in order to change field values. $p->parent = $pages->get("/members"); $p->template = "member"; $p->title = $sanitizer->text($input->post->name); // sanitized your value from form and sets to title $p->other_field = $sanitizer->text($input->post->other_field); $p->save(); // save the new page // now add the user $u = new User(); $u->of(false); $u->name = $sanitizer->username($input->post->username); $u->email = $sanitizer->email($input->post->email); $u->pass = $sanitizer->text($input->post->pass); $u->save(); $u->of(true); } ?> <form action="./" method="post"> <!-- form stuff here --> </form>