Search the Community

Yeah I tested code and found some issues. I create a code that works. Study how it's done and the changes. $page needs to be retrieved different, and it had some logik faults, it needs to add or remove $page, not $s_team... Biggest issue with save hooks is that when you save a page in the module it will get called endless recursive. To prevent this we save a skipme to the pages saved on runtime to it does skip them. Also added some additional checks for if there's no pages selected at all, to remove all references. Here a new working proof of concept module: https://gist.github.com/4335296

Hey, thanks for answering. I am logged out when performing the benchmark (see previous reply). I also tried enabling cache for "Guests and logged-in users", but that didn't make an impact. I did configure the cache under Template settings, and I am hitting only one page. The module I activated is called FieldtypeCache, and its summary is: "Caches the values of other fields for fewer runtime queries. Can also be used to combine multiple text fields and have them all be searchable under the cached field name. " I am pretty new to ProcessWire so that might not have been the correct thing, but Template cache isn't working well for me. I guess what I am asking is: 1.) Is there any way to verify that the template cache is working properly? 2.) Is it normal for cached pages to generate mysql queries?

Did some investigating here. If I'm right, it's not a bug per se, but an undesirable behavior. Try changing your code to this: require('./index.php'); // this is the ProcessWire index file for bootstrap $wire->pages->setOutputFormatting(false); echo $wire->pages->get('/videos/')->render(); echo "\n\n\n\n\n==============================\n\n\n\n\n\n"; echo $wire->pages->get('/people/')->render(); That fixed it in my case. The reason was that calling setOutputFormatting() on a page only sets the outputFormatting for that page. If your page's template happens to be loading other pages, they will be loaded with outputFormatting off. By setting the default output formatting state before you render(), you correct that issue. This is only the case when you are rendering from a bootstrapped script, because that default outputFormatting state is pre-set to false. In any other situation, you wouldn't have to do this. I think I can make this a lot simpler. I'm just going to update $page->render(); to take care of setting the right outputFormatting state for itself and the system before it attempts to render a page. If that change didn't fix your case, then go in and check the template(s) for the pages that are being rendered. Do you have any include() statements that should be changed to include_once()? This would be the case if you had any function definitions in include files. If you have any function definitions in your main template file, then you'd want to do this instead: if(!function_exists("my_function")): function my_function() { // do something } endif; Since your two page render() calls are happening in the same PHP runtime instance, you just have to watch out for any duplicate definitions or includes. Let me know if any of this solves it there?

The only way to prevent this issue is to install "PageLinkAbstractor" module and it will give you additional options on textfields. This will parse urls and add subfolder on runtime. http://modules.processwire.com/modules/page-link-abstractor/

URL segments are a runtime thing that ProcessWire doesn't know anything about. It only knows where you want to allow URL segments, but not what they are or what you plan to do with them. It's up to you (in your templates) to look for the URL segments you want to act upon. Likewise, it's a best practice to throw Wire404Exception(); when your template gets a URL segment it doesn't recognize. If you want to avoid any possibility of there ever being a collision between a page name and a URL segment, then you wouldn't use URL segments on pages that had children where the URL segment names had potential similarity with the child names. However, I think it's okay to use them in the instance where you are because it seems like there is no chance for a real-world collision here. I would feel comfortable using the URL segment "category" in this instance just because it doesn't seem to be consistent with something that would ever be used as an article title (though that may be just me).

We force a non-www on processwire.com, but it seems that not many sites do that for whatever reason. If you want to do that, here's the code you can use in your htaccess (replacing processwire.com with your domain): RewriteCond %{HTTP_HOST} ^www\. RewriteRule ^(.*)$ http://processwire.com/$1 [R=301,L] This isn't technically part of ProcessWire's runtime configuration because the rules in the htaccess file are what ultimately gives control to ProcessWire (they are executed before ProcessWire is).

This fieldtype wouldn't even need a db-table, since value is always 0 (well, it is 1 at the runtime but that will never get saved). So there probably is some code that can be removed (this was build from Checkbox fieldtype).

