Leaderboard

CKEditor for ProcessWire CKEditor is a web text editor like TinyMCE. This module can be used anywhere TinyMCE can be used in ProcessWire and it is generally considered one of the best web text editors out there. TinyMCE and CKEditor have always been the two big leaders of web text editors, and they've been equals for many years. Though lately it seems like CKEditor might be a little ahead of TinyMCE in some areas, so I thought we should give people the option of using CKEditor with ProcessWire. CKEditor has a nice inline mode that is desirable in the page editor when you may have lots of rich text inputs. The reason for this is that the page editor loads a lot faster. If you have this need, this would be one reason why you might want to use CKEditor over TinyMCE. Some also prefer CKEditor for other reasons. For instance, @apeisa prefers the table controls in CKEditor to TinyMCE's. Here are a few notes about this module: You already know CKEditor–it's what this forum is using. Though the version included with ProcessWire's module is significantly newer. It is currently beta test. You are advised to test thoroughly before using it in production. You may very well run into bugs, in which case please let me know so that I can fix. It is tested and confirmed compatible with both repeaters and multi-language support. It is now fully hooked into our link and image systems, like TinyMCE. Thanks to Antti for helping with the image plugin. If you want to use the inline mode, you'll need to install the HTML Purifier module first. The toolbar is fully configurable. It is multi-language ready and all text in the module is translatable. Like with TinyMCE, the module optionally supports definition of custom plugins and content.css file. How to install Copy all the files from this module into: /site/modules/InputfieldCKEditor/ Login to your admin and go to Modules > Check for new modules. Click install for InputfieldCKEditor. Now go to Setup > Fields and locate a textarea field that you want to use CKEditor (or create a new textarea field). When editing the settings for a textarea field, click the Details tab. Change the Inputfield Type to CKEditor and save. While still editing the field settings, click to the Input tab for CKEditor-specific settings you may optionally configure. Download ProcessWire Modules page: http://modules.processwire.com/modules/inputfield-ckeditor/ GitHub Repo: https://github.com/ryancramerdesign/InputfieldCKEditor Screenshots Screenshot of regular mode: Screenshot of inline mode, combined with multi-language fields:

Hi, After reading this thread, I decided to make a module that helps generating PDF files of ProcessWire pages. GitHub: https://github.com/wanze/Pages2Pdf Modules Directory: http://modules.processwire.com/modules/pages2-pdf/ This module uses the mPDF library to generate the PDF files. It has fully UTF-8 and basic HTML/CSS support for rendering the PDF files. The output is customizable with ProcessWire templates. Example I've enabled generating PDF files for the skyscraper template of ryans Skyscrapers-profile with a template that outputs the data in a table along with the body text and the images: one-atlantic-center-pdf-4177.pdf Please take a look at the README on GitHub for instructions and further information/examples. Cheers

http://urbanmotionbeats.info About the site Urbanmotionbeats is a party website featuring facts about events, galleries and a list of DJs. The main goal was to create a site, where they can upload their photos after a party. Processwire was perfect for this: We could make a template with all details about an event, add the image field and were ready to go. Features Processwire with ProCache enabled together with Lazyloaded images for a good page speed Event template with gallery and several text fields Homepage with random images, latest events and some text. Integration of the Facebook Comments and like boxes Responsive/Adaptive Design, because a lot of people will using this from their smartphone Problems We mostly had client problems. How to use the admin backend. Where are the limits of the Backend? How can I do X? Why does Safari on Windows not work with Drag'n'Drop? I've never though about, what would happen if someone uploads 300 pictures from a DSLR with 20MB each (Script Timeout). We've fixed most problems but also learned alot. Overall you can say, Processwire performed well. If our not so tech-savy clients would have to use another more bloated Backend they would be totally helpless. What's next? This site is only the first in a row. Other event "brands" from them will follow with a slightly modified design. We've written a JSON output so we can later combine all events from all sites (4 are planned) together in a portfolio site with a more business focused audience.

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

