Leaderboard

This site launched earlier this year (2021) and was the product of about 9 months work between myself and the site owners. It was a ground-up build replacing a Wordpress site. Trinnov are based in France and design and manufacturer perhaps the finest cinema processors and room correction hardware in the world. The project features multi-language, product library, a dealer & distributor locator integrated pulling data from the company's BMS, a full featured blog, a site-wide file library for manuals etc. plus a host of other features and customisations including a contact form that emails to different destinations depending on a combination of product application and enquiry type. I hope you like it! https://www.trinnov.com/

I don’t know if anyone here would find this handy but interesting nonetheless: https://css-tricks.com/wrangling-control-over-pdfs-with-the-adobe-pdf-embed-api/

I had a go at something like this a few years ago, exactly after I played a bit with the Perch trial. It didn't gain much traction and I never got to develop the concept further, but what I had was working flawlessly.

This module facilitates quick batch creation (titles only or CSV import for other fields), editing, sorting, deletion, and CSV export of all children under a given page. You can even provide an alternate parent page which allows for editing of an external page tree. http://modules.processwire.com/modules/batch-child-editor/ https://github.com/adrianbj/BatchChildEditor The interface can be added to the Children Tab, or in a new dedicated tab, or placed inline with other fields in the Content tab. Various modes allow you to: Lister - Embeds a customized Lister interface. Installation of ListerPro will allow inline ajax editing of displayed fields. Edit - This allows you to rename existing child pages and add new child pages. It is non-destructive and so could be used on child pages that have their own children or other content fields (not just title). It includes the ability to quickly sort and delete pages and change page templates. Also allows full editing of each page via a modal dialog by clicking on the page name link. This is my preferred default setup - see how it replaces the default Children/Subpages with an easily addable/editable/sortable/renamable/deletable list. Note that the edit links open each child page in a modal for quick editing of all fields. Add - adds newly entered page titles as child pages to the list of existing siblings. You could create a list of pages in Word or whatever and just paste them in here and viola! This screenshot shows the editor in its own tab (name is configurable) and shows some of the CSV creation options. Update and Replace modes look fairly similar but show existing page titles. Update - Updates the titles (and any other fields if you enter CSV data) for the existing pages and adds any additionally entered pages. Replace - Works similarly to Add, but replaces all the existing children. There are checks that prevent this method working if there are any child pages with their own children or other content fields that are not empty. This check can be disabled in the module config settings, but please be very careful with this. Export to CSV - Generates a CSV file containing the fields for all child pages. Fields to be exported can to fixed or customizable by the user. Also includes an API export method. Populating fields on new pages In Add, Update, and Replace modes you can enter CSV formatted rows to populate all text/numeric fields, making for an extremely quick way of creating new pages and populating their content fields. Predefined Field Pairings Like the field connections setup from Ryan's CSV Importer, but defined ahead of time so the dev controls what columns from the CSV pair with which PW fields. This is especially powerful in Update mode giving editors the ability to periodically import a CSV file to update only certain fields on a entire set of child pages. These pairings also allow for importing fieldtypes with subfields - verified to work for Profields Textareas and MapMarker fields, but I think should work for most others as well - let me know if you find any that don't work. Access permission This module requires a new permission: "batch-child-editor". This permission is created automatically on install and is added to the superuser role, but it is up to the developer to add the permission to other roles as required. Config Settings This module is HIGHLY configurable down to setting up custom descriptions and notes for your editors. You define one config globally for the site and then optionally you can define completely custom configurations for each page tree parent on your site. There are too many settings to bother showing here - you really just need to look through all the options and play around with them!

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.

