Leaderboard

Code is now posted at https://github.com/MetaTunes/ProcessDbMigrate Many thanks once more to those who gave me ideas and help in doing my first 'proper' module - in particular @Kiwi Chris, @bernhard and @adrian. Please test and feedback. But be gentle in your criticism of the code ?. Most importantly - this is a proof of concept only at this stage and it makes changes to your files and databases so please do not use on production sites and do back up everything beforehand - use at your own risk! To install: Place the ProcessDbMigrate folder in your site/modules directory. Make sure your environment meets the requirements - you need @Robin S's FieldtypeRuntimeOnly to be installed first. The earliest PW version I have tested it with is 3.0.148, but it might work on earlier 3.0.xxx versions. Please let me know if it works with earlier versions. Having satisfied the dependencies, install the module. You will see that there is an extensive help.md file - please read it, particularly if you get stuck. @bernhard asked for a screencast - I will do that next - hopefully it will make things clearer.

Try renderPager() instead of renderPages(). And remove start=0, this prevents MarkupPageNav from increasing the offset. Only use it when you explicitly don't want to paginate your results. A number of times. I've put together a small example that works with the skyscraper demo since my original content is too specific. You can download the profile for that site here on GitHub and copy it into a (uninstalled) PW installation, then install PW with the skyscraper site profile (make sure to read up on the FieldtypeMapMarker issue in the README on GitHub). After installation, drop the template file from the attached zip into the templates folder, log into the backend and create a new template "paginated" for the file. In the template's URLs settings, enable page numbers and url segments. Then create a new page under home with the new template, give it a title and publish it. Voila, you should be ready to go. When you visit your new page, it should look like this: The pagination links should load the content through ajax. paginated.zip

I've done this exact same path and it works really well with the bare minimum, check that doc page @szabesz sent. Stripe Checkout simplifies things a lot. FormBuilder seems to do this "plug and play" but I have honestly not tried it. The implementation of the checkout process is really minimal to get to the Checkout page if you want to remove FormBuilder from the equation, it ends up as very little code.

I recommend Stripe over PayPal. The simplest way to implement it is by using Stripe Checkout: https://stripe.com/en-hu/payments/checkout Once I have done that for a "one product only" site. This is the process in short: If visitor enters valid email address and provides quantity between 1 and 4 then he is allowed to proceed. ProcessWire sends an email to the site owner in the background with the email address provided and the amount in it, so that the site owner knows that someone initiated the process. Stripe Checkout comes up, customized with custom logo and a product image. Customer can either cancel the process or pay (also provides shipping info). If payment is successful, then customer gets confirmation message from ProcessWire and the bill from Stripe. That's all there is to it. The site owner can manage all the orders via the Stripe admin, nothing is stored in the ProcessWire database, not even the email address.

You can certainly use a cart but for three options you could also use a paypal "buy now" button.

Omg. The issue is caused at php version 8.0.2. Processwire running perfekt to php 7.4. I'm looking for entries in protocolls: nothing. No php error or warnings for this issue. That's mean. @wbmnfktr @BitPoet I thank both of you. Closed

My wife loves to cook, and I always like to further my knowledge around Processwire. So I thought I'll build a small page with the some small function to learn something. Used modules: ProMailer RepeaterMatrix Pages2PDF AIOM and some other litte modules Current functions: JSON-LD for recipes and page search Automatic ingredient calculation when changing the number of servings Creation of a PDF of the recipe Basic PWA (here is something to do, actually) Planned functions: a lot ? Site: https://www.dothiscookingthing.de

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.

@Robin S - Ryan's update to the HannaCode module yesterday has broken this. Looks like it's probably just because he namespaced it, so should be an easy fix. PS - @teppo - I wonder if your HannaCodeHelper module might suffer the same fate?

When you iterate over $single->zasvojenosti_select, you only get those page references that are select. You need to iterate over the possible choices like you do in the header instead. <?php foreach($pages->get(1067)->children() as $child) { if($single->zasvojenosti_select->has($child)): ?> <td>Yes</td> <?php else:?> <td>no</td> <?php endif;?> <?php } ?>

Really appreciate that you took the time to check this out, and sorry for the slow response. Yes, it was on shared hosting, but with a lot of the shared server resources dedicated to my sites. Well, the problem was resolved by my webhosts (Gandi), and things are running quick again. The full page loads in under 500ms now, which is more in line with what I would expect.

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).

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

This sounds very exciting! I know someone who has already put thousands of hours into modules and techniques that could serve such a scenario very well... ?

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