hi there! after playing a bit with pw, i decided to choose my own new website as a first project to test it. im realy happy with it and i will use it as my number 1 choice for my own clients in the future. the first time working with an cms i've got not the feeling that i need to "fight" against it. i was realy suprised how easy it is to use ajax with pw, which i did for my references page, i'm still looking for an easy to implement url/hashbang ajax-solution - this is something i will add in the future to the site. a little blog will follow:) http://chrisvaupel.de constructive critics are welcome PS: it's a small site, but i bought procache and formbuilder, becouse i was curious and wanted to give a little bit of money support - anyway, i just like to say that booth are working realy well

Well the imageType and filename property is protected in the imageSizer class. That's why.

ZipArchive does seem to be pretty widely adopted now. It wasn't when that existing ZIP code was originally written. I've been meaning to change it over to ZipArchive, but just haven't gotten around to it. It's on my to-do list.

I did had good play with this earlier this weekend - compared to tinyMce - it is just much nicer to use. Less fighting with positioning (text and tables, images inside text etc), less mysterious "if I hit backspace now, I don't have a clue what will happen" -moments and it just looks and feels nicer. Great work Ryan! Glad I could help a little. Also: The inline mode beats the Aloha hands down in my opinion. Of course not much use in backend (unless you need RTE inside repeaters or have lot's of multilang fields) - but if you build front end editing to your sites - don't forget this beauty.

In case you didn't know or had forgotten, in PW you can edit /site/config.php and set $config->debug = true; to help track down errors. I've often found 'soft errors' (bad practice PHP etc (something you get if you are PHP 'lite' like I am)) that were previously hidden are displayed when this is set to true. But I also found I set it and forget that it's set then sometimes see a page load slightly slowly or with a visible 'flash' and wonder what's wrong, only later remembering I have debug left on. So now as a reminder I echo (if the setting is true) a reminder somewhere obvious such as adjacent to the homepage (or every pages's) H1. It's good to be reminded since going to a production site with it set to true is NOT recommended (API doc). This is the simple test and echo I now add: if(wire('config')->debug) echo "<span class='alert'>Flashy? Slow? Probably because of \$config->debug = true;</span>";

I have just done one quick test with the new FieldtypeCropImage.module file - and it went fine. Create field - chose cropimage and add title - save. Went to input - removed existing thumbnail setting, added two new ones and selected Display Thumbnail. Save Added to template. Opened existing page, added image. OK Went back to field, added another thumbnail setting, Save Reloaded page edit - OK Went back to field, changed max images to 1 and set image upload sizes - save. Reloaded page edit - OK Closed pages and reopened - still OK. So, with any luck that has solved the issue!

@apeisa, I'm having same problem here that Joss reported. After creating the field it's settings don't initially get saved to fields table (which is probably how it's supposed to work -- I'm not exactly familiar with fields and can't say for sure), thus the need for that workaround Joss mentioned (saving it twice.) In my case it still seems to fix the problem, though, and I've been testing this in both 2.2.15 and 2.2.17. Anyway, I was a bit curious why this workaround is even required. Your inputfield does offer default setting after all, and that shouldn't require any settings being found from the database. After browsing through some code (not nearly well enough, there's plenty of stuff there..) I think I may have found a problem: There's a method called "_getInputFieldInstance", but it actually returns a field. "There's no thumb..." exception is thrown because default settings are always null, which in turn is caused by the fact that you were asking them from field, not inputfield. Following change did seem to fix this situation, at least based on very limited testing: --- a/FieldtypeCropImage.module +++ b/FieldtypeCropImage.module @@ -132,7 +132,7 @@ class FieldtypeCropImage extends FieldtypeImage { // if the image's pagefiles property matches the one with the // field we're looking at, we have a match. save in $field if($image->pagefiles === $pagefiles) { - $field = $imageField; + $field = $imageField->getInputfield($page); break; } } It's getting awfully late and my head is blurry, so I might have to take a better look at this later. Just posting it here in case that I can't remember anything about this tomorrow morning..

Just pushed version 1.0.0 (yay!) to GitHub. No huge improvements involved this time either, just some minor additions, comments, overall consistency checks etc.. and of course support for fantastic new CKEditor inputfield Ryan is working on One notable thing is that now tables created during install actually have proper (?) indexes included. If you've installed this module earlier and want to add these without uninstalling this module first, it's quite simple to do via MySQL client (I'm not familiar enough with PHPMyAdmin to say for sure, but this is probably easy to do there too): CREATE INDEX fields_id ON version_control_for_text_fields (fields_id); CREATE INDEX version_control_for_text_fields_id ON version_control_for_text_fields__data (version_control_for_text_fields_id); Don't worry too much if this seems difficult; these won't make any difference before you've got at least ~50k rows of history data (and even then the difference is minimal.) They should make things a bit faster especially if your site is very large, constantly updated and/or you want to keep history data "forever."

Looks like it's there 2 times. AND you don't install modules in core /wire/modules/ but in /site/modules/ because when you update you replace wire folder.

I missed the XML sitemap generator that I used in a previous CMS so I built my own module to achieve the same functionality. This module outputs an XML sitemap of your site that is readable by Google Webmaster Tools etc. I've generally found that it reduces the time it takes for new sites and pages to be listed in search engines using one in combination with Webmaster Tools etc (since you're specifically telling the service that a new site/new pages exist) so thought I may as well create a module for it. The module ignores any hidden pages and their children, assuming that since you don't want these to be visible on the site then you don't want them to be found via search engines either. It also adds a field called sitemap_ignore that you can add to your templates and exclude specific pages on a per-page basis. Again, this assumes that you wish to ignore that page's children as well. The sitemap is accessible at yoursite.com/sitemap.xml - the module checks to see whether this URL has been called and outputs the sitemap, then does a hard exit before PW gets a chance to output a 404 page. If there's a more elegant way of doing this I'll happily change the code to suit. Feedback and suggestions welcome On a slightly different note, I wanted to call the file XMLSitemap originally so as to be clearer about what it does in the filename, but if you have a module that begins with more than one uppercase letter then a warning containing only the module name is displayed on the Modules page, so I changed it to Sitemap instead which is fine as the description still says what it does. File can be downloaded via GitHub here: https://github.com/N.../zipball/master

Hi all, hopefully this is an easy fix. It seems the default behaviour for PW is to cache only the first language of a page as it is accessed. So you get a file like 1234.cache. I tried search around the forums here and found some mention of "secondaryID" and that it could be used to allow alternates of cached pages? (correct me if that wrong). Either way I was hoping to alter the cache file naming so that I could end up with something like this (or similar) 1234.default.cache 1234.fr.cache 1234.cn.cache Thanks!

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

I found (after 2-3 Projects using PW) that it's a good technique to use templates in a way I think hasn't been thought of yet really by some. (Although the CMS we use at work for year, works this way.) I'm sure I'm maybe wrong and someone else is already doing something similar. But I wanted to share this for everybody, just to show alternative way of using the brillant system that PW is. Delegate Template approach I tend to do a setup like this: - I create a main.php with the main html markup, no includes. So the whole html structure is there. - I then create page templates in PW without a file associated. I just name them let's say: basic-page, blog-entry, news-entry... but there's no basic-page.php actually. - Then after creating the template I make it use the "main" as alternative under "Advanced" settings tab. So it's using the main.php as the template file. - This allows to use all templates having the same php master template "main.php" - Then I create a folder and call it something like "/site/templates/view/", in which I create the inc files for the different template types. So there would be a basic-page.inc, blog-entry.inc ... - Then in the main.php template file I use following code to delegate what .inc should be included depending on the name of the template the page requested has. Using the TemplateFile functions you can use the render method, and assign variables to give to the inc explicitly, or you could also use just regular php include() technic. <?php /* * template views depending on template name * using TemplateFile method of PW */ // delegate render view template file // all page templates use "main.php" as alternative template file if( $page->template ) { $t = new TemplateFile($config->paths->templates . "view/{$page->template}.inc"); //$t->set("arr1", $somevar); echo $t->render(); } <?php /* * template views depending on template name * using regular php include */ if( $page->template ) { include($config->paths->templates . "view/{$page->template}.inc"); } I chosen this approach mainly because I hate splitting up the "main" template with head.inc and foot.inc etc. although I was also using this quite a lot, I like the delegate approach better. Having only one main.php which contains the complete html structure makes it easier for me to see/control whats going on. Hope this will be useful to someone. Cheers

Renobird built this lovely calendar here. Is there a way to do this just using a date field? Is it possible to extract just the month from a date for example and foreach it?

I'm on mobile and it looks very good! Congratulations.

Looks very sharp, Chris congrats! Is the page at http://chrisvaupel.de/leistungen/ constructed as a list of other pages? Cheers, Rick

you are right - i'll change it tommorow (and btw, i will change the order of the two footer columns for the mobile-view)

Really nice, but I would add a bit more padding top and bottom to the footer.

And I found that out without debugger... :-P

Is there a way to fake that? Effectively run a crawler over the entire site based on a generated map or something? I don't see this as high priority, but interesting all the same!

Thanks Teppo, I will add this for sure.

Yep,, that did it!

Another option, if what you want to do is simply a static copy of your whole site, is to use something like HTTrack: It's available as a Windows and Linux version + command line tool and (based on my experience so far) most of the time does good job. Windows version can sometimes require a bit of playing around with settings, but other than that it's simple, powerful, very configurable and completely automatic

Be sure to grab the latest, as I updated many things this morning. I haven't noticed this level of difference yet between TinyMCE and CKEditor. But if this becomes a common feeling among ProcessWire users, then we could always switch out the core default from TinyMCE to CKEditor. Though I would like to maintain them both either way. I noticed CKEditor doesn't seem happy to paste text without inserting a bunch of style attributes into it... which is annoying. But I'm sure there's a way to configure that out of there, just haven't figured out how yet. The current dev version of CKEditor does support allowed content rules in a manner similar to TinyMCE, but the stable version [that we are using] apparently does not (?).

Thanks Teppo, makes sense to me. I have locally tested this and one earlier pull request (string translations support by boundaryfunctions). All seems to be working fine so I committed them to github. Very happy if you guys can test that everything works as expected.

Lovely Maybe just use a custom instagram hashtag which will be displayed

Yeah, you're right - it would be a little complex as an inputfield. This may help for the photographers then: http://www.dropresize.com/ Basically they can create a folder on their desktop, tell this program to monitor it and set some settings and then they simply copy images into it and they automatically get resized. Would need some documentation though (the guy's site vanished with some dodgy host and hasn't been rebuilt yet, but it's not too complex to figure out from the app alone) but it would certainly make things much easier for the photographers

Just gave it another try and the fix I've mentioned above seems to be working properly. I'm including an in-depth explanation below, just in case you might want to see if there's a flaw in my thought process. I'm also using this module to learn about how fields, fieldtypes and inputfields actually work, so please bear with me.. When a field has already been saved (after initial creation, that is) all inputfield settings have been saved to fields table and thus field knows them too. This is why at this point you can ask "thumbSetting" from field and everything works smoothly. As far as I can tell, inputfield doesn't strictly speaking even have settings of it's own -- it uses settings of the field it's attached to. Or perhaps it's better to say that they share the same settings at this point? Someone please correct me if I'm on the wrong tracks here. Edit: now I'm really getting sidetracked, but if what I'm saying above is true, what would happen if fieldtype and inputfield had a setting with same name? Wouldn't that cause a conflict of some kind, ie. only one of them could save it's settings properly? What am I missing here? A newly created field doesn't yet have any inputfield-specific settings stored, since at the time of creation it won't yet know which inputfield is going to be used and thus cannot guess what it's default settings might be. That's why you'd definitely want to fetch default value directly from inputfield, not the field. Inputfield is the one with default values included at code level after all. This is something I've been unable to reproduce without relying on odd tricks. Essentially this sounds like your field had an image but still it's settings remained empty, which shouldn't really be possible. One way this could happen is if you create an image field, upload image to it and then change field type to CropImage without saving it twice. This seems to leave field settings at database blank and that way cause an exception once you open page edit -- CropImage inputfield tries to render thumbnails for thumbnail list you see below images but doesn't have proper settings and fails with an exception. When this exception happens at image upload phase, it just stops the upload process, but when it happens at this point it stops whole page from being rendered. Interesting stuff Anyway, it would be nice to see what's inside your fields database table for this field (name = "your_field_name"). That might give us a clue why this is happening, or at least if it's caused by what I presume it might be.

I've seen this happen before, just didn't have the time to see what's causing it then. Now that I did, it seems pretty obvious: JS related to title field only expects keyup, which isn't triggered when you choose a value from autofill list. Making following change would fix this, though I wouldn't necessarily suggest that you make this change locally -- it would make it slightly more difficult to update ProcessWire later. Posting it here just to point out what the problem is/was. --- a/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js +++ b/wire/modules/Inputfield/InputfieldPageTitle/InputfieldPageTitle.js @@ -25,7 +25,7 @@ $(document).ready(function() { $nameField.val(val).trigger('blur'); } - $titleField.keyup(titleKeyup); + $titleField.bind('keyup change', titleKeyup); $nameField.focus(function() { // if they happen to change the name field on their own, then disable I've also just opened an issue for this at GitHub, let's see what Ryan says

Hey Ryan, thanks for your kind reply. I'll expand a bit on what the slot picker is supposed to do, and I'll attach a sketch, for a lack of screenshootable material. I am archiving the CDs for 3 people - Paul, Simon and Greg. Each of these has a number of archive boxes for CDs - Simon, for example, has 3. Each of the boxes has a capacity of 80 CDs. In Simon's Box Nr. 1, there's plenty of space left, as only slots 1, 2, 5 and 8 are populated. The CD currently being edited in the sketch sits in slot 5. Clicking any one of the free slots in the tabbed grid will set the CD's "archive box" and "slot number" properties (or maybe I'll ditch "archive box" property and just count slot 82 as slot 2 of box 2) accordingly and update the text to the right of the grid. Clicking any of the inactive tabs, for Boxes 2 or 3, will update the grid according to the data about occupied slots in these boxes and so give the opportunity to locate the currently edited CD there. Clicking on "Add a box" or "Remove a box" does as the label says. Clicking "Remove a box" in the depicted scenario brings up a warning: "Really remove a box? You will need to re-slot all CDs from the box you remove. To proceed, chose the box to remove, or click on cancel." Clicking on Paul or Greg in the Owner field instantly updates the Archive Slot field with the respective owner's data, because each owner has his own boxes, and chosing a different owner for the CD will mean putting it into another box. So in general, the slot picker reads properties from a set of CDs (the ones of the currently chosen owner and his currently chosen box, determined via the slot picker's tabs) and builds an array of the slots occupied by these CDs. It builds a link for each non-occupied slot that will, when clicked, set some properties of the currently edited CD, and makes the remaining slots unclickable. I'd like to have the possibility to set the system up in a way that permits boxes with more or less slots than 80 - this would, I think, force a split of the archive number property into archive box and slot number. But if this brings in more difficulty than I can handle at the moment, I can do without other-than-80-slot-boxes. Thanks for having a look!