It's not a good idea for 'autoload' to be the only condition necessary to add script or css/style files. That's because some (including me) use things like $config->scripts and $config->styles on the front-end of sites, and don't want it to be populated with files irrelevant to my site. Furthermore, we can't assume that we always know what ProcessWire is being used for (it might not have anything to do with HTML), so it's just taking up extra memory if some autoload module is populating filenames when they won't ever be used. This is why none of PW's modules that deal with script/style files are autoload, and also why Process and ModuleJS module interfaces are not autoload. Process modules are on-demand, but if you have a Process module that you've made autoload, then you'd want to manually load any script/style files in the relevant execute() method -- this ensures they won't get loaded unless they'll actually be used. The ModuleJS class is different, as it's really not intended to be autoload at all, so there's not really any use in combining ModuleJS with autoload. The whole idea of javascript or css is specific to a runtime and on-demand context. And this is how it's happening in the admin template, as it is what ultimately triggers the JqueryCore and JqueryUI libraries to be loaded. And this is the time that they get placed into the $config->scripts array. So we'd just have to find some way to hook after that takes place, but before the markup of the page is generated. I think this may work for an autoload module: public function ready() { if($this->page->template == 'admin') $this->addHookBefore('ProcessController::execute', $this, 'hookExecute'); } public function hookExecute(HookEvent $event) { $this->config->scripts->add(' your script file '); }

I see what you mean. Sorry for the confusion this may have caused. I will think more here about how to handle this. I don't want it interfering with API usage such as yours, but do want it to be able to still work with any login form (whether ProcessLogin or a custom one). Initially I'm thinking maybe I should just have it throw an Exception rather than a $this->error(). Errors communicated via $this->error() require something to report them (like the admin template), so this could be hard to find in API usage. Whereas an Exception would be hard to miss. Beyond this, I think a way to disable SessionLoginThrottle at runtime would be worthwhile for a case like this too.

Sorry I missed this before. Got your PM so replying here. I'm still having some trouble understanding the question, but think I follow a bit. It sounds like you are trying to use $pages->get() to retrieve a page via a path like /a/b/ where /a/ is an actual page and /b/ is a urlSegment. A path with a urlSegment in it doesn't resolve to an actual page except when requested from the browser. So you can't use the API to retrieve a page by path with a urlSegment in it -- you'll get a NullPage. You would want to use just the /a/ (the part that is actually a page) in your API call. urlSegments are just runtime things for you to branch from in your template. They don't represent physical pages to the API.

Given that we don't know what the user's fields or types will be ahead of time, there isn't really any way to document it with the Page class (that I know of). The function that handles this particular situation (setting a value to a $page->pageref) is FieldtypePage::sanitizeValue(). It is currently documented (with phpdoc) to indicate what it's for and all the values that it accepts and returns. But doesn't say anything like "usually you'd set a PageArray" because I don't think anyone is going to be looking here unless they already know the routes that setting a value to a Page takes. Ultimately, the best way to document this sort of stuff may be outside of the code itself and in online documentation specific to each Fieldtype. I think the cheatsheet is a great resource for this stuff. Though I don't think there's anything specific to the situation we're talking about just because it's one of those things specific to a FieldtypePage. So I think FieldtypePage probably needs it's own manual. That's what we're doing now. But I'm not sure how to communicate to someone that when they set (or get) a value to a Page, a lot of decisions go on behind the scenes. In our particular case of setting a $page->pageref, the path would be this (pseudocode): $page->set('field_name', $somePage); { // if 'field_name' is a custom field confirmed by the page's fieldgroup, use setFieldValue() $this->setFieldValue('field_name', $somePage); { // get the Field object $field = $this->fields->get('field_name'); // let the Fieldtype sanitize the value before setting it to the $page, i.e. convert Page|int|string|array to PageArray $value = $field->type->sanitizeValue($this, $field, $somePage); } } That last line is where the magic happens. The sanitizeValue will accept $somePage in various types, but always returns a PageArray back to the page. If it gets something it doesn't like, then it's either going to throw an Exception or refuse it (depending on what the Fieldtype author thinks is appropriate). Something similar happens when you get() a value from a Page, tough even more behind the scenes: $page->get('field_name'); { // if field_name is a custom field confirmed by the page's fieldgroup, use getFieldValue() $this->getFieldValue('field_name'); { $field = $this->fields->get('field_name'); $value = parent::get('field_name'); // check if it's already loaded if(is_null($value)) { // value isn't yet loaded, so load it $value = $field->type->loadPageField($this, $field); if(is_null($value)) { // if no value then set a default (like blank PageArray) $value = $field->type->getDefaultValue($this, $field); } else { // convert value to runtime type, like array of ints => PageArray of Pages $value = $field->type->wakeupValue($this, $field, $value); } } // if output formatting is on, let the fieldtype modify it for presentation (if it wants to) if($this->outputFormatting) $value = $field->type->formatValue($this, $field, $value); } } I'm not exactly sure how to document this beyond the pseudocode above, or if it even matters. I'd rather people think of it as just setting or getting values and everything works. But it seems like a separate page of documentation for each Fieldtype might help to answer some of the questions.

