Leaderboard

This module is deprecated in favor of RockMigrations. It'll continue to work and I might fix some smaller incompatibilities if they're reported, but no major development will happen on this anymore. There where various threads about a how to reasonably handle multiple dev/staging and live environments with ProcessWire and at best handle it as automatically as possible. A git based workflow makes it easy to handle files, but the pain point of migrating db changes has even lead to multiple requests of not handling template/field storage in the db at all. I've gone ahead and used for my own projects the concept of database migrations, which most frameworks are using to handle database changes – but the ProcessWire flavored way. ___ ___ ___ ___ ___ ___ ___ /\__\ /\ \ /\ \ /\ \ /\ \ /\ \ /\ \ /::L_L_ _\:\ \ /::\ \ /::\ \ /::\ \ \:\ \ /::\ \ /:/L:\__\ /\/::\__\ /:/\:\__\ /::\:\__\ /::\:\__\ /::\__\ /::\:\__\ \/_/:/ / \::/\/__/ \:\:\/__/ \;:::/ / \/\::/ / /:/\/__/ \:\:\/ / /:/ / \:\__\ \::/ / |:\/__/ /:/ / \/__/ \:\/ / \/__/ \/__/ \/__/ \|__| \/__/ \/__/ Beta This module does help you managing migration files, where any database changes can be stored in php files using just the simple ProcessWire api at your disposal. It's not as nice as using the admin UI, but certainly better than trying to migrate changes manually and possibly weeks after adding the changes. Also there's always the option to create helper modules, which can export changes made in the admin UI to something usable in those migration files. For example I'm using an internal process module, which does let me export changes to template access rules as json strings, which I then use in my migrations to actually apply the changes. Now on to the meat – How to use the module: Read the following guide on creating own migrations Maybe use the CLI tool to speed up your workflow (and possibly automate stuff) It is generally recommended, but not enforced, that migrations are run/rolled back in order. When doing migrations or rollbacks, without specifying a migration, this module will stick to the order. Creating Migrations Your migrations will probably hold lot's of code, which does delete data. By now this module does not have any security measurements to prevent that. Be sure to test your migrations locally and possibly keep a database backup before running them. There are currently four types of migrations: default (Migration) Default migrations are the most free form migrations. There's just a description and two functions – update() and downgrade(). What you're doing in those functions is totally up to you, but it's recommended to try the best to keep changes as reversible as possible. Meaning that running update() and downgrade() once should have as less effect on the installation as possible. The ProcessWire API is available exactly like in modules using the $this->pages, $this->config, … syntax. FieldMigration TemplateMigration ModuleMigration All of those are there to make your life easier. They all have different but similar functions – which you can find in migrations created by this module – which ease the creation and removal of fields, templates or modules. All the boilerplate is handled by the base classes these migrations do extend, so you don't even need to think about update() and downgrade(). You can rather just describe the item you want to handle and the creation / removal process is taken care of. These are by now not highly tested, so please again be sure to test migrations before running them on important content. Command-Line Interface The module does include a cli interface, which does allow the migrations to be run automatically by CI or deployment scripts or just by you if you like cli's. The cli script is located in the bin directory inside the module's folder. It does however require a composer package to work, which you can simply add by running composer require league/climate in your site directory (or the root directory for pw 3.0). Make sure to require composers autoload.php in your config.php for 2.x installations. The CLI does have a quite handy help page, which you get by running php migrate -h so I'm just adding the important bits of that here: > php migrate -h […] Usage: migrate [-h, --help] [-i info, --info info] [-m migrate, --migrate migrate] [-n new, --new new] [-nf newField, --newField newField] [-nm newModule, --newModule newModule] [-nt newTemplate, --newTemplate newTemplate] [-r rollback, --rollback rollback] Optional Arguments: -m migrate, --migrate migrate Run a specific migration or all new* ones if none given. * From latest migrated to newest. -r rollback, --rollback rollback Undo a specific migration or the latest one if none given. -n new, --new new Bootstrap a new migrations file. Optionally you can already supply a description. -nt newTemplate, --newTemplate newTemplate Bootstrap a new template migrations file. Optionally you can already supply a description. -nm newModule, --newModule newModule Bootstrap a new module migrations file. Optionally you can already supply a description. -nf newField, --newField newField Bootstrap a new field migrations file. Optionally you can already supply a description. -i info, --info info Get detailed info about a migration. -h, --help Show all commands of the cli tool. Link the migrations cli update save to ProcessWire's root: https://processwire.com/talk/topic/13045-migrations/?p=118329 Helper Functions There are already a handful of helper function included in the Migration base class, which tackle things I found to need way to much boilerplate for kinda simple changes, but you can also add own custom helper functions via hooks. /** * This does use @diogo's while loop technique to loop over all pages * without getting memory exhaustion. */ $this->eachPageUncache("template=toBeHidden", function($p){ $p->setAndSave('status', Page::statusHidden); }); /** * $template, $field, $reference = null, $after = true * The below function reads like this: * In the template … add the field … relative to the field … in the position after/before */ $this->insertIntoTemplate('basic-page', 'images', 'body', false); /** * Edit field settings in context of a template */ $this->editInTemplateContext('basic-page', 'title', function($f, $template){ $f->label = 'Headline'; }); And a simple example of adding a custom helper as a hook. // in ready.php $wire->addHook('Migration::renameHome', function(HookEvent $event){ $name = $event->arguments(0); wire('pages')->get('/')->setAndSave('title', $name); }); // in the migration $this->renameHome('Root'); Snippets Still not sure how all this works in practice? Or you want to share a maybe more complex migration? Just head over to the Snippets Repo at Github. https://github.com/LostKobrakai/MigrationSnippets There are also less specific examples in the modules repository: https://github.com/LostKobrakai/Migrations/tree/master/migrations Appendix As long as the module is in Beta the helper functions in the Migration.php might be object to change/removal, so be aware of that. Download http://mods.pw/Bm https://github.com/LostKobrakai/Migrations

