Leaderboard

I'm happy to announce that we are back on Processwire this morning. @Jonathan Lahijani contacted me based on this post and took on the daunting task of redeveloping / designing our site and has done an amazing job. I'm very pleased with the results. We have a few tweaks to do here and there but functionally, it's more than I was hoping for. Jonathan will be doing a full write up on the process here within the next couple of weeks but for now I just wanted to let everyone know and get some feedback on the new site. Also, HUGE thanks to @Jonathan Lahijani for doing such an amazing job. ~Mike

Version 0.9.12 I added a single centralized translation file. It combines all text strings of all module and dependency files. This way it should be easier or lesser work to translate it. (<- hint @ceberlin, @Manfred62, @yellowled ) @apeisa: Also the legacy and serious text selection is included. (legacy is default!)

It looks to me like they should both work just fine. Just one thing to mention though. You could simplify the whole thing to: if($wire->users->count("email=$em") === 0) { $validMail = 1; } else { $validMail = 0; } or in my mind, even better: $validEmail = $wire->users->count("email=$em") === 0 ? true : false; Of course you could do the 1 : 0, but I think true : false is more appropriate because then later on you can do: if($validEmail) { Note in both cases I am also using 'users' instead of 'pages' which is more descriptive in this case. Also, using the PW count() method is much more efficient as it doesn't actually grab all the data, it just counts matches. You can even take it one step further if you only need to check if it's a valid email just one time: if($wire->users->count("email=$em") === 0) { //email is valid so do whatever here - maybe this is where you add them like: $u = new User() // etc etc }

Just posting a teaser at the moment because I am not yet sure if this should be a standalone module, or part of the still unreleased Module Toolkit (https://processwire.com/talk/topic/8410-module-toolkit/). Now available here: https://processwire.com/talk/topic/15702-module-settings-import-export/ It is quite simple in its execution - it adds a Settings Import / Export collapsed fieldset to the top of the module settings page of all modules. You can copy settings from one install and paste into another and click "Import Settings". It works quite like PW's core template and field import/export functionality. Simple as that PM me if anyone is keen to try it before I decide where and how it should be released. Settings are automatically saved when you uninstall a module, so you have an easy way to restore them when you uninstall. Anyone have any thoughts on any of this?

@verdeandrea: This notice is shown when PHP was compiled with Zend debugger enabled and an empty file field is submitted. The best course of action would be to install a non-debug build of PHP. Temporarily, a possible workaround might be to disable E_NOTICE warnings by setting "error_reporting(E_ALL & ~E_NOTICE);" in site/config.php.

Which folders/files will be created by the application after installed ? After installation usually the only place where folders/files are created by ProcessWire is inside /site/assets. But 3rd party modules may also use different places. Which folders/files usually be overwritten? Same answer as above Which folders/files using as cache, as session, as temporary? /site/assets/files /site/assets/cache /site/assets/sessions Do ProcessWire supports logs? If so, where is it? /site/assets/logs, $log Which files are using as configuration files? Should I concern about template configuration files? That's the place where deployment tools won't help, as ProcessWire doesn't store configuration in files (for the most part anyways). There are a few tools out there to accomodate for that fact, but iirc my Migrations module is the only one you could run via cli by a deployment script.

You do realise that if you (and Adrian with Tracy) keep developing your modules at this rate, they will become sentient before I do.

Yes, switching to a non-debug build is the way to go.

Yes, in the first table phpinfo prints, there should be a line starting with "Debug Build".

bd() and all the other shortcuts are available in the global namespace so you shouldn't need to do anything special. Is that not working for you? Does it then actually work with use\Debugger" & "Debugger::barDump(...) ? If so, could you perhaps give me more info about where in the module you are trying to make the call?

I don't think you need nested repeaters, just a single repeater that has a title field (title of the gallery) and an images field. The images field can contain multiple images. Use the description field for each image for the overlay text.

I created a simple image field (wihtout repeater). If you want a real example on howto use a repeater to make a carousel, tell me your repeater's structure and I will give you a working code but looking at your HTML markup, an Image field only like I did should be sufficient to achieve it.

I've added a checkbox to opt-out from automatic restore in my module.

I think forgetting settings by default is the most clean way (on uninstall), but there should probably be ways to let developers choose different paths if needed. Maybe "deactivate" could be a non destructive way to disable a module, whereas "deinstall" is the clean sweep, where everything is removed.

No, it's the other way: we just try to bring you the most of what the module is capable before you get sentient

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

This module provides a solution for keeping various site settings in one place (titles, slogans, api keys, emails, addresses, etc.). Features - Admin can create unlimited number of settings - Settings can be grouped - Admin can set setting label, notes, property name, field width and type - Settings can be of type text, checkbox, radios, select, email, url, integer How to use In module configuration create as many settings as needed. Customize their label, type, width and provide a name you want to use in a template files (property name). After that admin can set those settings on "General Settings" page in "Setup" section. Every time you wish to output eg. site name you can use $settings->site_name or wire('settings')->site_name or $settings->option2 to get value of 'Check it' as seen on the first screenshot. (Checked checkbox returns 1). You can change global name ($settings) to something else in module configuration. To get basic markup with all settings and their values use $settings->render(), usefull to check returning values (esp. select/radios - their values are sanitized as page names). Current limitation: -no way to change order of settings, -new settings can only be added at the bottom. Multilanguage To make fields multilanguage aware create a field with a same property name with '_languageName' appended. Example: Your site has two languages: default and french, create site_title and site_title_french fields. Put in a template $settings->site_title. If a user has set french language, this module output site_title_french, otherwise site_title. Please notice that render() function is not language aware. https://github.com/pmarki/ProcessGeneralSettings

There isn't any classes on the html element.

Thanks, that was a PHP version syntax error which was fixed. v055 is up: module settings restore is optional (disabled by default) JS workaround for field edit links for ajax-loaded fields syntax error fix (thanks to TomasKostadinov)

This discussion might help: https://processwire.com/talk/topic/13977-custom-php-code-selector/?do=findComment&comment=125688

Hi tpr, for me v054 gives an error just after updating: Parse error: syntax error, unexpected '.', expecting ',' or ';' in /Users/armin/Websites/pwreiter/site/assets/cache/FileCompiler/site/modules/AdminOnSteroids/AdminOnSteroids.module on line 23 I'm running on PW 3.0.32 in local environment (MAMP). I had no issues with past versions of AdminOnSteroids.

You are right! It says "Design Build = yes". So i need to ask to install a not-debug version of php?

So that is why he did not have time to release his video tutorials? Never mind, at least cmscritic.com is back to normal. Thanks for reporting!

Here's another one: Seems to happen after a field has been collapsed.

Great to hear. I have restored your listing on the sites page: http://processwire.com/about/sites/list/cms-critic/ @Jonathan Lahijani - if you want to send me the details you want entered in the Made By section, I'll update that too!

Glad it's working. Just a couple of FYIs for using Tracy with modules in case you missed them from above. If it's an autoload module, then sometimes Tracy isn't loaded before the module (nothing I can do about this until Ryan gets back to me). The other thing is that sometimes it pays to use the Dumps Recorder panel with "Preserve Dumps" checked as sometimes things can get lost during redirects within modules. This way, a simple reload will refresh the content of that panel and you'll have your dump.

shzzzzz .... yes it is just there "bd()" - don't know what went wrong here ^^ I was working in the execute() function of a Process module Thanks!

Ok, I will take care of the translation to DE tonight...

I'm of course dealing with server load issues at the moment. I'm speaking with my host now.

Multilanguage can complicate things a lot and most non-techie people doesn't even recognize that. At one of my workplaces they asked me to place 3 language flags to the header - they thought it's just as easy like that

Yes, I used to use MultiValueTextformatter for this and had the same worries. Just modified it a little to have 'some kind of multilanguage support', not as convenient as built in pw, but better than nothing

When viewing your PHP Notice from the first post, this is nothing coming from PW, it looks like coming directly from PHP. (I have scanned the PW 2.5 wire files for a part of that phrase!) Also, I don't get why it every time you save, speaks about upload? What modules and third modules are active on that site?

You should check it manually for one page. Go to a problematic page with an images field that must have an image (from the old hoster). Look at the Page-ID (you see it in the browsers status bar when hovering over the tabs on top: http://example.com/processwire/page/edit/?id=1234.... Then go ()via FTP) to site/assets/files/1234/ and look into the folder what files and variations are in there, and also what access settings are applied. When you above said you also tried 777, how have you done that? You know that it doesn't work onyl to change the settings in the site/config.php, yes? You need to set it in the filesystem on the new host! Via FTP, set all site/assets/ directories incl. subdirectories and all files to the needed access settings for PHP user on that server! This is nothing what has to do with PW nor what you can handle with PW. You need to do it manually.

sounds like directory / file access failures! Have you checked / doublechecked the settings for site/assets/files/... and all subfolders and files? Is PHP / PW able to modify / save / delete files there? Are all your files from the old hosters site are moved into the new one, or are there some missing?

Hi, I made a ProcessWire profile powered by Bootstrap 4 with a bootstrap carousel. You can look at the code there : https://github.com/flydev-fr/site-pwbs4/blob/master/templates/_func.php#L213-L250 and adapt it for your need. It should be really easy. Which version of Bootstrap you are using ? (it look like you are on version 3.. confirm ?)

Hello everyone, I didn't play much with ProcessWire, my project has just started and I have no experience about how ProcessWire will be when go live. I'm using a tool to deploy my code automatically to production server after build passed (Magallanes). Please give me the answers for the questions below: Which folders/files will be created by the application after installed ? Which folders/files usually be overwritten? Which folders/files using as cache, as session, as temporary? Do ProcessWire supports logs? If so, where is it? Which files are using as configuration files? Should I concern about template configuration files? Any help would be appreciated. Thank you!

Yeah, but that's just about it. Any module / template / field or other setting is saved in the db.

Hi @szabesz, thanks for your interesting. I've created poor documentation here: https://magephp.github.io I'm using GitLab and GitLab CI for all projects I had. So the purpose of the tool is, whenever I have a new push or accept merge request to production branch (master) or staging branch on GitLab. GitLab CI will start building my project and execute Magallanes deploy command. The repo changes content will be pulled to my server as a new release, and that release directory will be symlink to my `public_html` directory. I'm using 2 environments: production and staging. My magallanes config for staging should look like this (located at <project_folder>/.mage/config/environments/staging.yml) # staging environment deployment: strategy: git-remote-cache # git clone a bare repository on your server, then using git archive to get your code faster than usual ways user: www # your webserver user, or whatever user you want if it had read write access to webserver group port: 998 # ssh port from: ./ # local source code directory, e.g if you put source code into src/ directory, you need to change this to: /srv/users/www/apps/magento # your remote directory which contains public directory excludes_file: .rsync_excludes # all files/directories declared in this file will be deleted if you are using rsync strategy extras: enabled: true # don't turn it off :) directory: shared # your bloody share directory on the server vcs: enabled: true kind: git repository: git@gitlab.com:xxx/magento.git branch: staging # change if you are using different branch, obviously remote: origin # looks at above comment directory: repo rsync: enabled: false # set to true if you are using rsync-remote-cache strategy from: ./ local: .rsync_cache remote: cached-copy magento: enabled: false # set to true if you are deploying magento application app_path: bin/magento # magento executable file shared: # most important section enabled: true # always set to enable linking_strategy: absolute # i do not suggest you change this to relative linked_files: # contains all files you want to keep every deploy - app/etc/env.php - var/.magento_cronjob_status - var/.setup_cronjob_status - var/.update_cronjob_status - sitemap.xml linked_folders: # directory contains dynamic assets like logs, product images, session you want to keep - pub/media - var/log - var/session releases: enabled: true # i recommend you turn on release mode :) max: 10 # how many release you want to keep in releases directory symlink: public # what is the symlink name of every release after deploy, it may be public, public_html... based on your webserver configurations directory: releases # the directory you keep releases, it will be created inside 'to' of 'deployment' section hosts: - bloody-production-machine # your ip, ssh aliases. i do recommend you use ssh aliases for the god sake. tasks: pre-deploy: # task will be execute before deploy on-deploy: # task will be execute while deploying post-release: # task will be execute right after a release created - composer/update - magento/staging-setup - magento/set-permissions - filesystem/link-shared-files post-deploy: # tasks will be execute right after all above tasks section complete So with the above configuration, Magallanes will work like this as sequence (all remote tasks in Magallanes will open new ssh connection): Check your SSH is fine and created extras >> directory on your server if it didn't exists. Clone a bare repository into 'shared' directory from extras >> vcs >> repository. If releases >> enabled == true, then create new directory on your server named releases >> directory. Using git archive from bare repository to a new directory in releases >> directory >> unix_time Check tasks section and execute all tasks inside post-release If no error, then created new symlink in your deployment >> to under name releases >> symlink Done. If you need further information, please let me know. Sorry for my bloody English.

@Hector Nguyen I've never heard of it but Magallanes does look "interesting" indeed. So I'm interested in how you will set up your projects. I would be happy to improve my workflow if Magallanes can be the tool to do so. As for your actual question, I could answer it too but let's leave it to more experienced ProcessWire developers. I might miss something...

I'm using my MultiValueTextformatter module for such things, added to the Home page. Works fine, though it's for the developer only, not for the client because he could easily mess things up. If I use an InputfieldTextaraeaLanguage then it's multilanguage too - btw, is your module multilang capable? I have another idea in mind for such a module that would heavily depend on JavaScript (namely Vue.js). It would be responsible for the UI, all settings would be saved as one JSON.

Definitely 3! Here is a slightly outdated review of changes between 2 and 3: https://processwire.com/blog/posts/review-of-processwire-3.x-so-far/#whats-changed-between-2.x-and-3.x

Something like this could help: $(document).on('keydown', function (e) { e = e || window.event; var closeBtn = $('.ui-dialog-titlebar-close'); if (e.keyCode === 27 && closeBtn.length) { // ESC closeBtn.trigger('click'); } }); You just need to figure out the selector of the close button - I'm not sure they are all the same, but perhaps I'm wrong. In the next version of AdminOnSteroids (uploaded soon) there will be a feature to add custom JavaScript so you just need to place it there.

I've just added a feature to automatically save module settings to file on uninstall, and restore on install. This way you can uninstall the module without having to re-add settings later if you decide to install again. Additionally, settings can be moved easily from one project to another. With this I can apply more "safe" default settings and leave the more advanced stuff to those who need them.

By the way, I don't remember which version introduced this, but you can use $field->getLabel() instead http://processwire.com/api/ref/field/get-label/

Thanks all. There's really a lot wrapped into this. It connects to a lot more than I'm showing here. The test server doesn't show the other kinds of help desks we have. This one is the IT version, but there are 2 other variants of this system, one of which is for marketing (which has a bunch of additional fields when you complete a ticket). The original tickets are powered by FormBuilder. That way there can be all these ticket variants without having to create or try and reuse a bunch of fields. Once the ticket is created, it's sent to a PW page. The Formbuilder JSON (and the JSON for the actual Form) are saved to the page. This way, if the form fields ever change, it doesn't effect old tickets. Essentially the state of the form and the entry are snapshot together and attached to the page. The replies/internal notes are an extended version of the comments field so that everything is contained within a single page. It doesn't have to be that way, but I had already created this modified comments field for another project, so it was the easiest way to go with this project. Anyhow, It's not something I intend on releasing at this time, but may revisit it eventually if there's enough interest. I would remove the FormBuilder dependency if I made it public.

I haven't really read all of this thread, but just wanted to chime in with a brief overview of a help desk system I built. I can only show you screen shots from the test server — since the real one has sensitive data — but I think you get the idea. Unfortunately it's all pretty specific to our environment here, and was never intended to be released. Ticket List This is pretty small in the test environment. The lighting bolt icons open a modal that shows some "quick look" information for admins. Last comment, ticket history, etc... It's just a way to quickly peek into a ticket without opening it. Ticket View Many of these test tickets are filled with a ton of content, but here's one that shows some of the features. It's conversation based. You can attach specific equipment (we have several equipment databases managed in other PW modules). You can add files/images to any reply. Typical help desk stuff really. Reply options This is at the bottom of the discussion, a lot like it is here in the discussion forum. Agents can reply or create an internal note.

Just to clarify, I'm not working on the core image field, I only work on the CroppableImage Modules, to make them work with the new core Imagefield in PW3. It will inject a small section with buttons into the head of the edit area, like here, (predefined Crops) The buttons will open a modal editor window. The editor window should get some new styling. Thats it. And this only is possible because of the sponsoring through DREIKON, who are so kind to donate 500+ Euro for my work on this, what is much appreciated. Otherwise I wouldn't be able to invest the needed time for it, atm. Current state is: injection works, modal open and close works, rearanging / styling of the editor window needs to be done, testing needs to be done.

I can prove that he does so: He even writes tutorials about the topic: http://soma.urlich.ch/posts/custom-js-in-processwire-admin/

Why should it not be available on the front-end? It's just you have to output the stuff in your header. Look at the default.php of templates-admin/. I always use it in my sites. <script type="text/javascript"> var config = <?php echo json_encode($jsConfig); ?>; </script> Then use the config.key in your JS.

Few things that are "nice to know" when building PW modules: Autoload and non-autoload modules: autoload ones are loaded on every page load. So if you need to hook into core, then you probably need autoload. Non-autoload modules are run only by request: $modules->get("myUberModule")->doSomething() When you need hooks? Well.. common things are "do something when page is saved", "alter the output that is generated", "do something before page is accessed" etc.. Actually there is quite a many hooks and best way to find right hook for you need is to ask for it here. Building modules is pretty similar to working with templates. Nothing "special" there. Few notes though: You cannot directly access the PW API variables like $pages, $session, $input etc.. Those are available at $this->pages or wire('pages'). If you have static method(s) in your modules then you need wire('pages') there - so if you want to play it safe always use that (it works on command line scripts also) Modules can have settings - those are very easy to implement (just look examples from other modules that have settings) Modules are cool. init() is run before page is loaded, so if your autoload module needs to know the current page, that is available at ready() method. Forums is your friend, just ask and someone (probably Soma with his quick editing skills) will surely help.