Perhaps having permissions at the template level should be a pre-requisite to making them definable at the page level? Meaning, if you didn't have this module installed, then the permissions would need to be setup such that the user would be able to create the pages. I thought this was the case before, but might not be remembering it correctly. This seems like a good way to go. It should also probably return false when the template defines access that doesn't include the user's role. So if you use the strategy above, this hook would be more about selectively denying access than allowing it. Maybe best to remove these fields entirely from the form at runtime using the ProcessPageEdit::buildForm hook: public function hookBuildForm(HookEvent $event) { if(wire('user')->hasRole('paakayttaja')) return; $form = $event->return; $field = $form->get('view_roles'); if($field) $field->parent->remove($field); $field = $form->get('edit_roles'); if($field) $field->parent->remove($field); $event->return = $form; }

I've been making good progress here on ProcessWire 2.2 which we're targeting for the end of the year. The main drive of this version is adding multi-language support to the admin. This multi language support is being sponsored by Avoine, thanks to Antti Peisa. I just wanted to outline the approach we're taking as well as get any feedback and suggestions you have. The direction taken with multi language support is based on conversations Antti and I had a few months ago as well as feedback from users in the forum. What ProcessWire 2.2 focuses on There are lots of components to supporting multiple languages in a CMS, and the area we're focused on with this version is supporting multiple languages for PW's admin, modules and 3rd party modules. This is so that your clients can make edits to their site without having to know English. While PW hasn't had specific multi-language tools for your front end, it can support multiple languages any number of ways there (as many users have done, with language trees, multiple fields, etc). But the back-end tools have always been in English without an obvious way around that. So the biggest need has been a way to support multiple languages for PW's admin tools, core modules, 3rd party modules, etc. Basically, the non-dynamic side. And that's what PW 2.2 tackles. The direction being used We originally looked at PHP's gettext tools (http://www.php.net/manual/en/book.gettext.php), as they've been successfully used to provide this capability for CMSs like WordPress and Drupal, and they are a ready-to-go solution that is built-in to PHP and adds multi language capability with little overhead. I like gettext() from the PHP side as it's a really easy solution (for coding at least), and it's really efficient from the PHP side. But I felt that it puts a lot of burden on the translators with a lot of technical jargon, file formats and other tools. I want the translation tools to have the same simplicity as the rest of PW, and it looked like that was going to be a hard sell with gettext. Instead, we're using a home-brewed solution that essentially does the same thing as gettext, but is a whole lot simpler for translation. It's simple enough that if you find something that needs translation, you can just go and edit it in PW like you would edit anything else. It also means that these tools will be very simple for 3rd party module developers to use. They will also have use in your own sites and templates for your non-dynamic content. The tradeoff is that it takes longer to code this way (for me) and that it can't possibly be as efficient as gettext (given that gettext is built-in to PHP). Translations take up memory. However, PW, doesn't have files with tens of thousands of lines of code and doesn't need to keep thousands of translations in memory at any given time. When it gets down to the needs of PW and the needs of those using it, I don't believe we'd ever benefit from the efficiency of gettext. So the home-brewed solution won out. The actual solution is coded as a module. So if you don't need anything other than English in the admin, then you'll just leave the 'Languages' module uninstalled. How it works from the admin side The Languages module will be provided with the core, ready for a 1-click install. As soon as you click 'install', a 'Languages' tool is added to your Setup menu, a 'language' template is added to your templates, and a 'language' field is added to your fields and appended to the 'user' template with the default language (English) selected. When you go to Setup > Languages, you'll see a list of languages that are installed. From here you can click to edit a language or click 'Add New' to add a new language. Each language is technically a page (just like with users), so you can add additional fields to the 'language' template should it suit your needs. By default, each language template has a name (ISO-639 code, i.e. 'en'), a title (i.e. 'English') and a 'translations' file field. Each file in this field contains translations for a file in ProcessWire (whether a module, core, template, etc.). These files are created by another module in ProcessWire (to be discussed below) but a files field is provided here so that you can easily share your translations with other people. Likewise, you'll be able to download new language packs from the ProcessWire site and just upload them here, ready to use. How to make a translation ProcessWire keeps track of language translations on a per-file basis. So if you want to translate a file in ProcessWire, you have to tell it which one. ProcessWire will then load the file into memory and look for function calls that indicate translatable text. Then it presents you with a screen of all the phrases it found for translation, along with inputs for providing a translation for each one. See the attached screenshot for an example of this. When you hit 'save', it saves those translations in a JSON file that PW's languages module uses for runtime translation. This JSON file can also be shared with others, distributed with a module you've created, or zipped up with others as part of a language pack. As soon as the English version native to the translated file changes, the translated versions are considered out of date. We don't want to make guesses about the scope of the text change. So your translation screen will show you any existing translations that are considered 'out of date' along with new entry fields to provide new translations. Any fields left blank on the translation screen are considered untranslated and thus the original language (English) is substituted for any untranslated phrases. How it works from the code side I mentioned earlier that I like how gettext works from the developer side, and ProcessWire works in a very similar manner in this regard. Meaning, indicating text as translatable involves a "_" function call followed by the text. ProcessWire also needs a context, so you call this function with '$this'. Here's an example: $value = $this->_('Add New Page Here'); So $this->_('text') identifies the text as translatable. You have to use $this->_('text') rather than the gettext format of _('text') for two reasons: first is that the _('...') function is native to PHP and actually calls gettext, so that's already taken! Second is that ProcessWire needs a context to the function call… it needs to know what class or file it was called from, otherwise all translations would be a global namespace. So ProcessWire figures that out behind the scenes with a context of the calling class and uses the Reflection API to determine the file. If you didn't understand that last sentence, then don't worry because you don't need to–ProcessWire is taking care of the technical details for you. In addition to the $this->_('text') you can use a function format that would most likely be more suitable for translations performed in your template files. In this case, because "_" is already taken by gettext, we use "__" like WordPress does. So you can do this: echo __('Submit Form'); ProcessWire figures out the context of that call automatically and groups the translation with others from your template file. This type of call can also be used in 3rd party modules, but you'll have to tell PW the context, i.e. <?php echo __($this, 'Submit Form'); // these two lines do exactly the same thing echo $this->_('Submit Form'); Best practices for pre-translated text Just like with gettext, when entering text that's ultimately going to be translated, you need to avoid putting in any dynamic things in it. For instance, a string like "Found $count products" is not good for translation because it contains a variable in it. Instead, you'd want to enter such a string as: sprintf("Found %d products", $count). For more details, see the 'Marking Strings for Translation' and 'Best Practices' sections in WordPress's i18n page. They use gettext, but the same applies to us: Marking strings for translation http://codex.wordpress.org/I18n_for_WordPress_Developers#Marking_Strings_for_Translation Best practices http://codex.wordpress.org/I18n_for_WordPress_Developers#Best_Practices New API variables The Languages module installs a new API variable called $languages. It's interface is identical to that of $users in that it can be iterated as a PageArray or you can use get() and find() calls to pull individual languages from it, i.e. <?php foreach($languages as $language) { echo $language->title . "<br />"; } …and… <?php $french = $languages->get('fr'); The Languages module also adds a $language variable to every $user. So you can check what the current language is like this: <?php if($user->language->name == 'es') echo "Hola!"; Of course, $language is just a Page object, so it will also contain any other fields you have added to your 'language' template. Because ProcessWire's native language is English, the language is assumed to be English by default. So if you want it to assume a different language by default for your site, then you would just edit the 'guest' user and select a different language. Next Steps So that's the current state of ProcessWire 2.2 and how it's multilanguage support works. But it's not the only part of it. Because ProcessWire's admin is itself a site developed in PW, and because PW's output is not all non-dynamic, we need multilanguage support in our dynamic fieldtypes and inputfields in order to be truly multilingual. This is what I'll be focusing on in November, so will have more updates on that side of it then. Of course, this side may also be useful for the front-end (your sites) too, though my feeling is that a multi-tree approach is better for accessibility and SEO even if you do have multilingual fields. But even with a multi-tree approach, having multilingual fields will no doubt be useful with shared assets and more. I'm also hoping to have a beta version ready for those that are interested in testing within a month (or in the next few days, if interested in testing before multilingual fields are in place). Please post your questions, suggestions, feedback, etc. This is a work in progress and nothing is set in stone. Edit: added 'New API variables' section.

