Leaderboard

It sounds like one of the factors that determines which roadmap items get attention first is the level of interest within the community (makes sense). But it would be good to have a more accurate and transparent gauge of the interest in each roadmap item. A simple solution would be to have an official Roadmap sub-forum with a topic for each roadmap item (separate from the Wishlist sub-forum). The community could then indicate their interest in each item by "liking" it, and give feedback or ideas about implementation in topic replies. My vote for most desirable roadmap item: Add support for custom properties in file/image fields.

HI @lickny2001 Try to use "insertAfter" method https://processwire.com/api/ref/wire-array/insert-after/

You might also find this post: https://processwire.com/talk/topic/11499-admin-restrict-branch/?do=findComment&comment=144184 by @kixe useful - it talks about using that module with the multi-site module - I think this combination will help with what you want to achieve.

I built ProcessWirePageLists a long time ago - it works with Migrator and lets you install the fields and templates (and in some cases pages) for getting started quickly. https://github.com/adrianbj/ProcessWirePageLists The `person.json` file is probably the most relevant to the question you are asking. You could easily build one-click installs of templates/files all sorts of things, like a blog, hotel booking field/templates, news articles, image gallery, ecommerce - whatever really. Maybe I should commit some more myself, but my original plan was to get user contributions to that repo. This is how you "install" them. They are pulled in at runtime directly from Github, so new ones are always available. This is what the JSON looks like for "person": { "templates":[ { "template":"person", "data":{ "useRoles":0, "childrenTemplatesID":0, "sortfield":"", "noChildren":"", "noParents":"", "childTemplates":[ ], "parentTemplates":[ ], "allowPageNum":0, "allowChangeUser":0, "redirectLogin":0, "urlSegments":0, "https":0, "slashUrls":1, "altFilename":"", "guestSearchable":0, "pageClass":"", "pageLabelField":"", "noGlobal":0, "noMove":0, "noTrash":0, "noSettings":0, "noChangeTemplate":0, "noShortcut":0, "noUnpublish":0, "nameContentTab":0, "noCacheGetVars":"", "noCachePostVars":"", "useCacheForUsers":0, "cacheExpire":0, "cacheExpirePages":[ ], "label":"", "tags":"" } } ], "fields":[ { "name":"title", "label":"Title", "description":null, "template":"person", "flags":13, "type":"FieldtypePageTitle", "data":{ "required":1, "textformatters":[ null ], "size":0, "maxlength":255 } }, { "name":"first_name", "label":"First Name", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"last_name", "label":"Last Name", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"portrait", "label":"Portrait", "description":null, "template":"person", "flags":0, "type":"FieldtypeImage", "data":{ "extensions":"gif jpg jpeg png", "maxFiles":1, "inputfieldClass":"InputfieldImage", "descriptionRows":1, "adminThumbs":1, "defaultGrid":0, "fileSchema":2 } }, { "name":"position", "label":"Position", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"department", "label":"Department", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"email", "label":"E-Mail Address", "description":null, "template":"person", "flags":9, "type":"FieldtypeEmail", "data":{ "size":70, "maxlength":255, "columnWidth":50 } }, { "name":"website", "label":"Web site", "description":null, "template":"person", "flags":0, "type":"FieldtypeURL", "data":{ "noRelative":0, "addRoot":0, "columnWidth":50, "size":0, "maxlength":1024 } }, { "name":"phone", "label":"Phone", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":33, "size":0, "maxlength":2048 } }, { "name":"mobile", "label":"Mobile Phone", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":34, "size":0, "maxlength":2048 } }, { "name":"fax", "label":"Fax", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":33, "size":0, "maxlength":2048 } }, { "name":"po_box", "label":"PO Box", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"address_1", "label":"Address", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":50, "size":0, "maxlength":2048 } }, { "name":"address_2", "label":"Address", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "size":0, "maxlength":2048 } }, { "name":"city", "label":"City", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":33, "size":0, "maxlength":2048 } }, { "name":"state", "label":"State", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":34, "size":0, "maxlength":2048 } }, { "name":"country", "label":"Country", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":33, "size":0, "maxlength":2048 } }, { "name":"skype", "label":"Skype", "description":null, "template":"person", "flags":0, "type":"FieldtypeText", "data":{ "columnWidth":33, "size":0, "maxlength":2048 } }, { "name":"twitter", "label":"Twitter", "description":null, "template":"person", "flags":0, "type":"FieldtypeURL", "data":{ "noRelative":0, "addRoot":0, "columnWidth":34, "size":0, "maxlength":1024 } }, { "name":"facebook", "label":"Facebook", "description":null, "template":"person", "flags":0, "type":"FieldtypeURL", "data":{ "noRelative":0, "addRoot":0, "columnWidth":33, "size":0, "maxlength":1024 } } ] }