So sorry guys, link is fixed.

Thanks guys, you are too kind. That calendar was done with Textpattern, but I built a proof-of-concept of essentially the same thing using Processwire. Ryan gave me some huge clues on using JSON. I'll post it when I'm back at the office next week.

I have planning to update the language pack for ages. I do it next week when I get back to office. It would be great to get some contributors. I have avoiding translating the parts that are only for superusers, but using PW that has languages mixed is kind of frustrating. So I think we should aim for 100% coverage. Also, I am open on how to translate certain terms, like template (currently: "sivutyyppi"), name (currently: "sivun nimi osoitepalkissa") etc.. Trying to balance with what is "correct" and what is easy to understand for non-technical person.

That is prettiest and probably most easy to use/browse calendar in long time. Reno is my designer hero for sure!

Even after two years of PW-development I seem to make things much more complicated than they are (same goes for you Petey-boy ). Thanks Ryan!

Ryan dont you think users unpublished should have strikeethrought?

I get you Joss. My thoughts were directed at the OP where everfreecreative was saying it would be good for the less PHP literate. I think it would be very useful for the PHP pros as a time saving tool. Any novice such as myself, who wants to learn, not so much. To me it's sort of like allowing calculators in schools. Once you know how to do mathematics in your head or on paper then a calculator is a handy time saving device but if you use it in place of those skills you'll likely never learn them. Why do long division on paper when a few button pushes on a calculator gets you the answer. Still a good idea for those that want to use it, no judgement on my part, I'm just pointing out that if you want to learn, it may not help you do that.