Gazley, I think appending your special page like you intend is a good way to handle it (PW should take care of duplicated pages in array). And runtime sort sounds good to me too. So this is basically a cheer up post

With regard to your original suggestion, does the link's href get resolved at run-time or by selecting the target page in TinyMCE, does it just literally embed the path as a string so, no dynamic find() call at runtime?

You might try creating a new field using the FieldtypeCache type. This isn't installed by default, but it is included with PW, so you'll just need to click "install" from the modules menu. This field essentially keeps the values from several fields in one field, so that they can all be loaded at once as a group. Like all caches, it's creating duplication and trading disk space for speed. These cache fields are also handy if you are building a text searching engine that needs to scan lots of fields at once... your selector can query just the cache field rather than "field1|field2|field3|etc". Once installed, create the new "cache" field, click to its "details" tab and follow the instructions there. Don't make it autojoin. Instead, have your output generation code reference the cache field field (like $page->my_cache) before any of the others that are triggering queries. This should enable you to reduce it to just one query for all those fields. I'll be honest and say I created this fieldtype with many good intentions, but have rarely found it necessary to use. So be certain the situation you describe really is the bottleneck, and that you aren't omitting pagination or accidentally referencing something like $page->children() or $page/s->find() without a "limit=". The reason that I mention it is that MySQL selects are extremely fast, to the point where the difference between autojoin and non-autojoin may require some scale before you can measure the difference. If you are query counting, avoid doing that, as it often doesn't correlate with performance, especially in ProcessWire. (I used to be a big query counter until I read the book High Performance MySQL, which is reflected in PW's DB query approach). One other idea you might look at is temporarily convincing the fields in question at runtime that they are autojoin, before loading your pages: foreach($selectedFields as $fieldName) { $field = wire('fields')->get($fieldName); $field->flags = $field->flags | Field::flagAutojoin; } That's assuming all the fields in question support autojoin. Some fields, like files/images, can't be autojoined and telling it to may cause unpredictable results.