I wanted to view the contents of a JSON post in a web hook from an external application. In this instance the source application was Stripe posting event info at irregular intervals to a PW page URL. The process had to be unobtrusive. Solution was to send an email to myself. The web hook page template contained: // create a PW mail object using whatever method works for you $mail = wire()->modules('WireMailSmtp'); // Retrieve the request's body and parse it as JSON $stripe_input = @file_get_contents("php://input"); $event_json = json_decode($stripe_input); try { $body = "<pre>" . var_export($event_json, true) . "</pre>"; $mail->to('my@emailaddress.com'); $mail->from('from@emailaddress.com'); $mail->subject('test event_json'); $mail->bodyHTML($body); $mail->send(); } catch (\Exception $e) { $error = "Email not sent: " . $e->getMessage(); $mail->log($error); } Resulting email body contains nicely formatted code, eg: stdClass::__set_state(array( 'id' => 'evt_XXXXXXXXXXXXXXXX', 'object' => 'event', 'api_version' => '2016-07-06', 'created' => 1476900798, 'data' => stdClass::__set_state(array( 'object' => stdClass::__set_state(array( 'id' => 'sub_XXXXXXXXXXXXXXXX', 'object' => 'subscription', 'application_fee_percent' => NULL, 'cancel_at_period_end' => false, 'canceled_at' => NULL, 'created' => 1476900796, 'current_period_end' => 1508436796, 'current_period_start' => 1476900796, 'customer' => 'cus_XXXXXXXXXXXXXXXX', 'discount' => NULL, 'ended_at' => NULL, 'livemode' => true, 'metadata' => stdClass::__set_state(array( )), 'plan' => stdClass::__set_state(array( 'id' => 'annual', 'object' => 'plan', 'amount' => 8000, 'created' => 1474521586, 'currency' => 'usd', 'interval' => 'year', 'interval_count' => 1, 'livemode' => true, 'metadata' => stdClass::__set_state(array( )), 'name' => 'Annual', 'statement_descriptor' => NULL, 'trial_period_days' => NULL, )), 'quantity' => 1, 'start' => 1476900796, 'status' => 'active', 'tax_percent' => NULL, 'trial_end' => NULL, 'trial_start' => NULL, )), )), 'livemode' => true, 'pending_webhooks' => 1, 'request' => 'req_XXXXXXXXXXXXXXXX', 'type' => 'customer.subscription.created', ))

You found the solution just 4 years after posting this thread?! Wow. That's fast ?

awesome thank you!

Hi @benbyf If you right click on the image in the CKEditor field and select "Image Properties" then click on the quote marks icon you can edit Img Alt there.

Thanks

Yeah, that's exactly what's happening. In Router.php: public static function handleError($errNo, $errStr, $errFile, $errLine) { if (error_reporting()) { $return = new \StdClass(); $return->error = 'Internal Server Error'; $return->devmessage = [ 'message' => $errStr, 'location' => $errFile, 'line' => $errLine ]; self::displayOrLogError($return, 500); } } So if any error logging is enabled this will be fired, regardless of whether we actually care about that type of error. I've made some modifications, so I'll do a PR and you can see what you think @Sebi

Ok, so according to your previous post variable $pizza->ingredient is page array so you must use foreach also for ingredients.

If you are getting ID of ingredient possible workaround could be this: $ingredient = $pages->get($pizza->ingredient); Then use $ingredient as page, eg. $ingredient->title... Maybe check settings of your field in Pw if nothing is out of ordinary.

I've done this for a couple clients. @mr-fan suggestion is the one I use to. One installation I've done works like this: Download Library Page (hidden, template = "downloads") - File 1 (template = "download", contains a file upload field called 'pdf_file' 'and sometimes other fields such as 'title' etc.) - File 2 (template = "download", as File 1) - File 3 etc. Then, create a "file_download" field on pages that need the files. This is a Page Reference field with parent page set to the Download Library page and the selector template="download". I use a Page Select Multiple type for this. In the page template you can then do this to get the files foreach ($page->file_download as $fd) { echo "<a href='{$fd->url}'>{$fd->title}</a> } Hope that helps.

One thing I'd try is using Pages > Find to make the same selection, and then simplified version, and see if you get any results. If you have debug set to true in config.php, you can see the selector being used towards the bottom of the page. Another thing would be to try displaying the results of the find using the selector – and variations of it – on a page using print_r(). Or if you have Tracy Debugger installed (highly recommended!), return the result using bd(). BTW, it might be more efficient and a little easier to debug if you find and loop through the pages something like this: $batches = $pages->find("template=batch, batchdatestart<=today, batchdateend>=today"); foreach ($batches as $batch) ...

welcome to processwire - structure your site is essential for the fun of setup a site best blogpost ever is this one: This one made my first steps a lot faster thanks to @kongondofor this very very helpfull post for beginners...;) kind regards mr-fan

When working with ProcessWire always think "pages first", there are loads of creative ways to utilize them, they form the bases of the ecosystem. @Robin S and @adrian and others have lots of useful free modules to make it even easier to work with them. Just a few examples, randomly selected: https://processwire.com/talk/topic/25340-dynamic-options/ https://processwire.com/modules/process-page-field-select-creator/ https://processwire.com/modules/admin-page-field-edit-links/ https://processwire.com/talk/topic/24136-lister-selector https://github.com/ryancramerdesign/FieldtypeTextUnique https://processwire.com/modules/fieldtype-events/ https://github.com/kixe/FieldtypeSelectExtOption https://processwire.com/modules/process-admin-actions/ https://github.com/Toutouwai/AdminActionsUnorderedListToPages and more to discover: https://processwire.com/modules/ BTW, welcome to ProcessWire ?

They are, you need to configure that inside the repeater field, on the Details tab where you add the actual fields for the repeater, click on the field's label/name and it will popup a configuration screen that will be set the configuration in the context of the repeater field. (in case you use the fields in other places, for example)