ClearCacheAdmin Module Since there's so many asking how to clear cache. Here comes a helper module that let's you clear caches directly from the admin menu. Additionally it has its own admin page that's a collection of the various caches available in ProcessWire in one place. See some infos and clear them. WireCache (using $cache) caches in the DB and there no way to clear it from the admin. Now you can delete the entries individually or all in one go. Supports following cache types: - Template "Page" Cache (disk file cache) - MarkupCache module (file cache) - WireCache (DB) - Other files and directories found in assets/cache/ path Wanted to do this for a long time. It was also great fun to do it and give something to the community to also learn something. For now it's on github only. Requires ProcessWire 2.6+. https://github.com/somatonic/ClearCacheAdmin

@Ivan, Back in 2012, I decided to compare access times of a locally hosted site both before and after I switched it over to InnoDB. At the time I was in a dialog with Ryan about the benefits of, at least, allowing InnoDB as one of the DB engine choices during install. After all these years, I am delighted to see it finally arrive. Here's a screenshot of the side-by-side results of running 500 requests vs a, then standard, PW install - one using MyISAM and one using InnoDB. In general, MyISAM was faster than InnoDB - but it also had a larger standard deviation in the delivery times. Don't worry about the "failures" reported above - remember that the default install back then would serve one of a set of random images and the test tool looks to see which responses matched the first response - a non-match counts as a "failure". InnoDB did have a slightly higher throughput in terms of requests served per second.

This week's version of ProcessWire adds several new panels that provide simpler and more direct access to the page tree, page view and debug tools. New page view options also include multi-language selection and configuration support. And if that's not enough, we've also got install-time utf8mb4 support and more! https://processwire.com/blog/posts/pw-3.0.15/

I'm looking forward to both the new Images field and the new version of CroppableImage. I got a little over-ethusiastic about V3 on a few sites and upgraded without checking compatibility. Made me realise the Croppable is probably one of my essential Modules. Thanks for the update anyway horst.

