Leaderboard

Update 09.05.2014: new version of minimize.pw released. I've updated this post and you can read more here. ProcessImageMinimize A service and module to make images lightweight: minimize.pw Our new commercial service for ProcessWire: minimize.pw With minimize.pw, you can shrink your images (JPG and PNG) without noticeable visible differences up to 80%. This makes pages load faster and helps you to work with people not familiar with command line image compression. You can try it for free. Learn more Download the module Github Page Module features Hooks into any Pageimage with ->minimize() (short ->mz() ) Automatic compression with a 1-click-setup (new) Overwrites original files or keeps both versions (new) Image compression with minimize.pw Fail-safe mode so that your visitors won't notice any problems if we're offline or you have no volume left. Usage with templates First, download and install the module. You have to enter a license key. Get a free license key hereTo embed a minimized image into your web page, simply call the method mz() or minimize() on your Pageimage-object. Please note, that is has to be a single Pageimage. We also support apeisa Thumbnails module. $img = $page->image; $img->minimize(); Or put in context $img = $page->image; echo "<img alt='A minimized image' src='{$img->minimize()->url}'>"; You can also use it combined with other Pageimage methods: $image->size(300,400)->mz()->url; Read more at Github Pricing While the module is free, our service is fee-based. We have to pay for servers and traffic With this version we've dropped our year-based pricing structure and introduce a new volume-based pricing. Everyone gets 2000 images for free and you can buy additional volume anytime. Free: 1000 images once 5000 images / 19€ 15000 images / 39€ 50000 images / 89€ Buying more volume will also drop the site limit of three. Questions Feel free to ask any question you might have.

yep, context RTE. Reason, make those linebreak visible, so content editors are aware of those breaks. Lot's of time, the writers use line-breaks when they shouldn't, or don't know that they are using those. So that red, green & gray is done with CSS pseudo elements. Here you can see that the header also includes a strong tag, I don't like that so, there's the visual feedback. Ps, I did solve it, but don't like as I press solved, it tells me: Best Answer

I have to say it's been fun working with this module. And at the same time quite weird as I'm not used to writing open source code during the daytime. Still some work left until it's truly ready for production use but it looks like we're getting there. Just keep on pushing those green buttons, we'll handle the rest!

Somehow content editors love the <br> tag. On a 'random' base, the're putting in a line break. The cases of double <br> is easy to solve, but the single ones are just a pain in the *ss, as they could be intended. Think 80% of the <br /> makes me <grrrr />. For other elements I can use some pseudo elements to foo-doo visualize when they are used. For br thats not possible without some javascript I think. I even think: Disallow br tags at all.<br> How do you guys solve this.? Putting this in the the CSS, will visualize the BR. p br { content: "*"; display: block; margin-bottom: 0; line-height: 1; } p br:after { content: "<br>"; display: inline; background: red; color: #FFF; font-size: 12px; border-radius: 2px; margin-right: 2px; padding: 0 4px; float: left; }

Ryan - just wondering if you are planning on theme-ing the installation routine to match the new default admin theme before 2.4 is released? I think it's important for maintaining a cohesive look for PW.

I've pushed some updates to the CKEditor Inputfield fixing some bugs and updating to the latest version of CKEditor (4.3.2). I recommend upgrading if you are already using a past version. I've also added a couple of detailed tutorials to the README file including: How to make your own custom styles menu How to customize the appearance of the editor While you are upgrading, be sure to grab the latest version of the HTML Purifier module as well.