I love this kind of questions. I think one simple solution would be to have the list of images loaded via ajax (bootstrap PW and return the image array) or render a js object on the album page you will simple use when opening fancybox. Simplest solution for now (other solutions up to others slower posters): Add a link somehwere to the album <a href="#" class="showgallery">Show Gallery</a> The jquery will be like this. $('a.showgallery').fancybox([ {href : 'img1.jpg', title : 'Title'}, {href : 'img2.jpg', title : 'Title'} ], { ..fboptions.. } ); Print that script using php and add the images string on runtime. <?php $imgstr = ''; foreach($images as img) $imgstr .= "{href : '".$img->url."', title : '".$img->description."'},"; ?> $('a.showgallery').fancybox([<?php echo substr($imgstr, 0, -1); ?>], { ..fbconfig.. }); Done. Not tested but you get the idea.

I can't see what fields are in the Range repeater but maybe it's an option to just add a text field to the runtime repeater and just enter the ranges seperated by a delimiter of your choice, so: 1850-1875,1880-1882. You can use explode for front-end purposes. Of course this all depends on your needs. Most of the times when i see nested repeaters is start to wonder if there isn't a better way to structure your content.

Hi, I loathe forms. Wherever possible I try to avoid implementing them. In this case I have no choice and I'm left with an issue I can't figure out - this is based on Ryan's basic form example. I'm stumped on how to send the check box values to the recipient email. It's probably glaringly obvious to most except me. Regards Marty <?php /** * basic-form.php - Example of a simple contact form in ProcessWire * */ // set this to the email address you want to send to (or pull from a PW field) $emailTo = 'email@email.com'; // or if not set, we'll just email the default superuser if(empty($emailTo)) $emailTo = $users->get($config->superUserPageID)->email; // set and sanitize our form field values $form = array( 'contact_name' => $sanitizer->text($input->post->contact_name), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // initialize runtime vars $sent = false; $error = ''; // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate //foreach($form as $key => $value) { // if(empty($value)) $error = "<p class='form-error'>Please completed all fields.</p>"; //} //if(empty($form->$company_name)) $error = "<p class='form-error'>Please completed CF field.</p>"; // if no errors, email the form results if(!$error) { $subject = "A message from the contact form"; $message = ''; foreach($form as $key => $value) $message .= "$key: $value\n"; mail($emailTo, $subject, $message, "From: $form[email]"); $sent = true; } } if($sent) { echo "<p>Thank you, your message has been sent.</p>"; // or pull from a PW field } else { // encode values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // output the form echo <<< _OUT $error <form action="./" method="post" id="contact-form"> <p> <label for="company_name" class="contact_form">Company name:</label> <input type="text" id="company_name" class="contact_form " name="company_name" value="$form[company_name]" size="40" /> </p> <p> <label for="address_1" class="contact_form">Address 1:</label> <input type="text" id="address_1" class="contact_form " name="address_1" value="$form[address_1]" size="40" /> </p> <p> <label for="address_2" class="contact_form">Address 2:</label> <input type="text" id="address_2" class="contact_form " name="address_2" value="$form[address_2]" size="40" /> </p> <p> <label for="suburb" class="contact_form">Suburb</label> <input type="text" id="suburb" class="contact_form " name="suburb" value="$form[suburb]" size="40" /> </p> <p> <label for="state" class="contact_form">State:</label> <input type="text" id="suburb" class="contact_form " name="state" value="$form[state]" size="20" /> </p> <p> <label for="postcode" class="contact_form">Postcode:</label> <input type="text" id="postcode" class="contact_form " name="postcode" value="$form[postcode]" size="10" /> </p> <p> <label for="country" class="contact_form">Country:</label> <input type="text" id="postcode" class="contact_form " name="country" value="$form[country]" size="40" /> </p> <p> <label class="contact_form" for="contact_name">Contact person:*</label> <input class="contact_form required" type="text" id="contact_name" name="contact_name" size="40" value="$form[contact_name]" /> </p> <p> <label for="position" class="contact_form">Position:</label> <input type="text" id="position" class="contact_form " name="position" value="$form[position]" size="40" /> </p> <p> <label for="phone" class="contact_form">Phone</label> <input type="text" id="phone" class="contact_form " name="phone" value="$form[phone]" size="40" /> </p> <p> <label class="contact_form" for="email">Your email:*</label> <input class="contact_form required" type="email" name="email" id="email" size="40" value="$form[email]" /> </p> <fieldset class="products"> <p>Products of interest:</p> <fieldset class="prod_col"> <input type="checkbox" id="Hats" name="Hats" value="$form[hats]" /><label for="Hats" class="Hats">Hats</label><br/> <input type="checkbox" id="Gloves" name="Gloves" value="$form[gloves]" /><label for="Gloves" class="Gloves">Gloves</label><br/> <input type="checkbox" id="Mens" name="Mens" value="$form[mens]" /><label for="Mens" class="Mens">Mens</label><br/> </fieldset> <fieldset class="prod_col"> <input type="checkbox" id="Bags" name="Bags" value="$form[bags]" /><label for="Bags" class="Bags">Bags</label><br/> <input type="checkbox" id="Scarves" name="Scarves" value="$form[scarves]" /><label for="Scarves" class="Scarves">Scarves</label><br/> <input type="checkbox" id="Clothing" name="Clothing" value="$form[clothing]" /><label for="Clothing" class="Clothing">Clothing</label><br/> </fieldset> </fieldset> <p> <label class="contact_form comments" for="comments">If you have any further comments or questions, please complete this area:</label> <textarea class="contact_form" id="comments" name="comments" rows="5" cols="62">$form[comments]</textarea> </p> <input class="contact_submit" type="submit" name="submit" value="Submit" /> <p>* required fields</p> </form> _OUT; } ?>