Not at all. Yeah why not. But I originally just wanted to be able to trigger the various caches by simply using their own API. I wasn't doing any real operations or deletions just delegation. I now added support for "Other files and directories in the site/assets/cache/ dir". For now they will now show up in menu and on admin page and you can delete them recursively. Version 0.0.2 is commited.

As fas as I know, currently there is no way for a module developer to include a changelog in a way that enables us to check out the changes in the admin before upgrading.

I've just commited a few smaller updates (most on Jonathan's requests) Migration descriptions are now escaped, so that characters like double quotes or backslashes won't break any newly created migrations. Also the backend UI does now feature a textarea instead of a text input to allow for multiline description entry. In the cli one would have to add "\n" linebreaks manually. The module does now try to add the /site/migrations/ path automatically, when it's called for the first time (e.g. by accessing the admin UI page) I've added a basic onboarding page for the admin UI, when there are no migrations, which does now feature a "Create New" button to get started. Jonathan did also request the addition of importer migrations for modules like FormBuilder or HannaCode. I'm not really keen on adding those and especially maintaining them. I'd rather suggest creating a GitHub repo, where the community can add migration snippets via pull-request. For example using the FormBuilder importer is just a single line of code, whereas the HannaCode importer would need to be copied nearly completely, because it's so tightly coupled with it's backend form. This repo option would be an easy way to just share the bits of boilerplate which is sometimes needed to do things via the api. Additionally I'm going to add some example above on how to add own helper methods to the Migration class with hooks, so everybody can add his own helper functions. Edit: I've added the mentioned docs about helper functions.

I build a PW site for a restaurant/bar and called the admin URL 'office'. Another was for a friend who operates an auto mechanic shop, called his admin 'toolbox'.