I realise that Marty and many others fully understand the issues here, but for anyone else with similar problems, here it is in a nutshell... PW selectors use mySQL fulltext indexes (indices? I'm never sure) mostly, as they are very fast. However Fulltext indexes miss out some common words (stopwords) because they are too common to influence search results meaningfully for the most part. And Fulltext indexes ignore words shorter than 4 letters, unless you have enough control of the server to change that default behaviour. (Think VPS or better.) However PW's %= selector operator uses mySQL's LIKE operator, which while slower than a fulltext search, is still very fast (certainly on fewer than several thousand records) and isn't restricted by stopword lists or word length.

If you go to Admin>Setup>Fields and then edit the field with the tinymce Inpufield Type, there is a tab called "Input". On there you have the TinyMCE advanced configuration options. In the valid elements part replace "-p" with "#p". This will allow empty p tags. This should also pad the empty paragraph with a non-breaking space but for some reason TinyMCE seems to replace them with a regular whitespace. some more info here: http://processwire.com/talk/topic/4204-stop-tinymce-from-removing-entities/ and here http://www.tinymce.com/wiki.php/configuration:valid_elements

PW has very flexible UA management. Most of the sites can get the exact needs fulfilled after little clicking. But when you need to scale it in horizontal way: ie. adding ten different news sections, each with same templates but managed by different group of people, PW doesn't make it too easy (since UA is tied to templates). Also roles&permissions&template access is a combination, that at least we cannot leave to our clients (it's way too complicated for your average editor) - it means that UA management have to be done by us. This is fine on small scale, but some of our sites are pretty heavy on UA: biggest site has over 800 user groups and many times we do have something like 50 000 users importet (these sites are not build on pw today, but hopefully they will be). So we need to have simpler UA that our clients understands and can use on daily basis. That will also mean less granular control, but easier to manage. Lucky for us, PW has hook system in place, that is flexible enough to allow hooking to UA also. Few months ago I started building module to add two features for PW: -user groups (user can belong to more than one group) -page based permissions based on groups (so you can say: this page and it's children can be edited by groups A + B and viewed by groups A + B + C I first thought that I should release this as a paid module, but after showing this current early version to Nik and Teppo (I knew they had similar needs) and when they showed interest in development I wanted to make this a community project (this is gonna be thousand times better than just me building it alone). So lot's of progress is coming and of course everyone is invited to collaborate. Be it ideas, comments, testing, use cases etc.

Take a look at ProcessHello, there you have a good boilerplate.

Well, I'm no pro at this and you could probably improve it, but here's my attempt which serves my current needs pretty well: /** * Creates a repeater field with associated fieldgroup, template, and page * * @param string $repeaterName The name of your repeater field * @param string $repeaterFields List of field names to add to the repeater, separated by spaces * @param string $repeaterLabel The label for your repeater * @param string $repeaterTags Tags for the repeater field * @return Returns the new Repeater field * */ public function createRepeater($repeaterName,$repeaterFields,$repeaterLabel,$repeaterTags) { $fieldsArray = explode(' ',$repeaterFields); $f = new Field(); $f->type = $this->modules->get("FieldtypeRepeater"); $f->name = $repeaterName; $f->label = $repeaterLabel; $f->tags = $repeaterTags; $f->repeaterReadyItems = 3; //Create fieldgroup $repeaterFg = new Fieldgroup(); $repeaterFg->name = "repeater_$repeaterName"; //Add fields to fieldgroup foreach($fieldsArray as $field) { $repeaterFg->append($this->fields->get($field)); } $repeaterFg->save(); //Create template $repeaterT = new Template(); $repeaterT->name = "repeater_$repeaterName"; $repeaterT->flags = 8; $repeaterT->noChildren = 1; $repeaterT->noParents = 1; $repeaterT->noGlobal = 1; $repeaterT->slashUrls = 1; $repeaterT->fieldgroup = $repeaterFg; $repeaterT->save(); //Setup page for the repeater - Very important $repeaterPage = "for-field-{$f->id}"; $f->parent_id = $this->pages->get("name=$repeaterPage")->id; $f->template_id = $repeaterT->id; $f->repeaterReadyItems = 3; //Now, add the fields directly to the repeater field foreach($fieldsArray as $field) { $f->repeaterFields = $this->fields->get($field); } $f->save(); return $f; } And here's an example of calling it: $f = $this->createRepeater("sc_promos","sc_promo_active sc_promo_code sc_promo_discount","Promotional Offer","shoppingCart"); You can then use $f to add your new repeater field to a fieldgroup/template.

YESYESYESYESYES!!!! That was it! I thought that that particular bit of code wasn't necessary because I only wanted to create the repeater and not any associated pages. I'm not sure why it works but it does Yes, I've had to go in and manually hack the database due to errors along the way, but all is working well, so I don't think I've messed up anything too bad I do have to say... this is way complicated for ProcessWire since most things in PW tend to be surprisingly easy. But I don't think Ryan foresaw repeaters being created this way. I'm sure this is something that could be simplified in the future.

Good find - I had forgotten about that post I just used the code from that other post of mine on a fresh PW install (latest dev, although I think it should work on 2.3 stable as well) and it works perfectly. I know that when I was playing around with writing that code I often messed up the PW database to the point where I was getting errors and found the best way was to do a fresh install again. BUT, I just noticed that you are missing these key lines in your version: $repeater_page = "for-field-{$f->id}"; $f->parent_id = $this->pages->get("name=$repeater_page")->id; $f->template_id = $repeater_template->id; $f->repeaterReadyItems = 3; This is critical to make things work. Let me know how you go.

Looking at it from an 'awareness' angle i actually really like the way you've done it. Education wile you make and edit content.

I think the issue here is that the Admin Custom Page module is not aware of the new admin theme being in a module, so your custom admin pages still retain the non-module theme. We'll have to take a look at the code and see if there's a way to make some adjustments to how the module loads the theme.

*LOVE* Modules Manager Notification. Thank you Soma

PW is looking at the request URL. Since your request URL is /5gum/, PW thinks that's the starting point. You may need to set $config->urls->root manually to /admin/. This bit of code is probably not so safe: $brand_slug = basename ($_SERVER['REQUEST_URI']); // this would get me "5gum" $brand = wire('pages')->get("name=".$brand_slug); // this gives me a specific page I'd suggest changing it to: // sanitize brand slug with the pageName function $brand_slug = wire('sanitizer')->pageName(basename($_SERVER['REQUEST_URI'])); // this would get me "5gum" $brand = wire('pages')->get("name=$brand_slug"); // this gives me a specific page // double check that brand is what you expect and that it's viewable if(!$brand->id || $brand->template != 'brand' || !$brand->viewable()) throw new Wire404Exception();

I figured this also. There seems to be a difference. Set filename then render and render then specify template file. Calling with render with that option seems to try see if its viewable and It's not. Thus the error... there's not file.. and attaching your template would come after that. Only my guess without study code.

some (translatable) strings in modules to fix (PW dev 2.3.13) \wire\modules\Inputfield\InputfieldPageName\InputfieldPageName.module line 206-210 $field->label = __("Character replacements"); $field->description = __("Enter the replacements that will occur when a user is entering characters into a page name field. ") . __("Enter one replacement per line in key=value format. ") . __("Meaning, on each new line, enter the character(s) you want to replace followed by an equals sign '=' and the ascii character(s) you want to replace with."); line 212 $field->notes = __("The replacement value for each must be one or more of: a-z, 0-9, dash, underscore or period."); \wire\modules\Fieldtype\FieldtypePage.module line 739-740 $inputfield->label = __('Find and clean orphaned page references'); $inputfield->description = __('This cleans up for an issue in older versions of ProcessWire that could leave orphaned page references for deleted pages. If you are getting inaccurate results from page finding operations (especially with selectors using pageref.count), then you may want to run this.'); line 743 $inputfield->notes = __('Warning: To be safe you should back-up your database before running this.'); \wire\modules\PageRender.module line 391-392 $f->label = __("Clear the Page Render Disk Cache?"); $f->description = __("There are currently $numPages pages cached in $path"); EDIT: \wire\modules\PageRender.module line 392 is not translatable? Changing text in the translation doesn't show the new translated phrase in the module setting. It stays english. \wire\modules\Process\ProcessPageSearch\ProcessPageSearch.module starting at line 838 - 863 $inputfield->label = __("Default fields to search"); $description = __("Enter the names for one or more text-based fields that you want to search, separating each by a space. "); $inputfield->description = $description; $inputfields->append($inputfield); $inputfield = Wire::getFuel('modules')->get("InputfieldText"); $inputfield->attr('name', 'searchFields2'); if(!isset($data['searchFields2'])) $data['searchFields2'] = 'title'; if(is_array($data['searchFields2'])) $data['searchFields2'] = implode(' ', $data['searchFields2']); $inputfield->attr('value', $data['searchFields2']); $inputfield->label = __("Field(s) to search in admin search (ajax) mode"); $inputfield->description = $description; $inputfield->notes = __("We recommend limiting this to 1 or 2 fields at the most since results populate a live autocomplete field. Typically you would just search the 'title'."); $inputfields->append($inputfield); $inputfield = Wire::getFuel('modules')->get("InputfieldText"); $inputfield->attr('name', 'displayField'); $inputfield->attr('value', isset($data['displayField']) ? $data['displayField'] : 'name'); $inputfield->label = __("Default field name(s) to display in search results"); $inputfield->description = __("If specifying more than one field, separate each with a space."); $inputfields->append($inputfield); $inputfield = Wire::getFuel('modules')->get("InputfieldSelect"); $inputfield->attr('name', 'operator'); $inputfield->attr('value', isset($data['operator']) ? $data['operator'] : self::defaultOperator); $inputfield->label = __("Default search operator");

Joss, it's pretty much like that. Also the topic of the discussion is you. On a sidenote, Nik and Teppo are on fire with the module. My job seems to be pressing those green merge buttons on github. I like it this way

ok, for my case it was possible to fix it by adding the categoryData array manually to the modules json via mysql. something like [{\"emailAddress\":\"my@me.com\",\"emailCategory\":\"1013\",\"emailTemplate\":\"46\"}]

First, Welcome to ProcessWire! Hopefully that works for you. Ryan's Blog profile has taught me a lot about ProcessWire.

You can go to Settings on the page you are editing and there is a "Created by User" field that you can change to the user you want to be the author.

I certainly don't see anything wrong with your approach, but if you set up a settings page in the admin and added a "signature_image" field to it, it would be easier for you / your clients to change this image in the future. Then you could simply echo the image in the same place using: $pages->get("/settings/")->signature_image->url();

Hi all, after some time i am back and here is new version of this language packs. Version 1.0 is targeted for ProcessWire 2.4 so now is good time to make some release candidates and finish this ugly work . Any help will be appreciated. Czech Localization Pack. Current version: 0.9.9 (100 files) + README.txt Changelog: Updated strings and files to match latest git version (ProcessWire 2.3.13). Added: wire/core/AdminTheme.php wire/core/Pages.php wire/modules/LanguageSupport/LanguageTabs.module wire/modules/Fieldtype/FieldtypeURL.module wire/modules/Fieldtype/FieldtypeModule.module wire/modules/AdminTheme/AdminThemeDefault/AdminThemeDefault.module wire/modules/AdminTheme/AdminThemeDefault/functions.php wire/modules/AdminTheme/AdminThemeDefault/debug.inc wire/modules/AdminTheme/AdminThemeDefault/default.php Deleted: wire--templates-admin--debug-inc.json wire--templates-admin--default-php.json Czech Localization Pack for external modules. Current version: 0.4 (18 files) + README.txt Added: ModulesManager site/modules/ModulesManager/ModulesManagerNotification.module site/modules/ModulesManager/ModulesManager.module ProcessPageDelete site/modules/ProcessPageDelete/ProcessPageDelete.moduleDeleted: templates-admin (is part of core modules now) site--templates-admin--default-php.json site--templates-admin--shortcuts-inc.json Updated: FormBuilder InputfieldCKEditor Contains: FieldtypeCropImage InputfieldCKEditor TextformatterVideoEmbed FormBuilder ModulesManager ProcessPageDelete pw_czech_099.zip pw_czech_modules_04.zip

Ah, I think I'm getting closer... this rule is where the path is appended for use in processwire RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] I solved it with a RewriteRule instead of a redirect RewriteCond %{REQUEST_URI} ^.*/new/(.*) RewriteRule ^new/(.+)$ http://www.newdomain.com/$1 [R=301,L] RewriteRule ^new/(.*)$ http://www.newdomain.com/$1 [R=301,L] I put this before all the other rewrite conditions. It redirects all requests containing the /new/ path to the new domain homepage, and also appends any path segments which might come after /new/. So www.olddomain.com/new/about/ becomes www.newdomain.com/about/ ...which is exactly what I wanted. Thanks for pointing me in the right direction! ------------------------------- Edit: the rewrite condition is not even necessary, and to execute the rule for just www.olddomain.com/new/, the + has to be replaced by a *. Yay!

I've just recently made a few updates to my site, the main one of which is the addition of a blog/sketchbook area – http://www.houseofdeadleg.co.uk/blotter/ – that makes use of the comments fieldtype (thanks to all the forum posts on the subject).

This is a php setting, so if you have access to your php.ini file you can adjust the max_execution_time there. If not, you could edit the profile export module's .module file and add this at the top: ini_set('max_execution_time', 300); That will give you 300 seconds, instead of the default 30. Of course any updates to the module will override this, but hopefully it will get you through this current task.

Not sure if you have seen it or not, but this module by horst is currently the PW image manipulation option: http://processwire.com/talk/topic/4264-release-page-image-manipulator/ You may actually need to look beyond GD to imagemagick - it is much more powerful. If you also get the imagick pecl extension, you'll have a very powerful PHP-only tool. I bet you could use horst's module as a starting point to create an imagick version with more options, but you'll have a bit of work ahead of you. If you do want to start tackling this, take a look at my Image Rasterizer module: http://processwire.com/talk/topic/4632-image-rasterizer/ which uses imagick. It should give an idea of how you can manipulate an image on upload using PW and imagick in a simple module.

Good morning I'm sure this is already here somewhere but I can't find it. I'm keen to start to have a go creating modules with process wire so I can make things reusable and share back with the community. I ve read the basics of how to create a module, hello world etc.... So I'm ok with that bit but as a starting point I d like to try and create something like an image gallery from scratch. Is there a tutorial I just haven't seen or something to tell me how from a module I can create the pages, fields etc via a module please with some custom js and css possibly. I don't want this to be a profile as I want to create a load of reusable plug and play type functionality commonly asked for by clients which is why I'm keen to do this as a module. I will of course share when I manage to build this and future modules as I get my head around pw Apologies again if this has been asked before, I could just be having a moment but appreciate the assistance. Have to say pw is amazing, till now I ve always used Drupal but I think pw will now be my tool of choice for most things, so incredibly easy to use from what I've seen so far. Might even re do some of my existing sites into processwire Thanks again Paul

I think you are looking for: how to create pages, fields and templates using the api. See this topic and this topic with great examples.

Hi All Day 1 for me with processwire as I was introduced to it by a friend a couple of days ago and have to say (being used to doing most things in drupal) I cant believe how easy this is to use and im hooked already, I can see it fast becoming my cms of choice for a lot of things I do currently. So time to ask my first question to help with my learning. Are there any tutorials or examples out there I can read to figure out how i can link associated data. For example i d like to create a page for a record relating to a staff member and then when i view the staff member see a table view below showing all their qualifications and skills, if possible several tabs with different data but i ll figure that out later unless theres a tutorial that already explains this as well. Hope that makes sense Many thanks in advance and im looking forward to hopefully contributing back as I learn process wire Paul

If I understand what you are looking for, the simplest way I can think of to achieve this would be to turn on the tags field for the images field and then enter "gallery" in the tags for the images that you want displayed in the slideshow. You could order by adjusting the order of the images in the field the normal way, or if you want a different order, you could have a second tag with the order number. Of course whether this is a good solution or not might depend on whether you are setting this up once, or your clients will be doing this regularly. So maybe not a great solution Personally I think it might be easier to have two separate image fields, one for the slideshow images, and one for any other images that need to be inserted in the body RTE.

I don't really get your setup. Pretty exotic. What about /site/templates/ ? I'm not sure, but if you don't have your PW installed in a subfolder /5gum/ then it shouldn't include in it urls. But as I said I don't really get your setup here. Could be that you have the /5gum/index.php rendering something? Why do you have it this way? To your problem of the image url. It's simply because you do this in a bootstrap and there's no output formatting happening there. So if there's no output formatting any image field will be an array, regardless of the image field settings (set to max 1). So this will get your image echo $brand->meta_image->first->url;

Hi Wilsea, Impressive summary of your initial take about the ins and outs of PW. Thanks. A few things need clarification: Pages - interesting further reading here by Joss It is important to understand the distinction between templates and template files. Templates do not have to have a template file with the same name as the template; you can tell PW you'll be using a different name. E.g. a Template called "Nit" can be associated with a Template File called "Picking". Template Files and not Templates display your data (in the fronted) Templates do not need to have a Template file Advanced template and template file approaches - classic thread by Soma and others. $page->first_name: in this case, there is a field on that page called first_name. If there isn't PW will complain very loudly Yes, fields are reusable. Some people get confused by this (not you). So, to further clarify, what it means is that you can add a field to as many different templates as you like and each of them (the field) will be a different instance of the field. It is important to add that removing fields from a template only removes the field's instance in that template and not in others. Also, you can't delete a field that is in use by any template. You can override the label of a field on a template by template basis (i.e. the instance of the field) For those who want to dig deeper: Each field (not each instance of the field) is actually a table in the PW database. The table will be named "field_field-name" (e.g. field_email). Each field instance is a row in that field's table Title field is not mandatory The only mandatory field in PW is Name. In the default install that ships with PW, Title is designated as a Global Field, hence required in all templates, hence its omnipresence. Hence, apart from name, in PW, all fields are custom fields. The name field is used to build the URL ...btw, the name and title of a page can be different Good job though! Cheers/k

I'm new to PW as well, but here goes.... pages This is how I understand it at the moment. The biggest conceptual shift is moving away from the idea that pages are web pages. In PW they are more than that. Pages hold data, so think of pages as more like records in a database. Exactly what data the page has depends on the template the page is using. When you create a new page, the first thing you do is choose a template for the page. templates. (1) Templates keeps track of what data items will be stored with each page eg name, position, phone etc. Each template uses one or more fields, and you decide which fields when you create the template. (These fields can be changed later on, if you wish, but obviously deleting a field will also lose the data associated with that field ). The data is collected when you fill in a form on the admin panel for each staff member, or if you already have a lot of data you can import the data as a csv file using the Import Pages from CSV module, You can have as many templates as you like, and fields can be re-used in multiple templates. (2) the template usually has a php file of the same name in site/templates that manages how the data is displayed. The template php file is where the code goes to produce a simple vanilla display of data, or can get as fancy as you like with tables, tabs, and whatever collection of whistles and bells you like. Each template has access to the $page variable that comes with PW, which can be used to refer to each item of data (ie the fields in the template) on your page, using syntax $page->myvariable to refer to the data in the field. eg If the page had a field first_name, then echo $page_>first_name would print the first name of the person associated with the page. Ryan explains it really well at http://processwire.com/talk/topic/43-template-tutorial/ (3) templates are created from admin>setup>templates>new template. This is where the fields are connected to the template (and to pages using the template). The php file manages the display of the page. It doesn't seem to matter whether you create the php file and import it into templates first, of whether you create a template first without a matching file and ad the file later. To display a page for Fred Nurk, you would have a page using a template with fields for name, phone and whatever else you want to record, and a template php file, with the same name as the template. If your template was called staff, you would also have a file staff.php, in site/templates. If the page for Fred was under a subdirectory called employees, and the title field was used for his name, then the page could be viewed at yoursite/employees/fred-nurk/ fields fields are containers for information. Fields need to exist before they can be added to a template. Fields are created from admin>setup>fields.new field. Each template has a mandatory title field, which is used to when a page is displayed in the pages directory tree. It's also usually used to build the url address that will be used to view the page. Getting information in a page from other pages You can get information into a currently displayed page from another PW page, by using the $pages variable and any selector that seems appropriate. There a number of different selectors that let you locate a particular page or group of pages by a wide range of criteria. The API section on Selectors is a must read and reread.(It's a lengthy page full of essential information and I found it took a while to take it all in - it might be worth printing it out ) The selectors take all the pain out of querying the database .For example, selectors might be used to set up a loop through each of the staff member pages (remember pages are like database records) and generate a list of phone numbers on one page. If you're keeping things like skills on separate pages, then you can use a selector to get information about the skill, and add that to your page on Fred Nurk. In your template php file you would use a selector to locate a page or group of pages, eg $myfoundpage=$pages->get(some selection criteria) or $myPagesArray = $pages->find (some selection criteria), and then you have access to all the fields associated with $myfoundpage through its template. If the template for $myfoundpage has a field for pet_name, then $myfoundpage->pet_name will give you the pet's name. It you want to get really fancy, you can display entire multiple pages inside one master page, using the render method of a page (it comes with that $page that is built into eachPW page.) echo $pageA->render(); echo $pageB->render; echo $pageC->render; would display the contents of all three PW pages on the one browser page. Or you might set up a master/child type of page, where the contents of the bottom part of the page are changed through an ajax call depending on what actions are taken at the top of the page. You'll probably get the idea pretty quickly by getting in and having a go. I'd suggest using a really simple template and going through Ryan's mini tutorial on templates at the end of this post The tutorials section of the forum is a pretty good place to start as well. There's also the wiki

No problem here with 2.3.11 logging in with different IP addresses. Have you tried this setting in your config.php $config->sessionFingerprint = false;

Thought I should actually put the demo up on my site: http://foundation5.stonywebsites.co.uk/

Hi Gebeer The main scss is foundation.scss in the scss folder. That in turn imports all the various foundation.scss files. This is then output to foundation.css using whichever method you want. Other than that, there are four other css files: editor.css has some basic foundation typography styles that can be used by whichever RTE you wish foundation.min.css is just the normal foundation download and is not linked - it is just there for reference. normalize.css - this is the normalize script included with foundation site.css - this includes some PW styles and any oddments that you want to have at your fingertips - for instance I have used it for some header styles and row styles. The reason I have laid it out like this is so that the foundation framework is distinct from anything else. If a dev then wants to combine elements, that is up to them, but their starting point is the same as if they had imported foundation straight from the zurb repository. They should be able to replace my foundation.css file with the original from Zurb and the site will still work, other than some colours. After that, they can bend it as they wished, but in this particular version, I did not want to add too many surprises for people who have used Foundation elsewhere

Hi all, today I finally managed to get everything working together properly. Now here is my Foundation 5 dropin template: https://github.com/gebeer/pwfoundation5. It uses Foundation 5 SCSS files. There's a quite extensive readme file with instructions. The template is based on Ryans FoundationSiteProfile. My approach takes advantage of the SASS/SCSS/Compass technology. So the output of the final CSS is highly customizable and only one file (style.css) is put out. You have full control over which modules of the Foundation framework you want to include in your project. This results in smaller CSS files that can be minified upon compilation with Compass. You can use the template as is. But if you want to modify the CSS, you need to have additional software (Ruby/Compass/Zurb Foundation gem) installed on your machine. In the template's Readme.md you will find instructions on how to do this (for Mac and Linux machines - Windows: sorry I don't know). If you are familiar working with SASS/Compass you will find your ways around easily. I have setup a structure that allows for updating the Foundation framework independently and that separates the project specific css from the Foundation css. This is a work in progress and I'm planning on using it for the relaunch of my own website. If you find any bugs, please let me know here or on the github bug tracker. I will try to fix them. Everyone is welcome to contribute or ask questions. Cheers gerhard

I believe when enabling pagefileSecure ProcessWire puts the pagefileSecurePathPrefix (default = "-") automatically in the folders when: - A page with the files field is unpublished - A page with the files field has a template to which the guest role is disabled Just checked this with a fresh install. I also followed soma's steps, but I can't seem to reproduce.

Thanks for your interest Ryan. The problem is at my end, as anticipated. It just took me hours and hours to realize that although all the codes were 9 nine letters, some of them should have been 8 letters, and the 8 letter ones are padded with a space at the front. Aaaarrrgggghhhhh. How could I be so blind. Please accept my apologies for wasting people's time. I'm uber impressed with PW - a joy to use and awesome support. I'm basically a retired hobbyist relying heavily on google and StackOverflow for programming knowledge. I started out with Wordpress , found that it was a pain t to customise, so was Drupal, CodeIgniter didn't light my fire, and Laravel assumed far more coding knowledge than I have. But for me PW ticks all the boxes - easy to learn, easy to use, helps you learn PHP and build a site that does what you want it to. Thankyou for making this product open-source. It's a game changer. I started with a brand new database

Awesome explanation, thanks for taking the time to document this. I'm rapidly acquiring a real taste for this thing they call processwire

I am also using dsnmasq on my local dev setup and I think all you should have to do is uncomment this line in the standard PW htaccess file: RewriteBase /

Little site note on the unique methode after the Wirearray of files: $config->jsFiles->unique() Appending unique isn't needed anymore, as the ->add('script-here') insures it's uniqueness. This works for 2.2, 2.3 and dev.

Whether cached at view or save, t's exactly the same amount of work either way. Though caching at save potentially creates more work. Whether we're talking about template cache or ProCache, there are a few reasons why it's better to do it upon first view, rather than upon save. Pages are only cached for guest users. If we performed an automatic cache after a page save, it would be within the context of the user editing the page. This is not a context we want to cache. You want the page to be cached within the context of a real page view, not from something automatic or behind the scenes. This ensures that any other modules that are part of the render process also get to participate. You may save a page multiple times in a short period of time (don't we all?). If it gets cached on every save, you are potentially using a lot more resources than if it was just cached the first time it was viewed from a guest user. If we regenerated on save rather than view, that would be a whole lot of extra saves that have to be performed in the system (a save uses a lot more resources than a view). Keep in mind cache files automatically expire after some period of time (defined by you). You can't rely purely on a save() for knowing when data is stale or not, as your site may be pulling data from multiple pages or other resources.

Hopefully you really mean that you replace the /wire/ directory and not actually overwrite it.

You can do it if using Inputfields from the API, but not from Setup > Fields > some_checkbox_field. Though I'm not sure what you mean about a double negative. ProcessWire is designed to be friendly to schema changes. We assume that you are probably not defining everything you need ahead of time. As a result, it's preferable to use a checked checkbox field to alter a default behavior, not to enforce one. Lets say you have hundreds of pages using some template, and you decide to add a new checkbox field called enable_nav that you use to determine whether or not to show navigation on a page. You could say that you wanted that checkbox to be checked by default... great, but that only applies to pages created from this point forward. All your existing pages didn't have the field before, and are not checked. So now you have a new problem. Now consider the the alternative, which would be to make your checkbox do the opposite. Instead of calling it enable_nav, you call it disable_nav. Add it to your template, and your existing pages are kept in the proper default state. New pages created from this point forward will check a box to bypass a default state rather than enable one. Using this strategy scales well, enforces consistency and don't break existing systems when you add a new field.

Yeah, it's fully ajax. Pagination, filtering, sorting... and it saves state, so if you come back it's on the same spot. It's very cool and fast. I see this as a great alternative to the page tree, when dealing with large lists of products.

I've just added it to ProcessPageSearch and committed the update to the P21 source. Now you can do something like this: var url = config.urls.root + 'page/search/for?template=basic-page&body*=something'; $.getJSON(url, function(data) { console.log(data); }); The example above shows "search/for?" as the URL. When you add the "for" to it, it assumes that you are going to specify a selector in the URL. This works with either Ajax or regular mode. In ajax mode, it returns JSON. In regular (non ajax) mode it's going to output the results in interactive/html mode as usual. This "selector mode" isn't used in the search engine by default, so it's only used when you include the "for?" in your URL and specify a selector after it. I believe this selector mode is much more convenient than the regular mode for AJAX use, as well as regular non-ajax links to the search engine. The selector can be identical in format to a regular selector with the only difference being that you separate each part of the selector with a "&" rather than an ",". Here is an example: /processwire/page/search/for?template=villa&body*=luxury&bedrooms>5&bathrooms<=3 The above is a valid URL, but it's also a valid selector. If we replace the "&" with ", ", then we get this: template=villa, body*=luxury, bedrooms>5, bathrooms<=3 PW abstracts away the parsing of GET vars that lack an equals sign, like "bedrooms>5", and translates all of PW's 2-character operators just fine too (like *=, ~=, %=, <=, >=). Of course, you can also do this (specify a parent path): /processwire/page/search/for?parent=/path/to/parent&featured=1 If you want to specify what fields should appear in the JSON output (or the interactive table), then just add a "get=" var to your URL, like this: /processwire/page/search/for?template=basic-page&get=title,path,categories Separate out the fields you want to "get" with commas, like above. When you specify what fields should be included, it will include them in the output, in addition to the native fields that are included in all (like id, name, template, parent, etc.). Because JSON can represents objects nicely, PW will also include partial objects (like page references) as JSON objects. For something like a Page reference, it'll include most of the native fields for each page, as well as the title and path. By default it will paginate by 50, though you can increase that up to 250 by specifying your own "limit=123" var in the URL (where 123 is the limit you want to specify). To retrieve the next pagination, specify the same limit but precede your URL with the page number, i.e. /processwire/page/search/for/page2?template=basic-page&limit=100 If you prefer, you can specify a "start=123" var in your selector (just like with other PW selectors), to indicate the result number you want to start from. But I'm guessing most will prefer the simplicity of using the page number pagination. If you call jQuery's getJSON() on the search URL, you will get your results in JSON format. Here's an example of a call we might use: $.getJSON("/processwire/page/search/for?template=basic-page", function(data) { console.log(data); }); jQuery's getJSON automatically converts it to an object in jQuery, but the JSON string is probably the simplest way to envision it, so here is the actual JSON string as it's returned from that query. This query was performed on a stock install of PW 2.1 using the included profile. <?php // ignore the PHP tag, I just wanted syntax highlighting { "selector":"template=basic-page, limit=50", // just a repeat of the selector you used "total":"4", // total number of results found. if there were 1230 matches, this would be 1230 "limit":50, // the max number of results that will be in this request (default=50) "start":0, "matches":[ // array of matches { "id":1001, "parent_id":1, "template":"basic-page", "path":"/about/", "name":"about", "title":"About" // plus any fields you specify with get=... }, { "id":1002, "parent_id":1001, "template":"basic-page", "path":"/about/what/", "name":"what", "title":"Child page example 1" }, // and so on for each match ] } I'm sure there are tweaks and improvements still to be made, so please let me know if you find any issues or areas for improvement.