$category in this code is a Page object (of Page class) so you can add and populate a property on the fly to the objects and use that on runtime. Like a virtual field that isn't saved to page.

Yeah, permissions and ownership look OK. The folder is accessible just fine without .htaccess. Here is the full file: ################################################################################################# # START PROCESSWIRE HTACCESS DIRECTIVES # @version 2.1 ################################################################################################# # ----------------------------------------------------------------------------------------------- # Don't show directory indexes, but do follow symbolic links # ----------------------------------------------------------------------------------------------- Options -Indexes Options +FollowSymLinks # ----------------------------------------------------------------------------------------------- # Let ProcessWire handle 404s # ----------------------------------------------------------------------------------------------- ErrorDocument 404 /index.php # ----------------------------------------------------------------------------------------------- # Handle request for missing favicon.ico/robots.txt files (no ending quote for Apache 1.3) # ----------------------------------------------------------------------------------------------- <Files favicon.ico> ErrorDocument 404 "The requested file favicon.ico was not found. </Files> <Files robots.txt> ErrorDocument 404 "The requested file robots.txt was not found. </Files> # ----------------------------------------------------------------------------------------------- # Protect ProcessWire system files (part 1) # ----------------------------------------------------------------------------------------------- <FilesMatch "\.(inc|info|module|sh|sql)$|^(\..*)$"> Order allow,deny </FilesMatch> # ----------------------------------------------------------------------------------------------- # Override a few PHP settings that can't be changed at runtime (not required) # ----------------------------------------------------------------------------------------------- <IfModule mod_php5.c> php_flag magic_quotes_gpc off php_flag magic_quotes_sybase off php_flag register_globals off </IfModule> # ----------------------------------------------------------------------------------------------- # Set default directory index files # ----------------------------------------------------------------------------------------------- DirectoryIndex index.php index.html index.htm # ----------------------------------------------------------------------------------------------- # ProcessWire requires mod_rewrite # ----------------------------------------------------------------------------------------------- <IfModule mod_rewrite.c> RewriteEngine On # ----------------------------------------------------------------------------------------------- # Set an environment variable so the installer can detect that mod_rewrite is active. # ----------------------------------------------------------------------------------------------- SetEnv HTTP_MOD_REWRITE On # ----------------------------------------------------------------------------------------------- # Optional: Set a rewrite base if rewrites aern't working properly on your server. # And if your site directory starts with a "~" you will most likely have to use this. # ----------------------------------------------------------------------------------------------- # RewriteBase / # RewriteBase /pw/ # RewriteBase /~blah/ # ----------------------------------------------------------------------------------------------- # Access Restrictions: Keep web users out of dirs that begin with a period # ----------------------------------------------------------------------------------------------- RewriteRule "(^|/)\." - [F] # ----------------------------------------------------------------------------------------------- # Optional: Redirect users to the 'www.' version of the site (uncomment to enable). # For example: http://processwire.com/ would be redirected to http://www.processwire.com/ # ----------------------------------------------------------------------------------------------- RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # ----------------------------------------------------------------------------------------------- # Access Restrictions: Protect ProcessWire system files (part 2) # ----------------------------------------------------------------------------------------------- RewriteCond %{REQUEST_URI} (^|/)\.htaccess$ [NC,OR] RewriteCond %{REQUEST_URI} (^|/)site/assets/(cache|logs|backups|sessions|config|install)($|/.*$) [OR] RewriteCond %{REQUEST_URI} (^|/)site/install($|/.*$) [OR] RewriteCond %{REQUEST_URI} (^|/)site/config\.php$ [OR] RewriteCond %{REQUEST_URI} (^|/)(wire|site)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ [OR] RewriteCond %{REQUEST_URI} (^|/)site/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] RewriteCond %{REQUEST_URI} (^|/)site/assets($|/|/.*\.php)$ [OR] RewriteCond %{REQUEST_URI} (^|/)wire/(core|modules)/.*\.(php|inc|tpl|module)$ [OR] RewriteCond %{REQUEST_URI} (^|/)site/modules/.*\.(php|inc|tpl|module)$ [OR] RewriteCond %{REQUEST_URI} (^|/)(COPYRIGHT|INSTALL|README|htaccess)\.txt$ [OR] RewriteCond %{REQUEST_URI} (^|/)site-default/ RewriteRule ^.*$ - [F,L] # ----------------------------------------------------------------------------------------------- # Ensure that the URL follows the name-format specification required by ProcessWire # ----------------------------------------------------------------------------------------------- RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$" # ----------------------------------------------------------------------------------------------- # If the request is for a file or directory that physically exists on the server, # then don't give control to ProcessWire, and instead load the file # ----------------------------------------------------------------------------------------------- RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !(favicon\.ico|robots\.txt) # ----------------------------------------------------------------------------------------------- # Optional: Don't send missing image requests to ProcessWire (uncomment below to enable). # This might be helpful if you are launching a new site and lots of images have moved. # It will reduce the load on the server not to have ProcessWire trying to serve those requests. # ----------------------------------------------------------------------------------------------- # RewriteCond %{REQUEST_URI} !\.(gif|jpg|png|ico)$ [NC] # ----------------------------------------------------------------------------------------------- # Pass control to ProcessWire if all the above directives allow us to this point. # For regular VirtualHosts (most installs) # ----------------------------------------------------------------------------------------------- RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # ----------------------------------------------------------------------------------------------- # If using VirtualDocumentRoot: comment out the one above and use this one instead. # ----------------------------------------------------------------------------------------------- # RewriteRule ^(.*)$ /index.php?it=$1 [L,QSA] </IfModule> ################################################################################################# # END PROCESSWIRE HTACCESS DIRECTIVES #################################################################################################

