Soma

You might want to look into that thread http://processwire.com/talk/topic/5145-paginator-and-seo/

With some help you could get it for less. $drinks->get("category=whisky, type=middletons, ice=1"); I like that ass.

Would be great to know what PW version, cause I think this was already fixed long time ago? Edit: doesn't look like, but I don't know what's about it cause there seems to be some 0 ignore in PW with textfields, if you enter 000 it doesn't get saved.

Yeah I'm also here.

It's the nature of Radios in HTML, I've never seen or needed a radio group options to be unselectable. Maybe I'm wrong. Edit: Maybe I've misunderstood your post, ignore me.

I'm not sure and don't have time to test, but the behavior seems correct. All 2th level are affected of course. I think you would want to define a selector for the parent only using "nav_selector" https://github.com/somatonic/MarkupSimpleNavigation#added-support-for-nav_selector-propertyfield-and-selector_leveln-new-in-121 So you could define the selector on the parent "Employees" $pages->get("/employees/")->nav_selector = "employee=1";

Radios aren't made for deselecting, You may use ASM select then?

Does it work without MSN? Usually employee=1 or 0 should work.

Yeah I think the only way (dirty) is to use GET parameter added to each language switch with the language name, so you can know user has switched. I have hard time understanding why you need this kinda weird complex setup and not let the url speak. As I see you use LanguageSupportPageNames... I guess you then use no lang segment set on homepage names? There is this behavior of the default system language when those are set that redirects you to the root url if you enter domain.com/en/ when en is the default. It's kinda hard with this way of doing it, and I'm not sure what the best setup would be as there are so many variations and ways to do a ML setup. I just remember having such session and lang url params projects that was hard to figure out what's happening when something didn't work out or got broken. Too complicated for my simple mind really

As far as I see it's only image/file and maybe page fields that need a page to be existent for custom php code in the settings. If you only use text fields it would be possible what you want. Otherwise you could still create a page with a unique name and redirect to the page edit screen for editing. Something like Pete was doing that was linked to in the thread I linked to.

Damn martijn spamming my links

AWStats just reads the access log from the server, so I'm not sure what your free server has or allows. You'd need access to the access log. There's no such script that can just be uploaded and tracks files downloaded. Unless you use this technique I mention with google analytics event tracking using JS. Or if you make a download file "is a page", so you can count on the template side with php. martijn was faster...

I'm really wondering why this hasn't come up yet. I think it's not a very urgent problem, and for us advanced user anyway not. But for clients there's a chance that they get caught by it, so I think it should be prevented. What I'm talking about is, if you create a new page, enter title and hit enter two times fast, or double click save button. It will save page and try to create a second one, and fail saying there's already existing one with same name.

To not write all over again: http://processwire.com/talk/topic/2696-check-the-template-of-the-page-which-will-be-added/ from two days ago, still fresh... Also it's not possible to edit page directly without saving it first, as some fields require a page ID to function, and that's why there's a page creation screen.

- AWstats installed on most hosting servers is a server-side statistic "tool" for every visits and file accessed. - Google Event Tracking, make a click script that tracks events.

I have upgraded and installed 2.3.8 many times and haven't had this error. Are you sure cache or cookies aren't involved?

Thanks guys for all the great feedback. I've been adding some new stuff and working on many details. I updated my first post with what is used. I've also added a fix for the overflow issue in pre code boxes: white-space: pre-wrap; /* css-3 */ white-space: -moz-pre-wrap; /* Mozilla, since 1999 */ white-space: -pre-wrap; /* Opera 4-6 */ white-space: -o-pre-wrap; /* Opera 7 */ word-wrap: break-word; Thanks for those who decided to follow my blog already, so I just need to write something interesting. But that makes it more fun when you know people are watching.

I added overflow: auto for the poor ones , jk Not sure what's better, but will let it for now.

What Browser? This is handled by the Rainbow JS CSS with word-wrap: break-word; which will wrap long lines.

Thanks guys. @martijn, yes I added some more links @xeto, just added a RSS feed. Let me know if it works out for you.