The admin URL is always based on something distinctly or uniquely associated with the client (so it's not hard for them or me to remember). It's just a matter of knowing detailed information about the client or their business.

Fantastic. Been waiting very long for something that takes me back to the days of Rails migrations! I will be doing a screencast on this in my WP vs. PW series. Just in time!

For those interested in migrations similar to Rails and other web application frameworks, see LostKobrakai's Migrations module: https://processwire.com/talk/topic/13045-migrations/

i think the best option is to remove the ACE completely and then have the module simply check to see if the Ace Extended module is installed, if it is, then use that and init for PHP; otherwise show a normal text area; the module could show a link to install Ace extended for those who want to edit their codes in the admin. I have a module that does this, and it so far works fine...

Perhaps sanitise the user-agent string you pull from the $_SERVER variable? I don't know how much of a risk it really represents in this case, but it is possible to overwrite these headers with certain browser extensions, meaning they can be crafted by cunning minds, to supply certain strings to applications. At the very least I'd think about stripping tags from that value before you store it.

Looks great, Benjamin, thank you! I have not tried this yet, but look forward to doing so. Could your module check if ProcessDatabaseBackups is installed? If it is perhaps it could take care of either backing up the DB or at least reminding the user to do so, before it performs a migration.

$sanitizer->int() or php natives (int) or intval() will do. Looking up in tools like API-gen, maintained (with everytime the newest codebase) by Kongondo, is much more faster than asking (such simply code/method related things) in the forums. I highly suggest to use this. It will save you a lot of time, that you otherwise have to wait until someone other answers your questions. --- EDIT: Oh damn, - @arjen beats me, while I made the screenshot!

Hi folks! I'm about to add my new module FieldtypeAssistedURL to the repository. You find the source code on github and hopefully in the modules repository soon. Here an extract from the README.md: This module offers you a new field type AssistedURL Field, providing and input field for storing absolute and relative URLs. The field type adds a button to open the URL chooser dialog known from the CKEditor link feature without the tab navigation bar for specifying link attributes. Using the URL chooser dialog the editor may select URLs from internal pages or uploaded files via a search field with auto-completion, a page tree control, and a file selector control. Please feel free to post suggestions and any form of feedback here in the forums or on github. Wumbo

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

Basically as soon as I can. This is something that I would love to use myself, so I am eager to get it finished for various personal projects. I could have finished this by now if it was for my personal use, as I would have cut corners here and there, but I want to release it as a module that everyone can use. This is a part time project for me as I'm not a PHP programmer, so I often don't know what I'm doing. But I have the ideas and a vision, so I will crack on and hope others comment on my code in order to improve it. As a prime example, do you personally like the idea of being able to choose your own module for the comments / replies? I could hard code it into the core module as I did previously with HermodBB, but if other modules exist to fit the bill, then why invent the wheel? But that's just my opinion. PW gives us so much flexibility, and that's what I want to take advantage of. PW takes care of users, permissions, profiles, and that's the beauty of it as it's something I don't need to bother with.

Hi all, here's my first official module. I created it for a project I'm working on, so I thought I'd release it in case anyone else finds it useful. If you have any suggestions or find any issues with it etc, please post them here. ​ NOTE: I have only tested it on PW 3.0.3, so you might want to try it on a test installation first if you decide to use it. ​Lumberjack Logger Module A simple module for ProcessWire CMS that logs the IP / User Agent details of the user when the page is saved. Installation Copy the Lumberjack folder to /site/modules and then refresh the modules from Admin->Modules. Lumberjack can then be installed. Usage Two new fields will be created when Lumberjack is installed. lumb_ip_log - This field is used to store the IP lumb_ua_log - This field is used to store the User Agent String You can add both fields or just one to the required templates. Pages using those templates will then automatically store the IP and User Agent of the user when the page is saved. Settings Lumberjack can be disabled by unchecking the Enabled option on the settings page. ​ Screenshot ​ Download ​ Link https://github.com/GuruMeditation02/Lumberjack Updates Version 0.1.1 - Added User Agent String santization

Actually, this is the blog post in question: the one about ProcessWire 3.0.14 I have just tested and you are right, it does not seem to work (PW 3.0.15). I set all the "Use Compiled File?" settings to auto, cleared the template compile cache folder (/site/assets/cache/FileCompiler/site/templates) and the files keep coming back. And my template files start with namespace ProcessWire;

Hi rlwsota, I have started to rewrite some code and it will be released as LiteBB. The test code module I released can be classed as discontinued at this stage, so I don't recommend using it. The code for LiteBB is similar but I have renamed some fields etc and have started to rethink some aspects. At the moment I'm thinking along the following lines: LiteBB module (the core), which will essentially install the required templates and fields that you would expect for a forum. Just like HermodBB does now. Page-based Comments module. Comments are topic replies, and I'd like to offer a page-based version of Ryan's. My idea being that LiteBB users can choose to use their preferred module for the comments. Various optional modules. An example being the Lumberjack logger module I released that is responsible for logging the user's IP / User Agent etc.

And 3.x in fact - I've got it running on an installation there with no issues (auto-compiling for namespaces nicely).

A search to hide "delete" tab brought me here. Thanks soma for the code. In order to hide the tab(s), you have to add another hook to edit form: $this->addHook('ProcessPageEdit::getTabs', $this, 'hookEditFormTabs'); public function hookEditFormTabs($event) { // logic check // if ($this->user->isSuperuser()) return; // if ($this->page->id != 29) return; $tabs = $event->return; unset($tabs['ProcessPageEditDelete']); $event->return = $tabs; }

I am wondering is there a way to alter MyISAM tables to InnoDB on a working installation. Wanna try it for the increase in speed for the daily service script. Or is it a bad idea?

I've released the module mentioned above as beta: https://processwire....045-migrations/

I thought just after I posted it could be the field type. It is a text field, so that's obviously the problem. Thanks for confirming

Is h_age a textfield or a integer/float field? Only the latter ones should be able to use the >/< operators.

Just wanted to use this medium to say i am extremely happy and impressed with the community, I have been away from Processwire because of works and pressure, each time i come back here i see something amazing, and honestly Processwire 3.0 is amazing and looking forward to do crazy things with this.

No, sorry. I meant it's not a good idea for the compiler to add a namespace declaration. You yourself can do what you want / need to do in your template files.

Thanks for the report. I commited an update that fixes this. I hadn't thought about it and was runnning php 7

I did this once because I created a whole backend area for the users, and didn't want the user to ever see the processwire admin. But i usually just leave as it is if the client is okay with it, or like @OrganizedFellow, i change it to something appropriate.

The mix of preg_replace_callback and str_replace here doesn't work (throws an "Array to string conversion" error), as the $match passed to the callable is an array of matches (with $match[0] being the entire matched string and $match[1..n] the first to nth capturing group). It would need to either be written as function replace($match){ return 'P. Jentschura'; } or, as the others wrote, simply get rid of preg_replace_callback completely and directly perform a str_replace. public function formatValue(Page $page, Field $field, &$value) { $value = str_replace('P. Jentschura', 'P. Jentschura', $value); }

I guess too low PHP version.

I always change the admin URL. I feel that is just as important as ensuring that the admin account is something other than "admin" or "administrator".

Sure. I just wanted to get it out, but this can certainly being added. We're using Cronjob DB Backup on our project so it's not been so much a necessity for me. Also it wouldn't even need to check for anything as the backup functionality is part of the core. Only the admin UI must be installed.

This might come in handy, it's still hot: https://processwire.com/talk/topic/13042-clearcacheadmin/

Please don't forget to share the URL once you got this sorted

@GuruMeditation Thank you for the module - and welcome to the wonderful world of "official" module authorship!

Hmmm, PHP 6? Really? AFAIK not an officially supported version. (Google for more info.) You would probably be better served with 5.6 or maybe even 7. Anyhow, GD support is pretty much a requirement for most hosting. PW uses it to resize/crop images. The combination of PHP 6 and no GD throws real doubt on the competence of your hoster,

Ah yes right, negative evals to true. So then correcting mine: if($id > 0){...} But don't see why that would be an issue to have a negative page id it won't find it anyway.

what? please try: foreach(array(-5, -1, 0, 1, 5) as $id) { var_dump((bool)$id); }

Usually like this. $id = (int) $input->post->id; $p = $pages->get("id=$id, template=dings"); if($p->id){ // valid } else { // not valid }

Which, in plain vanilla PHP is $pageID = abs(intval($id));

Does TextFormatterHannaCode need to be so large? The bundled version of Ace contains all 4 versions of the Javascript files, but in ProcessHannaCode.module I can only see the src-min version being called in. Removing these and the demo directory would reduce the size of the module by around 38MB. Are there licensing issues which require that these files must be present?

$dishes = $pages->find("…, sort=parent, sort=XX"); $parentID = null; foreach($dishes as $dish) { if($parentID === null || $dish->parent->id !== $parentID){ $parentID = $dish->parent->id; // render restaurant headline } // render dish list item }

Great. Thanks for sharing! And honestly, i would never have considered this.

Getting back to this topic may I ask if there are any plans to update the cheatsheet in near future? Or is it discontinued? The cheatsheet is such a valuable resource. I would be glad to assist in updating it but I'm afraid my understanding of the API isn't good enough. Thanks for keeping us informed.

Hi Joe. A simple search via google (processwire.com hide settings tab) found my thread a while ago: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/ Here's another example doing it differently: // in a autoload module like HelloWorld.module public function init(){ $this->addHookAfter("ProcessPageEdit::buildForm", $this, "buildFormHook"); } public function buildFormHook(HookEvent $event){ // get page edited by ProcessPageEdit $page = $event->object->getPage(); // conditions if(wire("user")->hasRole("superuser")) return; if($page->id == 1039) { // the form InputfieldWrapper returned by ProcessPageEdit::buildForm() $form = $event->return; // find the desired InputfieldWrapper's and remove them from the form $fieldset = $form->find("id=ProcessPageEditSettings")->first(); $form->remove($fieldset); $fieldset = $form->find("id=ProcessPageEditDelete")->first(); $form->remove($fieldset); } } This works fine in PW.