This is seriously useful! I was thinking about using WYSIHTML Bootstrap thingy on front end forms - this should be a perfect addition!

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

Here's a link to the CKEditor module work-in-progress if you want to try it out. I'm not yet using it in production, but it seems to work well locally on the sites I'm developing. https://github.com/ryancramerdesign/InputfieldCKEditor

The possibilities are endless in Pw to achieve what you want. Some Possibilities: Don't use $page->title but $page->id instead - this id is unique even if you change the title Better: Give the pages you need the additional js the same template => this way you only have to check for the template Add a checkbox field to the template(s) of pages that need the additional stuff and check if this is set If you really, really need to access the templates url from inside a textarea, you could do something like this: //in Textarea blu blu blu {{templates}} blub blub blub //In template $blub = str_replace('{{templates}}', $config->urls->templates, $page->blub); @pwired What? In Pw your fields ARE the template variables, just more flexible. Who stops you from adding html/css/js into a textarea field in ProcessWire?

Hi, when you are on your own local machine and want to 'upload' a file and wants to get it unzipped, you should provide the path to an unzip-app and all needed params / flags for it. (A commandline app!) If you don't have one, you may go and fetch 7z. It comes with an additional commandline prog called '7za.exe' Put it somewhere into your systempath, open a shell command (cmd.exe) and type in 7za -h or 7za --help to get a list of available commands and switches. If you have figured out the needed command and switch/es, write this into your PW-site config.php, instead of the unix there. I use 7za.exe sometimes with PHP-CLI on my local machine, - but only to zip archives. I never have used it to unzip via cli.

