Leaderboard

Hello community, i´m proud to tell you that my first website with processwire is online Even though I have not necessarily chosen the easiest project for me ... it was/is a great joy to work with processwire and I´m very glad to have discovered this great system and this very helpful community, thanks that I could be a part of it! Now to the page: It is a Trakehner horse breeding farm in southern Germany. www.trakehnerhof-st-vitus.de The basic system is based on the site template by Martijn (here again many THANKS Martijn). It is supplemented by a responsive Design with bootstrap, meanmenu, nivo-slider, magnific-popup and some css stuff. To import more than 500 individual horse sites, the CSV import module helped me a lot. By some Excel magic in the run-up and then a clean csv file the import to processwire was very easy! Installed Modules: - Image cropping tool - Get Video Thumbnails - ProcessImageMinimize - Piwik Analytics - MinifyHTML just to name a few ... So what do you say? Would you buy a horse

Hi, After the move to ProcessWire on one of our major websites, I had to build myself a module/plugin so I could use the Amazon S3 / CloudFront infrastructure. The module/plugin uses Amazon S3 PHP SDK and the idea was to provide a clean way to upload/backup files to S3 and distribute the assets via Cloudfront. The current version of the module/plugin will copy the page files to Amazon S3 so you can then serve the via Cloudfront automatically. Note that the files are still also copied to the server where your PW installation resides. There's an option to backup the deleted files to another folder on S3 because when you delete a file on PW via the admin, the file is also deleted from it's folder on S3. The module also supports Apeisa's Thumbnail module so it also stores the thumbnails on S3. Note that the native size() method to create image thumbnails on S3 is currently not supported. As it is, the module will only upload new assets, so beware that if you already have pages created with assets you'll definitely have errors, so my advice is to test this with a blank installation of PW. If anyone wants to test it and contribute to it, I think this provides a good proof of concept for a functionality that is requested by several users (me included). Please note that I'm not a PHP developer, my skills (very) limited and I'm aware that it can be improved and I'm open to suggestions, feedback and most of all, collaborators. The module is hosted on github here and it's available in the ProcessWire modules directory. Nelson Mendes

Hey, The Form API has CSRF protection build in, but if you for some reason don't want to use the API you can however use the CSRF protection. Its very simple but it took some time for me to find out, so i figured i share my findings with the rest. What is CSRF? First you need to create a token and a token name you do that as following: $tokenName = $this->session->CSRF->getTokenName(); $tokenValue = $this->session->CSRF->getTokenValue(); Very simple. Now what you want to do is create a hidden input field like this: $html .= '<input type="hidden" id="_post_token" name="' . $tokenName . '" value="' . $tokenValue . '"/>'; Now this will generate something that will look like this: You are done on the form side. You can now go to the part where you are receiving the post. Then use: $session->CSRF->validate(); This will return true (1) on a valid request and an exception on a bad request. You can test this out to open up your Firebug/Chrome debug console and change the value of the textbox to something else. Basicly what this does is set a session variable with a name (getTokenName) and gives it a hashed value. If a request has a token in it it has to have the same value or it is not send from the correct form. Well I hope I helped someone.

It has been a pleasure to develop our new website with ProcessWire. Welcome! http://www.nordenswansiirila.fi/en/ -- Mikael

Not really a ProcessWire wish, but related: Currently it's only possible to state a supported ProcessWire version for a module in the modules directory, and that has to be 2.0, 2.1, 2.2, 2.3 or 2.4. Anything beyond that has to go to comments (where it's rather easy to miss). The most basic thing I could think of would be the ability to provide required ProcessWire version as '2.4.1' etc. in case that nearest minor version (2.4 in this case) isn't supported. I'd also like to specify any other modules that are required -- and perhaps even more specific things than that, such as PHP version or specific extension (Imagick comes to mind first).

I can confirm there is something strange happening with 2.4.5 and admin theme switching. It may have existed before that as well. Happens on both Mac/PC and is not specifically related to Modesta. I submitted an issue on github