I know this old, but the answer to this question is to add: $accept->attr('data-href', wire('config')->urls->admin . 'page/edit/?id=1479'); Remove this line: $accept->attr('href', 'http://localhost/winkelmann/www/bewerbertool-talents/admin/page/edit/?id=1479'); Hope that helps the next person.

You could look at @kongondo's Blog Module http://modules.processwire.com/modules/process-blog/ for your News site and this thread may give you some ideas on how to cut down front end development time

Hi @cosmicsafari Just look in the cache directory for a file called LazyCronLock.cache. If it is there for more than half a minute (or however long you estimate your code should run for) then delete it to unjam LazyCron. If this keeps happening, then there could be something in your hook method that is timing out and leaving the lock file there. Here's some code to return the location of the file if you want to do it programmatically... function getLazyCronLockfileName() { return wire('config')->paths->cache . "LazyCronLock.cache"; }

I usually go by @rafaoski's approach. I first go to http://www.favicomatic.com/, upload a 500x500 image to generate a full icon pack. Then I place the icons in their own folder inside the templates folder. Usually /site/templates/img/favicon/ Favicomatic gives you a rather large HTML snippet. Slap that on your template, and on each line that points to a file, you'll have to fix the url, like so: <link rel="icon" type="image/x-icon" href="<?= $config->urls->templates ?>img/favicon/favicon.ico">

Starting point - https://processwire.com/api/modules/multi-site-support/

DEPRECATED - USE ROCKMIGRATIONS INSTEAD I'm very happy to share my newest module called "ProcessWire Kickstart" that I developed during the holidays Maybe some of you already saw the preview thread about this... What it does: This module makes it possible to install ProcessWire in a fully automated process. You can define all necessary settings in one single php file and you can even define "recipes" that get executed after installation. This means you can install modules, adopt settings and do whatever you want with your new site using the PW API (like creating pages and so on). You could also place a kind of frontend boilerplate on your git account and grab that after installation and place it in your templates folder. I ran out of time so maybe someone could try that out and show how he did it Additional to that there is a ProcessModule to install in your ProcessWire admin which makes creating and testing recipes super easy. Note: Alpha realese until this module gets some more testing. Please be careful with this tool since it does some heavy file system manipulations (unzipping, moving and DELETING whole directories...). Use at your own risk. Usage: Just grab a copy of the kickstarter, place it on your server, visit yournewsite.com/kickstart.php, adjust settings (like username+password) as needed and hit "install". If your mysql user does not have the rights to create a new database then you have to create a database before running the installer! Download: via SSH: cd /var/www/yournewsitedirectory wget baumrock.com/kickstart.php // or using curl curl baumrock.com/kickstart.php -L --output kickstart.php Manually: Klick baumrock.com/kickstart.php and upload the file to your server Note: baumrock.com/kickstart.php returns the current master file from the gitlab repo and changes the namespace of the script so that it can install itself via recipe. If you don't need to install the kickstart processmodule via recipe you could also download the kickstart.php file from gitlab. Screenshots/Walkthrough: The initial Screen: You can either upload a file via the left panel or take my example file from the gitlab repo: This way you can create your own kickstartfiles and host it on your own accounts. When the file is loaded you can easily edit all necessary informations, like username, password and the url where to grab ProcessWire from. I just tried it with an old version as well... 2.7 worked just fine (having the old installer that recently was updated) but an ancient 2.2.4 version failed. I don't think anybody will ever need to install lots of old versions of pw with this tool but I wanted to mention it here. Hit "install" and lean back - on my VPS it takes 15 seconds to install my very own custom version of processwire with all modules that i need After logging into your admin you'll see that all modules from your recipe are installed: Recipe Editor: As recipes are executed after processwire was installed you have all your API magic available there. Running this scripts is only possible inside of a working processwire installation, so I created a module to help you with that task. See the comments of the sample recipe for more information! I hope this tool helps you to save lots of time and create lots of awesome ProcessWire websites I would be happy to see how you use this and please share useful recipes here in the thread so that everybody can profit. Maybe you just want to throw in an idea what could be done (for example I can imagine a recipe that checks file permissions on the system after installation)... Some parts of the code and maybe also part of the idea are taken from @Soma 's old and still great online installer, thx for that!