Hello there! Appreciation First of all I would like to say Thank You for making such a fantastic back-end. In my ten years of web development it's the first one to actually make sense to me. When I used to develop in Flash I was searching every where for a back-end that would just let me output my data as xml without the hassle of learning a new "language" or syntax, or messing with settings directly in the back-end itself. For my current portfolio and some other sites I ended up using Drupal with some plugins for managing the data and then just dug in to the database directly, pulling out whatever i needed. It wasn't easy, but it was easier than learning how to make an actual plugin that did the same. With process wire I realize now I could have saved weeks of development, had I known of it's existence. It was so easy to get into that I basically just sad down a few hours one day to get familiar with the UI and I have only had use for the cheat sheet ever since. This stuff is build in a very logical way and without unneeded complexity. I can see a lot of thought / experience has gone into this, and I really appreciate you letting us use it! Question I have some ideas for new modules that I would like to build. They would add some extra functionality to the core functions of Processwire. One is to implement getID3() (http://getid3.sourceforge.net/) to get the extra data in mp3s like $fileMp3->composer for example. The other one is to add extra image functionality on both the front- and back-end using imagemagick. I'm updating my portfolio to an html5 version and it's going to have a worn down/outdoor look, and therefore I'd like to add some Instagram type of effects to certain images (http://net.tutsplus....lters-with-php/). On the back-end I would like to add options for adding image effects when the image has been uploaded. I would like to keep the original while the modified Image is used by the front-end. Ideally it would be a drop down with some predefined effects while having the option to add more than one effect. Next would be to extend the Image with more options, just in the same way resize works. For example $fileImage->resize(150,150)->kelvin(75, "#4499ff") I'll post what I came up with so far. It's inspired mainly by the tutsplus article and it contains obvious errors, but it's more to give you an idea of what I want to achieve. I looked for an Image class to add a hook to - in the same way that resize works, but I couldn't really find out how it was put together. I also don't quite understand why this module shows up under an "Image" section as I didn't define it anywhere (see attached image). I'm not asking for finished code here, but looking for guidance as http://processwire.com/api/modules/ and the hello_world.module don't tell me what I want to know. Or maybe I'm looking in the wrong place? Anyway, here's the code so far. Any tips would be greatly appreciated! ( And sorry for the wall of text ) <?php class ImageInstagram extends WireData implements Module { public $_image = NULL; public $_output = NULL; public $_prefix = 'IMG'; private $_width = NULL; private $_height = NULL; private $_tmp = NULL; public static function getModuleInfo() { return array( // The module'ss title, typically a little more descriptive than the class name 'title' => 'Image Instagram Effects', // version: major, minor, revision, i.e. 100 = 1.0.0 'version' => 003, // summary is brief description of what this module is 'summary' => 'Add InstaGram effects to images', // Optional URL to more information about the module 'href' => 'http://www.processwire.com', // singular=true: indicates that only one instance of the module is allowed. // This is usually what you want for modules that attach hooks. 'singular' => true, // autoload=true: indicates the module should be started with ProcessWire. // This is necessary for any modules that attach runtime hooks, otherwise those // hooks won't get attached unless some other code calls the module on it's own. // Note that autoload modules are almost always also 'singular' (seen above). 'autoload' => true, ); } public function init() { $this->addHook('Images::kelvin', $this, 'kelvin'); } public function kelvin($event) { $this->tempfile(); $this->execute("convert( $this->_tmp -auto-gamma -modulate 120,50,100 ) ( -size {$this->_width}x{$this->_height} -fill 'rgba(255,153,0,0.5)' -draw 'rectangle 0,0 {$this->_width},{$this->_height}' ) -compose multiply $this->_tmp"); $this->frame($this->_tmp, __FUNCTION__); $this->output(); } public function tempfile() { # copy original file and assign temporary name $this->_tmp = $this->_prefix . rand(); copy($this->_image, $this->_tmp); } public function frame($input, $frame) { $this->execute("convert $input ( '$frame' -resize {$this->_width}x{$this->_height}! -unsharp 1.5×1.0+1.5+0.02 ) -flatten $input"); } public function execute($command) { # remove newlines and convert single quotes to double to prevent errors $command = str_replace(array("\n", "'"), array('', '"'), $command); $command = escapeshellcmd($command); # execute convert program exec($command); } public function output() { # rename working temporary file to output filename rename($this->_tmp, $this->_output); } }

Hi Pete, Many thanks for responding! I don't think I made myself clear. What I was referring to was caching the runtime results of queries, not their definitions, and possibly HTML fragments (generated on the fly) that might be used more than once in the same server-side hit. Know what I mean? Cheers --Gary

I use the .less apps http://incident57.com/less/ (mac, pc also is available elsewhere), that converts to regular CSS when saving (watching files), you can also set it to minify them. I'm not a fan of serverside or js runtime. It's basicly great tool to help using variables and mixins etc to write css.

What do you want to debug? I have to say I have no clue about PHPStorm and XDebug. I think this has not much to do with PW rather than your IDE and PHP. DO you mean a local runtime environement? I think without having PW context there (not plain php) it doesn't really make sense, and something you do while coding templates -> testing in browser, if error go back and check, fix, continue. There's also debug option you can enable in /site/config.php to see errors and warnings. Edit: I think your struggle is also little selfmade, I've never needed autocomplete for something like PW, or debug, lint or anything, just for coding php websites, rarely really have the need as it's so simple. What I sometimes use is a phplint to spot errors in php code right away, but mostly it's just annoying and slows IDE's down.