Depends what field "image" is really. If it's single image field your code would be fine. If it allows more than 1 image it will be a WireArray, and your code would fail. Then you'd need to treat it as such using if($product->image->count){ ... } Then you'd access images in the array using a foreach loop, or with one of the array functions $product->image->first()->url or $product->image->eq(n)->url If that's the case you might want to set "image" to allow only 1 image (as the name suggests) ,then your code would work and be consistent with the naming. After all I could have also linked to the other 1'000'000 threads about this very same image field problem everybody has. But maybe it's just enough to link to the documentation which explains this again. https://processwire.com/api/fieldtypes/images/

You might want to have a look at this alpha module from Soma: https://github.com/somatonic/BlocksContent There is some discussion about it here: https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=45437 You might want to browse further back in that thread too. One other possibility might be the new PageTable field type which allows for adding multiple content blocks (you can define multiple templates) that can be sorted by the user, so you could easily have a separate Add button for each of your content types - I think this could be pretty effective actually. There isn't any real documentation for PageTable yet, but you can start reading here: https://processwire.com/talk/topic/6417-processwire-profields-table/page-2#entry62890

I'll set this option on my To-Do. After my vacation.

@Manfred62 You have to uninstall Default Admin Theme from Core modules section before/after installing Modesta Admin Theme and it should work fine. I'll update the readme with instructions. New theme updates coming after this weekend

Getting ready for release, it’s ready to test. I just committed version 0.9.0 which adds the setup panel. https://github.com/plauclair/FieldGenerator You can see it in action here: I would really appreciate that you submit bug reports on GitHub if you find anything.

What about $Locations->unique(); http://cheatsheet.processwire.com/?filter=unique