In this post, we take a look at all that was covered in 2017, and our roadmap for 2018, which includes plans for the year ahead. https://processwire.com/blog/posts/processwire-2018-roadmap/

Yeah, Site Profiles are nice, but what I like about my poorly named "Page Lists" is that they can be applied one-by-one as components as needed and also added to a site after initial PW install. I'd really like to build these out if we can get some community contributions.

p.s. I'm finding my bearings around here again. I think "Site Profiles" represent what I'm talking about, either in part or wholly. I'll go learn there also. I must say, I couldn't find a definition of "Profile" in the docs, I didn't know what that meant at large. https://processwire.com/ promotes the trees but doesn't say much about the forest and its varied on-boarding trails.

Thank you very much for that one, Adrian. I'll definately look into that one.

Thanks @flydev, I know this will be very helpful to others as well!

You will end up with a PHP function (written by @mindplay.dk) ,two templates and pages which will define your menu. I will write the tutorial a bit later in the afternoon.

if you have a little courage (and if anyone else is interested), I can write you a little tutorial but you must put your hands dirty ?, let me know.

VS Code is in need of one too.

OK, it works. Thank you for your replies.

Thanks @Robin S - I have made that change along with some code cleanup and making all the module setting strings translatable.

Hi @adrian, Could you please make a small change in ModuleSettingsImportExport.js to avoid an undefined variable error in PW 2.x? On line 11: var allModuleSettings = typeof ProcessWire !== 'undefined' && ProcessWire.config ? ProcessWire.config.allModuleSettings : config.allModuleSettings; I think this might be all that's needed for PW 2.x compatibility (although I haven't tested extensively). Thanks.

Gave it a vote

@flydev, thanks for the report. Looks like I didn't account for use of InputfieldPassword without an associated FieldtypePassword. Fixed in v0.1.5 (I changed to semantic versioning).

There are loads of favicon generators. I generally use https://www.favicon-generator.org/ then point the link href to the appropriate directory & file

You mean JSON? Or Serialized array? Here are a couple of posts (not all may be directly relevant in your case, though).

Well, uh, FWIW I’ve encountered a problem today that may or may not be similar. My backend sessions were working as fine as ever, but users on the frontend would get logged out immediately after logging in. Basically, they would get their welcome page but their next request would fail. After disabling Session Handler Database sessions would persist nicely. Now when I saw you mention the Multilanguage setup, I had a look at my prepend file, where for some reason I can’t really remember I had put this: $session->language = $user->language; I’m sure once upon a time this fixed something about Language settings getting lost in between requests or something, but apparently it doesn’t play nice with the Session Handler Database module. So after removing that line everything is back to normal, DB sessions enabled and all. I have no idea about the mechanics behind the effects I’m observing here, unfortunately, but I thought I’d throw it out there, I guess.

Yesterday I've fixed a few things mentioned earlier. Some remarks: For me it works fine. Does it happen on other sites too? Others? Yep, navItems are hacky because there is no hook to add menu items properly. To add items only to specific pages would require to rewrite the whole thing, but my biggest concern is how to make the admin for it simple. I don't remember why it's there Sure, when the time comes.