I just went ahead and did what I wanted to do since a long time. Yesterday at this time there was nothing. Now there's this: http://soma.urlich.ch/ My old portfolio, taking dust, is gone for good! Now I have new shiny blog. Starting with zero, this took a couple hours to setup a complete custom blog. I'm still working out details here and there and adding new stuff I still want to. But what I need and wanted is there now roughly. Some things used in this ProcessWire site: - ModulesManager (of course) - Hanna Code - Repeaters (for the inline code snippets added to content by some Hanna code) - Rainbow JS for the highlighting (http://craig.is/making/rainbows/) - PW Comments Core module - RSS Feed Core module - Markup Twitter Feed (http://modules.processwire.com/modules/markup-twitter-feed/) - Pocketgrid (there's no good grid system other than this http://arnaudleray.github.io/pocketgrid/) - FontAwesome Icon Font No frameworks used except PW. I hope I'll find time to write some things about web dev in general and ProcessWire. Hope you step by now and then.

In some projects I use a mix of the $config->scripts and $config->styles FilenameArray to add scripts in templates. And one similar to the one Ryan, where I can create js and css files with the name of the template and they'll get loaded if existing. In a recent project I use a custom $config->siteScripts = new FilenameArray(); $config->siteStyles = new FilenameArray(); I set in a autoload module. Then I add the script in a template: $config->siteScripts->add($config->urls->templates . "js/yx.js"); This also allows for modules I create, for example widgets (that are not autoload), that need scripts/styles to add them with simply adding the method above in the init(). So as soon as I load the module in the front-end they'll get added to the array. To output, I use the same method as found in default.php from the admin template. <?php foreach($config->siteScripts->unique() as $file) echo "\n\t<script src='$file'></script>"; ?> You could also just use the $config->scripts used in the backend, but if you use form (InputfieldForm) API in the front-end, loading inputfields modules will also load scripts and styles from those in the filename array. This may not desired, that's why I use a custom filename array. For anything basic and global, I add scripts and styles hardcoded in the main template.

There so many ways and use cases. I think with creating your own ProcessPageAdd module like Ryan mentioned would be a way to go, though depends on the case and you might need to maintain it in case the core one has changes that need to be implemented in your copy too. To use existing ProcessPageAdd you can hook into execute or buildForm. The latter being better as it returns the form not rendered so you can manipulate it. The ProcessPageAdd module also stores the template ($this->template) in case the Template family settings is set to only one specific, but this property is protected so you can't read it from outside the module. But you can add your own checks to get the parent and check for the family settings of its template. $template->childTemplates. Then use this info to check if it's your template you want to make changes. If you get this far you can also add fields to the form you wish to. These may even existing fields you are using on your page you create, and they will get saved along with the page add form. Just as an example to do what I said above: $this->addHookAfter('ProcessPageAdd::buildForm', $this, 'hookProcessPageAdd'); public function hookProcessPageAdd(HookEvent $event){ $process = $event->object; $form = $event->return; // get the parent page if(isset($_POST['parent_id'])) { $this->parent_id = (int) $_POST['parent_id']; } else { $this->parent_id = isset($_GET['parent_id']) ? (int) $_GET['parent_id'] : 1; } $this->parent = $this->pages->get($this->parent_id); // get the template via the child templates // if only 1 defined if(count($this->parent->template->childTemplates) == 1) { $childTemplates = $this->parent->template->childTemplates; $this->template = $this->templates->get(reset($childTemplates)); } if($this->template == "post"){ // load an existing field and get its inputfield to add to the form // this will be save to the page if the created page has the field $f = $this->fields->get("date_published"); $inputfield = $f->getInputfield(new Page(),null); // add the field after the page name field $form->insertAfter($inputfield, $form->get("_pw_page_name")); // populate page name field with a timestamp $form->get("_pw_page_name")->attr("value", time()); } } So far so good. The page title field is global and is also used on the page add process, it's also required, so you can't ignore it. It would be possible to remove the title field from your template. To do this you have to make the "title" field not global (field advanced settings). Once removed it will not get added to newly created template, and also you can remove it from any template. BUT there's some drawback, since the title is not global anymore, it will never be shown anymore in the page add process also for other normal pages! This gets kinda tricky. You could remove the title field and after that make it global again, but then it will get again shown at the page add process even if the template has no title field anymore. ProcessWire doesn't know. Also when opening the template you removed the title field previously, it is added again to the fieldgroup, and you can't remove it. See? So maybe best bet would be to leave it alone and just remove it from the add page form in the hook, or just populate it with some value, and later use hooks to concat values on page save to set the title dynamic. $form->remove($form->get("title")); So with all this in mind you could add "firstname", "lastname" fields to the add form with ease. Then use a Pages::added and/or Pages::saveReady to populate the title after adding the page. Or you could also "hide" the title field on the template. When editing the template, click on the title field to open context editor, select for visibility "Hidden, not shown in the editor". This will "remove" the title field on the edit screen. But you can still populate it via API if needed.