Leaderboard

Admin Restrict Branch Select is an add-on / companion module for Admin Restrict Branch. With this module enabled, you can manually select more than one branch parent per user via the branch_parent field, and users with more than one option selected will be able to switch between those while editing site content. Switching between branches is done via a select field injected at the top of the page tree. Note that users are still limited to one branch at a time: this module will not make it possible to view multiple branches at the same time. When the module is installed, it will automatically update the branch_parent field if deemed necessary, i.e. if it isn't yet configured to allow selecting multiple pages. You can make changes to the field later, if you want to restrict selectable options by template, use asmSelect instead of PageListSelectMultiple, etc. This is an early beta release, so be sure to test carefully before enabling this module in production! https://processwire.com/modules/admin-restrict-branch-select/ https://github.com/teppokoivula/AdminRestrictBranchSelect

This module is exactly what I need on a current project. And did need on a number in the past, but had to cope without. Thanks, Teppo!

Just did a quick test and it looks great - thanks for sharing this - I think it will be a great solution for many folks.

As a novice user i had my problems understanding how multiple file/image upload works and how to delete only one selected uploaded image and not to delete all. It is very difficult for a novice user to understand the complicated examples and answers of the very experienced members. So i decided to make a very simple example for explaining the multiple file/image upload and selected delete. I am not an expert on Processwire, wanted only to share what i achieved so far. So there may be better ways to do the same. (Take this as an axample form a novice for other novices) WARNING : As this is only a very simple example; there are no validations and security checks in this example. So please dont use this on a real project without security checks etc. The attached fileexample.php is complete working example. (I made some last minute comment additions, hope i did not destroyed anything. If you have problems using the example file please inform me, i will check and correct) With this example you will be able to; - upload multiple images - delete only selected images you uploaded before. Especially for the second part (deleting only one image from a multiple image field) it is very hard to find examples and answers in the forum HOW TO USE THE EXAMPLE FİLE: 1- Create a TEMP directory for for fileupload below site/assets/ 2- Download the attached "fileexample.php file and edit line 24, write the path of the created fileupload temp directory. 3- Upload the "fileexample.php file to site/templates/ folder 4- Create an new field named "images" with type of images. 5- Add a new template. Choose "fileexample" from the recommended list. 6- Edit the "fileexample" template and add the created "images" field from step 4 to it. 7- Create a new Page and select "fileexample" as the template of this page. Now visit the newly created page and you will see 5 image input fields. It is possible to use only one inputfield, but it is more visual the way i choose in the example. The flow of the example is like this; When you visit the page the form is created. If there are already uploaded images the thumbnails are shown and a "Delete" button next to it. If there is no image than a image input is shown. As we used "$imageamount = '5';" if there are 2 images already uploaded you will see 2 thumbnail iamges with delete buttons netx to them and 3 image inputfields. If you choose some images on the image input fileds and hit the "Save" button than the code part starting with "if ($input->post->fileprocess){" is triggered. This part makes the file upload process. If you click the Delete button next to one thumbnail the script "deleteimage" is trigered. This script makes a ajax Post call the same page with the post variable "imagedelete". This ajax call sets "imagedelete" variable and so the code satrting with line "if ($input->post->imagedelete) {" Will be trigered. Here the most important part is the exit in the last line. As this is a Ajax call the call have to be terminated before anything is outputted. ----------------------------- Hope all is clear understandable. My English not so good, sorry. If you do not understand any part please ask and will do my best to explain it again. fileexample.php

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.

A module for managing files and folders. Supports creating, opening (e.g. viewing, playing, editing), renaming, moving, copying, deleting and searching for files. You can also view and change (not supported on Windows) file and directory permissions. https://github.com/matjazpotocnik/ProcessFileManager The author of FileManager component is (c) 2006 - 2018 Gerd Tentler, http://www.gerd-tentler.de/tools/filemanager/. I modified it to work with ProcessWire as a module. Please see license files on usage in commercial projects!

Hey @adrian! Just a heads-up that I posted an updated and extended version of my code as a new add-on module: The functionality seemed pretty specific to one use case so I figured it was best not to bundle it in the main module, but feel free to use anything from my module if it makes sense to you. Turns out that the original implementation missed a few key points and was very specific to a particular site, so this is basically a full rewrite... ?

According to this post: https://groups.google.com/g/unpoly/c/BUIGByZE3FE/m/7igAzadjBQAJ this is the todo file to keep an eye on: https://github.com/unpoly/unpoly/blob/hk/layers/design/todo_layers.txt In which the "Remaining feature work" section keeps shrinking day by day, so I hope I can soon start to fiddle v2. The todo list does not tell too much about the state of readiness of the docs but I hope even exploring the new version will be fun ?

I hope everyone is having a good week! Commits to the core this week include 10 issue report resolutions (so far). This will likely continue next week as well, and then I'll bump the version up then. Also included this week is an CKEditor upgrade from 4.14.0 to version 4.16.0. While that may sound like a minor CKEditor version bump, there's actually quite a list of updates in the CKEditor 4.x changelog, including a few security-related fixes, though none that I think are likely to affect PW users. I do still have a couple of core feature requests in progress as well, but there's more work still to do on those. Nothing too exciting this week, but I like to check in and say hello either way. I hope you all have a great weekend!

Can you paste the code from your template, related to the output of this textarea field, as well, @modifiedcontent?