Hi everyone, Event Mentor is now running on ProcessWire and ProCache (it previously on Hero Framework). It's also linked up with DigitalDeliveryApp to handle payments and digital downloads. Site design by monodesign. Cheers Marty

Hi, kawaramono.cz is little presentation web for my friend made with PW. Pretty simple solution with full content administration, zurb foundation framework and colorbox.

WillyC isn't quite correct there, if I understand what he's trying to say. page-edit is the minimum permission required to to do edit-related activities on the page. Sorting a page's children is considered an edit-related activity. Why? Because it's feasible a user might have edit access to some siblings and not others, so it's a bit of an access control problem for edit access to one page to affect placement of pages a user doesn't have edit access to. So I don't know of a way to get around that without installing other modules. But for the most part, if you've got limited access editors, your sorting mechanisms are ideally predefined so that they don't have to do that. But I will put on my to-do list, to think of other solutions for that particular case. Though I think where we are is probably about right from a security standpoint. For now there are a couple of ways you could accomplish this with modules. One way would be to install the Page Edit Field Permission module. Have it create permissions for all the fields you want to limit access to on the parent. Then create a new role in addition to your existing editor role. Call it "editor-parent" or something like that. Give that role page-edit and page-sort permissions, nothing more. Edit the template used by the parent page, and check the box to give it edit access to the parent with the sortable children. Give your editor users that role as well. Your editors will be able to sort the children and edit the parent, but only the fields you designate (which you might decide to be, none). Another alternative is to add a custom module to take care of it for you. This one essentially changes the behavior of ProcessWire so that if you have access to edit a page, and you have page-sort permission, you also have access to sort it among siblings (written in browser, not tested). class PageSortableCustom extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Page Sortable Custom', 'version' => 1, 'summary' => 'Let a user sort siblings they have access to edit.', 'autoload' => true, ); } public function init() { $this->addHookAfter('Page::sortable', $this, 'hookPageSortable'); } public function hookPageSortable(HookEvent $event) { if($event->return) return; // already sortable, so exit $page = $event->object; if($page->id == 1 || !$page->editable()) return; if($this->user->hasPermission('page-sort', $page)) $event->return = true; } }

This is actually fixed in the dev branch. You could switch to the dev branch, or you could copy the relevant file out of it (/wire/modules/PageRender.module) and replace the one you have. Here is the commit highlighting the changes: https://github.com/ryancramerdesign/ProcessWire/commit/6c6f27ea0f0df4653ac241f5c8b54d44e1c36494