Oh I see, so your selector is relative to PageA and PageB as the current $page ? In that case this should work when run from PageA or PageB: foreach($page->children() as $c){ or foreach($page->children("template=basic-page") as $c){ Do the "Child Pages" ever get loaded by their URL? If so and because they have the same basic-page template, you need to do something else to prevent them for looking for child pages. You could simply do: if($page->numChildren()>0){ foreach($page->children() as $c){ } Or perhaps it would actually make more sense to have a separate template for the PageA and PageB parents? Lots of options really

Manfred62, looks like I broke it in one of this week's commits. I added translation support to uploaded filenames so that you could upload ŖýäŅ-Čřämêŕ.jpg and it would convert to ryan-cramer.jpg rather than ____-______.jpg. It basically runs files through the existing translation engine used by page names (and your settings defined with the InputfieldPageName module). So it was attempting to beautify filenames in the same way as page names, which meant converting things like doubled hyphens to a single replacement character. Obviously that's not compatible with the language JSON file name format, my mistake. I've modified it so that it now allows doubled hyphens, so it should be fixed now on dev. I was also able to duplicate the issue with the Setup and Access page titles/summaries incorrectly displaying in default language, so that should be fixed now as well. Thanks for reporting it.

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

Just wanted to share what I recently used to create forms in modules and in frontend using the API and Inputfield modules PW provides and uses on its own. I think many newcomers or also advanced user aren't aware what is already possible in templates with some simple and flexible code. Learning this can greatly help in any aspect when you develop with PW. It's not as easy and powerful as FormBuilder but a great example of what can be archieved within PW. Really? Tell me more The output markup generated with something like echo $form->render(); will be a like the one you get with FormBuilder or admin forms in backend. It's what PW is made of. Now since 2.2.5~ somewhere, the "required" option is possible for all fields (previous not) and that makes it easier a lot for validation and also it renders inline errors already nicely (due to Ryan FormBuilder yah!). For example the Password inputfield already provides two field to confirm the password and will validate it. De- and encryption method also exists. Or you can also use columns width setting for a field, which was added not so long ago. Some fields like Asm MultiSelect would require to also include their css and js to work but haven't tried. Also file uploads isn't there, but maybe at some point there will be more options. It would be still possible to code your own uploader when the form is submitted. Validation? If you understand a little more how PW works with forms and inputfields you can simply add you own validation, do hooks and lots of magic with very easy code to read and maintain. You can also use the processInput($input->post) method of a form that PW uses itself to validate a form. So getting to see if there was any errors is simply checking for $form->getErrors();. Also the $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automaticly. It's also worth noting that processInput() will work also with an array (key=>value) of data it doesn't have to be the one from $input->post. Styling? It works well if you take your own CSS or just pick the inputfields.css from the templates-admin folder as a start. Also the CSS file from the wire/modules/InputfieldRadios module can be helpful to add. And that's it. It's not very hard to get it display nicely. Here an code example of a simple form. <?php $out = ''; // create a new form field (also field wrapper) $form = $modules->get("InputfieldForm"); $form->action = "./"; $form->method = "post"; $form->attr("id+name",'subscribe-form'); // create a text input $field = $modules->get("InputfieldText"); $field->label = "Name"; $field->attr('id+name','name'); $field->required = 1; $form->append($field); // append the field to the form // create email field $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $form->append($field); // append the field // you get the idea $field = $modules->get("InputfieldPassword"); $field->label = "Passwort"; $field->attr("id+name","pass"); $field->required = 1; $form->append($field); // oh a submit button! $submit = $modules->get("InputfieldSubmit"); $submit->attr("value","Subscribe"); $submit->attr("id+name","submit"); $form->append($submit); // form was submitted so we process the form if($input->post->submit) { // user submitted the form, process it and check for errors $form->processInput($input->post); // here is a good point for extra/custom validation and manipulate fields $email = $form->get("email"); if($email && (strpos($email->value,'@hotmail') !== FALSE)){ // attach an error to the field // and it will get displayed along the field $email->error("Sorry we don't accept hotmail addresses for now."); } if($form->getErrors()) { // the form is processed and populated // but contains errors $out .= $form->render(); } else { // do with the form what you like, create and save it as page // or send emails. to get the values you can use // $email = $form->get("email")->value; // $name = $form->get("name")->value; // $pass = $form->get("pass")->value; // // to sanitize input // $name = $sanitizer->text($input->post->name); // $email = $sanitizer->email($form->get("email")->value); $out .= "<p>Thanks! Your submission was successful."; } } else { // render out form without processing $out .= $form->render(); } include("./head.inc"); echo $out; include("./foot.inc"); Here the code snippet as gist github: https://gist.github.com/4027908 Maybe there's something I'm not aware of yet, so if there something to still care about just let me know. Maybe some example of hooks could be appended here too. Thanks Edit March 2017: This code still works in PW2.8 and PW3.

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

Greetings Recently uploaded my first site made within the amazing walls of ProcessWire. It's a very simple, yet professional, site for an accounting, tax, and business consultancy in Limbe, Cameroon. The site uses well-built templates (especially on the backend - I really love the way everything works with the editing pages on a per-template basis), and a custom module for the contact form, which runs a clear and concise validation service, powered by the respective Illuminate components (yes, I had to mingle Composer into the scene). Looking forward to many more sites in PW - as it is, I have three more to upload by the end of July. Hope you like it - feedback is always welcome. www.aegpartners-cm.com

I guess the approach would depend on the actual time constraint requirements. If you needed an allowed range of time (ie: between 1pm and 2pm) you could write a simple php function that pulls the current time and tests to see if you're within the specified range. // 130000 == 1:00:00 pm, 140000 == 2:00:00 pm function testTheTime($startTime=130000, $endTime=140000){ $currentTime = (int) date('Gis'); if ($currentTime > $startTime && $currentTime < $endTime ){ return true; } else{ return false; } } $inRange = testTheTime(); // do something with it The $page->created property comes in the form of a Unix timestamp, so you could format it with PHP's date() function however you need. Obviously, you could throw that into the mix of the above function and do what you needed with just a function. If you want a hook you could do something like: // add a method called "test" wire()->addHook('Page::test',null,'lockPage'); // function evaluates the created time of the page, and compares it to specified start and end times function testTheTime($createdTime, $startTime, $endTime){ $createdTime = (int) date('Gis'); if ( ($createdTime > $startTime) && ($createdTime < $endTime) ){ return true; } else{ return false; } } function lockPage(HookEvent $event){ $page = $event->object; //grab the page instance $createdTime = $page->created; //grab the created timestamp $lock = testTheTime($createdTime,130000,140000); //pass it along $event->return = $lock; //returns the value } if($page->test()){ throw new Wire404Exception; //if the created time is within 1pm or 2pm, throw a 404 } I know, I know, it's a crappy example of a use case but you get the idea of where you could take it (sorry, I'm that that imaginative when at work). BTW, the above is for using within a template file, you could easily make a module and not make your template file so ugly.

http://validator.w3.org/check?uri=http%3A%2F%2Fanswerhub.com%2Fblog&charset=%28detect+automatically%29&doctype=Inline&group=0 Error #4

For the login, you would create a login form and based on who they are, direct them to the appropriate landing page. This can be tricky to update if you're hardcoding all the partner companies into your script (don't do that). Instead, for each company, create a user. Then, based on the users role, they can access pages that they are allowed to manage. You might find the Page Edit Per User module handy http://modules.processwire.com/modules/page-edit-per-user/ Or the Page Edit Per Role module http://modules.processwire.com/modules/page-edit-field-permission/ . I am actually working on a front end admin for users of a company intranet and that's along the lines of how I do it.

Do those pages have the language really active?

better count than find if($pages->count("/contract/")){ // exists } with find() it would be slightly less efficient if($pages->find("/contract/")->count){ // exists } Or get() will return a NullPage object if not found if(!pages->get("/contract/") instanceof NullPage){ // exists }

I can confirm this workaround!! Now I also have the Modesta theme activated. Also you can have both themes installed. You only have to make a new search for modules, to refresh the theme change. For example: root gets Modesta theme, guest gets Default theme is also possible.

I just had the same issue on mac with a fresh install. I uninstalled the default admin theme, which changed nothing, but then I hit "check for new modules" and the next page loaded the admin theme correctly. It's really wierd.

I see what you did! Ha. You are getting the children of the top level locations page, which is always a state, instead of reading the state field on the locations template! That would work.... It looks like I was making this harder than it had to be! There was totally a process wire way to do this. I am going to try and see if I can get by with out that statename field on the location as well. I don't think the optional city name will matter.

Well how about a separate query like: $locations = $pages->get("/locations/"); foreach($locations->children() as $state) $StatesHTML .= '<option value=".$state->name.'>' . $state->title . '</option>'; } Maybe this is still getting duplicates, but I would think from your page structure, there should only be one Statename for each state, with multiple Location Names children below each Statename

Hi, sure I know that deleting the rows in the database solves it perfectly. My post is -because I think to remember that there was a max_age setting somewhere (but I cannot find it) -and because a Delete-All button is something I was used to from Drupal and liked the idea to have such a button.

This is expected behavior for TinyMCE. If you click the HTML button and cut/copy/paste everything in there it will work fine.

Damn, wish I found this one a bit earlier, I did practically the same thing, could of saved me some time. Still, excellent stuff and insights!

Hi Ralf, I love to see you succeeded with the site. Jahj ! Congrats with the outcome! The site is easy navigate-able and looks fine. It was a pleasure to help you out with the profile and big thanks naming me in the "impressum".

Yes I would...

As would I. Currently I have a foreach pushing the list into an array and using that but if I could use the FilenameArray it would simplify my code a great deal. $min_js = array(); foreach($config->scripts as $script){ $min_js[] = $script; } if(count($min_js)) echo '<script src="'.AIOM::JS($min_js).'"></script>'; I'm not sure about my foreach since it could be run on an empty $config->scripts but I don't know how best to check a FilenameArray is not empty, count() returns 1 when it's empty usually.

@Manol, Regarding the Feed Module: 1. Could you validate your feed. It should say: "Congratulations!" 2. It can be that the ttl (time to live) is to high.

Wao! thank you so much statestreet. You were the last piece to the puzzle. I just did a fresh install and read this entire thread. For those who are wondering Follow arjen Instructions here: https://processwire.com/talk/topic/1025-multisite/#entry20399 For dev or localhost you'll need to edit your host file for your second domain name so it points to the same directory EG. 127.0.0.1 madbox.com You may need to edit your virtual host when it goes live so it points to the right directory. Doesn't really matter for dev. <VirtualHost 127.0.0.1> ServerName sandbox.com ServerAlias madbox.com DocumentRoot "C:/wamp/sandbox.com" <Directory "C:/wamp/sandbox.com"> allow from all order allow,deny AllowOverride All </Directory> </VirtualHost> Then in the site/config.php you'll need to edit the httpHosts variable (last one) EG. $config->httpHosts = array('sandbox.com', 'www.sandbox.com','www.madbox.com','madbox.com');

If you just need to remove those specific parts (i.e. all URLs start with index.php/news/11-latest-news/) then try this: RewriteRule ^index.php/news/11-latest-news/(?:[0-9]*-)([^\/\.]*).html$ http://www.domain.com/news/latest-news/$1/ [L,R=301] If that's just one example and you're looking to remove index.php and all sequences of [0-9]*- from beginning of pages, you might have to do something like this instead: RewriteRule ^index.php/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*).html$ http://www.domain.com/$1/$2/ [L,R=301] RewriteRule ^index.php/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*).html$ http://www.domain.com/$1/$2/$3/ [L,R=301] Note: that last one is pretty ugly and requires new rewriterule for each level of content. I'm not aware of any sensible way of implementing string replacement via rewriterules, so if this really is the case you might benefit from actually doing this with PHP -- just point all index.php requests to custom PHP script (or page or whatever) and do 301 redirect from there after a bit of preg_replace() magic.

Ok, just to follow up. I have fixed the issue with the error when using the "Edit Imported Content" option - stupid oversight on my part when I added a cleanup routine in a recent update. Should be fine now I can't replicate the error around roles so it would be great to have your exported json if possible. I also tried to look at the language page names issue, but when I tried to leave the default name blank I get an error saying that it can't be blank, but I think I must not be understanding this. Could you please outline the steps to set up a site with multi-language page names with a blank default name so I can test this. Thanks again for your feedback with this.

Well I think this should work: foreach($pages->find("template=basic-page, parent!=/") as $c) That will get all pages with basic-page template but without home (/) as their direct parent. Of course this won't work if you end up with further levels of child nesting. But right now, Page A and Page B should be excluded by this.

hi there! i just discovered this great module an wanted to test it with a site of mine. export worked well (140mb zip ), but the import failed with the following error: it seems like there is an issue with the import/export and the use of the »Languages Support - Page Names« module. using this module, the homepage also has a name field for each language, where the field for the default language is empty by default. this seems to bug the import. if i add a name manually, the import succeeds, but i get another (undeleteable) homepage under the original. a second error occurs, when i try to import user details: i couldn't find the reason for this. and last but not least the third error: When i select the "Edit Imported Content" option, i can choose the fields and pages, i want to import. after submitting may selection i get an error, that zip or json are missing. otherwise, great module!

I can't tell for sure what the problem is, so I think you should try to simplify things down and debug each variable to figure out where things are going wrong. Bring it back to this: foreach($page->children("category=$input->urlSegment1") as $preview){ echo $preview->title; } Things to check are that the name of the category field is correct. Remember this must be the name of the field that is used in the template on the current page and not the name of the parent page that houses the child categories. Also try echo'ing $input->urlSegment1 to make sure it actually contains the name of the category you are looking for. If not you can firstly replace this with a hardcoded category name to make sure your selector is working, then track down why $input->urlSegment1 is not being populated. Hope that helps to get you sorted.

You would link multiple users in a similar way - new Page field called users, configured for "template=user", and use the "Multiple pages (PageArray)" option on the field Details tab, and add to the event template. The difference in code would be this: <?php // Loop through all users added to the page. foreach ($page->users as $u) { // Use $u (or whatever you like) but not "$user" - it is a ProcessWire system variable (current logged in user). echo $u->name . " is a member of this event.<br>"; } ?> Locations with the same name would not be permitted to have the same direct parent - so the name would have to be changed when adding it. Each page still has its own ID, name and path which can be used to identify and load them within code. For example: ID: 1042 Name: concert-hall Title: Concert Hall Path: /locations/concert-hall/ The ID cannot be changed, but the name can. And the path is built up based on the name of the page and the names of it's parents. By default, names are automatically generated from the title field value, but can be overridden if necessary, generated yourself, or automatically using datetime values.

New version available: It now uses an iframe implementation, not as easy as it sounds, because the text area and the iframe somehow need to share the data. At first I went for the session thing (see above), but then realized there would be too many server requests going on. Then I went with cookies, nah 4096 byte limit .. so I now use local storage with a cookie fallback. So now the styles are scoped properly, no clashing of rules. The refresh interval is now configurable. Major code refactoring under the hood and many additions, little optimizations, not so elegant anymore, but whaaateva. It now comes with another optional theme Solarized Dark, it's not as pretty as I thought, will look for better default ones Key strokes of space and enter are ignored, so no unnecessary refreshes are taking place. When updated content is injected (and overflows the browser window), it does not scroll to to the top, but stays at the current position. Summary how it now works (for those interested): The text area is watched for changes, when it changes, the text is sent to the server, converted via text formatters. a local storage item with a unique key of that field and the respective page is set to true meanwhile within the iframe, JS is polling for that value very frequently (no server requests are taking place here), if it's true the text is injected (and only then to prevent constant flickering), the value is set to false so the iframe is only injecting when changes happen in the text area Roadmap: I would love to make the config on a per field basis, but since this module is not an input field but merely hooks into the rendering I am not sure how to, will look into that. Oh, and it's on the module directory now too: http://modules.processwire.com/modules/process-textarea-preview/ Cheers!

If articles is your news listing page and a child of your home, why don't you just do: echo "<p>Return to: <a href='/articles/'>articles.</a></p>"; (Note: As Soma mentioned, whatch your use of quotes) It is shorter, no less customizable and uses the page tree structure. The API way of getting a url of a page is great for instance within a foreach loop where you are listing out the results from a query, but is not needed for a straight link. The API allows you to do things that are not straightforward; it is not intended as a replacement for ordinary actions.

Feasibly it's possible, but it's not desirable. Making wire('var') aware of context involves pre-compiling the template files to replace wire('var') with wire($this, 'var'). So it's something we do to provide backwards compatibility in template files. We won't be providing that backwards compatibility outside of template files, so people will have to use $this->var, $this->wire('var') or wire($this, 'var'); elsewhere. Also, a Static::syntax implies dealing with a framework that only has one context, which gives the appearance of a weakness that isn't there, something I think we'd want to avoid. While I'd really like to limit statics in ProcessWire as much as possible (just because they are more than often a bad programming practice), that syntax is perfectly fine for static functions where context doesn't matter or where you are passing the context into it. For example, $sanitizer functions would not need to have different behavior in different contexts. I've even seen some frameworks that do use statics for sanitization functions as well. In the end though, IMO they would still be better served by providing the same functions non-statically. The plan is that when you do this... $main = new ProcessWire('/site/'); $intranet = new ProcessWire('/site-intranet/'); ...everything in each of those two instances will be unique to those instances and whatever site files are stored in /site/ or /site-intranet/. That means that when a module is initialized, it is only initialized for the instance (whether main or intranet). When a module refers to $this->var, it's referring to API variables that are part of its instance only. This enables you to have multiple sites talking to each other. Currently this isn't possible precisely because PW uses statics for API variables behind the scenes. But the fact that we've kept that behind the scenes is a good thing because that means it doesn't matter how our API variables are stored. We can switch them to a stronger storage mechanism that would be tied to an instance. This is one reason why I deprecated the Wire::getFuel() syntax (that appeared in early versions of PW2) early-on... though you might still see it appear in a few core spots, which will need to be changed. But we've really tried to keep the public API clear of static calls so that the API would not have to change as PW continues to grow as a framework.

I finally figured this one out. I had just about given up, when I thought to look in config.php, and lo and behold, there at the bottom was $config->httpHosts, which only contained the domains that were working. I added the other domains, and now the multisite module is working excellently.

Those modules are purely written for this setup. You take them out of the site then they won't function. I don't see value for those in Modules section, that list should be clean. (less is more) - If you want to get insight of the working for the tabs (ProcessPageEdit::buildForm) go for Soma's TemplateNotes - For the Process module, take a look at ProcessHello (ryan's great howto do process modules ) In basic, modules are not hard to do. When you know what to hook, and you know how to get the $event object and you know how to give it back, then it's not much different from working in your templates. There are many modules around here. And in a lot of circumstances others already have done these three things for you. If you take those as starting point, you only have to write some basic PHP. Don't let the word .module "fog" your mind

Ralf needed a parental Pedigree and I helped him to setup a very basic site. I quite liked the building of it and it resulted in doing 'to much' just for fun. I Asked Ralf if I could make it to a site profile so that someone else could profit from it to. Horse template Family Tab (Horse template) Pedigree (d3js) Unfinished Horse ( Horses created by Pagefield, but not yet edited ) Menu building /processwire Menu front-end / Download The Profile: pedigree_profile.zip

Dear Ryan, I think that the way you've created the interface to the more exotic field types in the Admin back end is really great. I'd like to be able to use any or all of those fields on the front end, via the API, more easily, based on a clear and simple set of notes and possible division of .js and .css files per field. For example, to get the calendar popup working in edit mode, in a front end app, I had to include these files in the <head> section of my pages: <link type='text/css' href='/site/templates-admin/styles/JqueryUI/JqueryUI.css' rel='stylesheet' /> <link type='text/css' href='/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.css?v=103' rel='stylesheet' /> <script type='text/javascript' src='/wire/modules/Jquery/JqueryCore/JqueryCore.js?v=183'></script> <script type='text/javascript' src='/wire/modules/Jquery/JqueryUI/JqueryUI.js?v=192'></script> <script type='text/javascript' src='/wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js?v=103'></script> <script type='text/javascript' src='/wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.js?v=103'></script> <script type='text/javascript' src='/wire/modules/Inputfield/InputfieldDatetime/jquery-ui-timepicker-addon.js'></script> To get the multi-column checkboxes working in edit mode, I had to include this <div> in my edit form: <ul class='Inputfields'> ... input field here ... </ul> and then I copied a variety of CSS classes from your core code into my main css file. I'd like to be able to use the image upload field with the progress bar, and many of the other specialized fields that you've created, that require special javascript or css to run properly. My suggestion is to create js and css files per field -- or field family, that can be easily included, without extra weight from other items, with notes on each field, e.g. - for xyz field, include these .js and .css files, and add this xyz html to your edit template (if necessary) This would allow developers to *easily* use the full power of the admin fields in front-end edits, which would be a truly glorious thing. Thanks! Peter

First of all, I'm a big fan of PW's current admin UI and also aware of other possible admin themes, but I'm also very happy about the discussion in that thread @kongondo linked above.. and thus also the opinions expressed here Common argument here and elsewhere seems to be that PW allows you to swap the default admin theme to something else, but I don't think that people saying this are really getting it. There's a very special position deserved for default theme. It's an entry point, first impressions are based on it, and it also plays an important role when defining PW's external image, ie. what kind of message it wants to send. I've evaluated a few CMS products myself and I must admit that for me first impressions are very important. I'm the kind of guy who first looks for screenshots and then reads the specs. That's just how my mind works and saying that it's "wrong" is, in my humble opinion, more than a bit arrogant. Current default admin theme is very usable and I myself like it's simplicity a lot, but that two-column layout @Philipp presented in aforementioned thread was simply jaw-dropping. Just because PW is a flexible framework for building awesome custom stuff doesn't mean that it can't be pretty and sexy out-of-the-box, especially if that's what many (otherwise very capable) web designers / developers are looking for. There are a lot of CMS products around that all claim to be flexible, extensible and usable. It's simply not an easy market to crack and thus I don't think that we should skip over any steps that can make PW's road less rocky.

Thank you, Ryan. My intent was to implement some sort of security auditing such that I would receive a message whenever a CSRF was attempted. So I needed to catch the exception. The following code works for me. try { $form->processInput($input->post); $session->CSRF->validate(); } catch (WireCSRFException $e) { echo "Processing aborted. Suspected attempt to forge the submission. IP logged." . $e->getMessage(); /* * Some code to execute whenever the token gets spoofed * Like sending a notification mail with the spoofer's IP address */ die(); // live a great life and die() gracefully. }