The UserActivity Pro module in ProDevTools was upgraded this week so that it now uses the Javascript Beacon API, enabling quick and reliable identification of when a user has finished a particular activity. It also now keeps track of when an activity is visible to the user or the window is hidden (like minimized or in a different tab), and it is able to report how many unsaved changes a user has made. All of this is visible from the Access > Activity menu in the admin. On the core side, there have been minor updates, so no version bump this week. But there are still a couple new PRs and useful things to look at in the commit log. The plan for next week: Bernhard Baumrock has been working on a PR that makes it very simple to modify and recompile the CSS of our AdminThemeUikit module... like as simple as placing an admin.less file in /site/templates/ directory. I'll save the details for next week, but after using it a bit here I have to say it's very cool. It also makes it really simple to upgrade the Uikit version. Previously I'd been following the build process as outlined in the Uikit instructions and often found myself in a state of confusion with npm errors and strange dependencies, needing upgrades for unidentifiable tools and producing incoherent warnings that never went away and left me with little confidence in the process. Perhaps it was because I started all this back when Uikit 3 was still beta, but the result was that I didn't much like upgrading Uikit or recompiling our AdminThemeUikit CSS, and I don't think anyone else did either. It made it a little difficult for our AdminThemeUikit module to achieve its original mission of being a simple module that many would extend and build from. Well, Bernhard has found a way to skip over all that nonsense and made it much simpler for all of us, so that AdminThemeUikit can finally be what it set out to be. I look forward to integrating this PR hopefully this coming week and think it means a lot of good things for our admin. Also, huge thanks to Pete for upgrading our forums this week! It's a great upgrade.

You could take all files at one hidden place like parent ->pdf-files child ->a.pdf child ->b.pdf and on every page you want you can link via dialog to the files or make a file-inputfield with selector to the setup parent page with all childpages as choice. I used at one project a pagetable field to have all files on one place - and can link to them from any other page. there is a commercial module, too and a free one with less functions but much to learn from https://processwire.com/modules/media-library/ kind regards mr-fan

Amazing, thank you! Zuse wasn't on the list and is now

You can create/modify the fields/templates/pages however you like in the development environment. Then create the migration page by just defining what has been added/changed/deleted. Sure, but why bother (see the above)? Minor tweaks by hand are OK if the json file isn't quite what you want, but better to let the code generate it. My module does not track changes - that can get very messy. You just define the scope of changes (in the right dependency order) and it picks up the current state - not how it got there. Perhaps this might work better than the real-time hooking. A suitable compromise that might be workable is a separate component that just logs what has changed since last time (without knowing how). That could then build a draft migration page, but the sequence may need to be hand-sorted as getting the system to work out the dependencies could be tricky. In theory, you could use json files to snapshot the whole database and then take diffs from that to create the migration page, but that could be pretty resource-intensive - at the very least you would want to restrict the page tree to exclude user pages which are not maintained in the dev. It definitely has that advantage, provided you took a snapshot before you started work on the changes. On the other hand (a) it is a good idea to document what you are doing ? and (b) if you are working on 2 or more sets of (disjoint) changes, your approach would bundle them as one. So while it may be a good idea (and maybe achievable as per the above comments), you would definitely want it to be optional - e.g. have a button "Create migration page from snapshot". I couldn't agree more, and would appreciate @ryan's take on this. It is the only thing about PW that irritates me. I'm not sure he would agree - the whole import/export stuff seemed to have been left unfinished years ago - for example this. And by all means look at my code, but you might wish to wear gloves ?

Ryan's comment in the fixed GitHub issue: Therefore, to include unpublished pages you must get the unformatted value of the field: $items = $page->getUnformatted('your_page_reference_field_name');

https://www.baumrock.com/portfolio/individuelles-crm-und-controlling-tool/ I'm happy to share my biggest and most interesting ProcessWire project so far with you It's a 100% custom office-management solution that helps my client to keep track of all their contacts, projects and finance/controlling stuff. Conception was done back in 2016 and the software is productive since begin of this year. My client is very happy with the result and so am I. Some technical insights: Everything is done inside the PW Admin. I'm using the Reno Theme with some custom colors. In the beginning I was not sure if I should stay with the pw admin or build my own admin-framework but now I'm VERY happy that I went with PW Almost all of my custom Process Pages use my RockDatatables module - there are still some limitations but without it, this project would not have been possible For the charts I used Google Charts and chartjs - both play well together with the datatables and make it possible to display filtered data instantly: also my handsontable module was created for this project to have a nice and quick option for matrix data inputs: Lister and ListerPro were no options as i needed much more flexibility regarding data presentation (like colorization, filtering and building sums of selected rows): invoices are highly customisable as well and easy to create. PDFs are created by php and mPDF by the way: all data is dummy data populated via my Module RockDummyData have a nice weekend everybody