So one of my requirements is that the shell script that must access the secret content is executed on the editor's personal machine, not on the server. After scouring ProcessWire's API, I think I've stumbled upon a way to do the main thing I use smd_access_keys for: function showSecretContent() { return "<pre>Secret content</pre>"; } /** * Generate a key unique to this user and for this day only. */ $segment = sha1($user->name . $datetime->date('Y-m-d') . $this->config->userAuthSalt); /** * Add the key to the URL for this page to use in links. */ $urlkey = $page->url . '?key=' . $segment; /** * If there is a key in the URL request, save it. */ $key = $input->get('key'); /** * To authenticate the key for certified users only, save all users to an array. */ $allusers = $users->find('id>0'); /** * If the current session is logged in to ProcessWire, show the URL key and the secret content. */ if (!$user->isGuest()) { echo '<pre><a href="' . $urlkey . '">'. $urlkey . '</a>' .'</pre>'; echo '<pre>This is what you will see:</pre>'; echo showSecretContent(); } else { /** * If the page is accessed without a ProcessWire login, check if the key is set. */ if (isset($key)) { /** * If the key is set, check all the users for a user who matches the key. */ foreach ($allusers as $thatuser) { if ( $thatuser !== $users->getGuestUser() && $key == sha1( $thatuser->name . $datetime->date('Y-m-d') . $this->config->userAuthSalt ) ) { /** * If there is a user who matches the key, who isn't a "guest", show the secret content, * But only if the session isn't logged in. */ if ($user->isGuest()) echo showSecretContent(); } } } else { /** * Don't show the secret content if the session isn't logged in or when the request doesn't include a key. */ echo '<pre>Go away</pre>'; } } Compared to smd_access_keys, this script does not allow keys to include custom expiration windows or expiration after a given number of requests—a "key" expires at midnight regardless of whether it was created at 00:01 or 11:59. This script also does not save keys to a database or allow keys to be voided in the ProcessWire admin. It also doesn't offer file protection. (smd_access_keys can be used to generate keyed links to download assets that you want to limit, like if you offer a MP3 or PDF download only to someone who signs up for your newsletter.) But I didn't need those features for this implementation. Can you see any problems with this approach? Are there security issues that I have overlooked? Are there any obvious improvements I should make? Thanks for any guidance you can offer! I appreciate your comments and support.

ProcessFileEdit is fantastic and I think ProcessFileManager has a useful role as well when you need to create/delete/move files around and don't have your dev machine with you. Also, here's a sneak peak for the new File Editor Panel in Tracy (coming soon!). This comes with: Test (changes don't affect other users) and Restore functionality (in case you save and made a major mistake) for all file types and even continues to work if you accidentally introduced a fatal error into the code you just saved - this allows you to recover without needing FTP access. Of course this doesn't replace the functionality of ProcessFileManager at all, but another tool in the arsenal.

Hi y'all! Long time no see. Here's a little module aiming to help you build accessible websites ProcessWire Accessibility Tools Download: http://modules.processwire.com/modules/pwat/ Github: https://github.com/marcus-herrmann/PWAT A small, but hopefully growing toolkit for creating accessible ProcessWire sites. Right now it consists of the following little helpers: tota11y visualization toolkit by Khan Academy A toggle button to see view site in grayscale. The w3c recommends checking your page without colours to see if your design still works (accompanied by a colours contrast check, which is part of tota11y) A link to test your webpage with WAVE, webaim's Web Accessibility eValuation Tool. By the nature of this tool, the website under test must be available online, local hosts won't work. Installation Once you have downloaded PWAT, go to your module Install page and click "Check for new modules". Find "ProcessWire Accessibility Tools" and click "Install". During installation, PWAT creates a new role 'pwat_user'. To use the Accessibility Tools, you have to grant user this role. Following, you can start configuring the module. Usage PWAT starts with only the tota11y script activated. On the configuration page you can decide whether PWAT is visible on admin pages if tota11y is active if the grayscale toggle is active if the link to WAVE will be visible Credits The amazing tota11y visualization tool by Khan Academy Inspiration: Paul J. Adam's bookmarklets Inspiration: WordPress wa11y Plugin Best, marcus

I think this unnecessary, because there is not a single installer (of which I know) out there that is password protected (not PW, not WordPress, not Drupal, not NextCloud, etc.). And even if it was so, I think that most guys develop on a local machine and then upload to a live server. I know: People do stuff differently. However: Because of the upload functionality, it is a high security risk if people can upload files, without checking for permission. I think this does not matter on a local server, but on a live server it does.

Hm... thanks for that hint. I'm not sure if I like the idea of adding a password. It would break the functionality - at least I would have to put in more work. I didn't think of password protecting it, because that's the same with the regular installer (it is also visible to the public as long as the installation did not finish). The only difference at PW Kickstart is that it enables you uploading files, that's true... But still i don't think that it is necessary to password protect the directory. The goal of this installer to make the process of creating new pw websites as easy and as fast as possible and to eliminate all of the repetitive tasks that one has to do on every new pw installation. Ok I just got an idea: The downloader at baumrock.com/kickstart.php actually grabs the file from the gitlab repo and replaces the namespace ProcessWire on the first line with namespace Kickstart. This is do make sure the installer works both as an installer and as a helper for the Recipe Processmodule. I could easily add some lines of code to that service that adds the IP of the requesting client to the kickstart.php file and blocks all requests that do not come from that IP. What do you guys think?