I'd be happy to be wrong with my opinion here ? I've put a lot of effort in setting up my infrastructure and it looks like finally I've found a good combination of all the puzzle pieces playing well together (Hosting+Server administration, GIT for version control, RockMigrations for Migrations, RockShell for all the maintanance and installation stuff to spin up a new pw instance, create db dumps and restores etc.). I just have the feeling that 90% are happy with the usual workflow: develop locally or directly on the server (I've done that myself for years) and then simply copy files over. That's something that any regular hosting provider supports... and my feeling is 80% of the remaining 10% are happy managing it on their own. If I'm wrong and anybody is looking for processwire hosting in DACH write me a PM ?

I have to disagree with this, to an extent. If I did client projects of my own I'd very much appreciate the option of off-loading the hosting and day-to-day maintenance of said sites to someone else. Sure, most of the time a "general purpose" hosting plan is good enough and ProcessWire is great in that it has very rarely really "required" updates, but I could imagine a plan dedicated to ProcessWire providing some extra services that a general purpose one won't and can't ? At the same time I don't really see why this wouldn't work for business clients as well. We host the sites we build in-house, and I can say that a lot of time and effort has gone to tweaking that setup, and maintaining the platform and the sites on it is an ongoing process. If hosting wasn't an important part of what we do, or we weren't quite as familiar with the inner workings of ProcessWire, it would make plenty of sense to subcontract that service from someone who actually specializes in it. Many companies that work on other platforms, such as WordPress, choose external hosting — not because they can't do the hosting, but rather because it's not their core business. There are also numerous "developer oriented" hosting platforms out there.

The only funding possibility for Processwire now is (as i know) by selling pro modules. For selling more modules, Processwire have to be used on more projects. So it have to be more populer. In my country Turkey Processwire is not known at all. (Turkey has over 80 million people) Everone could put different effort in this undertaking. So my role is such an organisation could be to promote the use of Proceswire in Turkey. I would love to do this. I own a MsExcel Forum with nearly 300.000 members and this forum could be a good starting source for building a Processwire community in Turkey. --------------------- Edit : You would ask "why a separate community?" In Turkey the knowledge of foreign languages are is very low. So people are asking for Turkish documentation, examples or explanation. Therefore a local community would have larger members count.

I'm not sure who would really pay for such a service. Most of PW users are tech-savvy, so I guess they WANT to have the control over their infrastructure (or choose any of the cheap hosting providers out there...). Installing PW is no problem for them. On the other hand people that dont want to handle any technical aspects (like hosting or installing PW) are likely more happy with one of the plug&play CMSs?!

You and me both. From the outside it seemed like a very nice idea and the numbers initially posted seemed to indicate a decent level of interest. Hard to say — could be any number of reasons: technical issues, problems with the business model, or simply the classic "moved on to other projects". The service was quietly taken down, and the Twitter account or support board were never updated to even mention this ?‍♂️

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.

@cstevensjr, this started on Wednesday of this week when Dreamhost made some bizarre unilateral ModSecurity setting that broke every ProcessWire site's ability to upload images or files. You have to open a support ticket and tell them to change the ModSec setting for every domain on your account to allow the CMS to work. They should be able to check their logs and know what to change, but you also might have to go back and forth with them and test it. I exchanged probably 10 emails with them on Wednesday while they repeatedly tweaked the ruleset until i was able to upload again. Last night i had to send them a list of ~20 sites that they had to adjust the ruleset for and they replied today that it is now done, but only time will tell if I start to receive complaints from site owners that they can't upload. This is certainly disappointing behavior from Dreamhost, and they should make amends. Hopefully they are going to learn a hard lesson once they get an avalanche of support complaints about this. By the way, you can easily tell what the problem is, if you upload while viewing the network panel. You'll see probably a 418 error and when you view the response you'll see Internal Server Error. 418 is the DH response for anything related to ModSec. In addition you can go into the server logs and open the log file (which may be pretty huge by now) and see the mod sec errors.

@ryan Thank you for the continued effort you put into PW and the quick solution to LMD’s problem, which bit me too for a second ?! I just noticed there still seems to be an issue with the join/field selector. If used with pagination it appears to add the limit/pagesize to the total number of results, which distorts pagination. One too many pages are shown, the last of them being empty. For example, I have this selector: template=show, datum>=2019-01-01, datum<2020-01-01, has_parent=1234, sort=-datum, limit=50 With the join fields getTotal() gives me 102, without only 52 (one show per week, makes sense). Interestingly, on the second pagination page, getTotal() will say 54 (?!) and the superfluous 3rd page disappears.

Additionally, you don't need a PayPal account - you can pay with your CC without signing up. I am not defending PayPal - I actually think it's a pretty ugly system to use, but it does mostly get the job done however you need. You'll always have more flexibility with other services though. In Canada, Moneris is a reasonable option - not modern like Stripe etc, but it can be completely hidden from the user - ie everything happens on your site with no redirect.