ryan

If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file: ini_set("session.gc_probability", 1); ini_set("session.gc_divisor", 100);

You might want to also look at using the YouTube/Vimeo Textformatter module on your body field. It includes a responsive option as well in the module settings.

That should work. You could also do it this way: $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $pages->get((int) $idioma_id); if($p->id && $p->viewable()) $page->htl_idiomas->add($p); } However, something that is missing that you definitely want to add is more validation. Meaning, check to make sure that the pages you are adding to itl_idiomas are in fact the pages you intend. This prevents the possibility of someone manipulating the POST values to include page IDs outside of those you allow. So I would do this instead: $idiomas = $pages->get('/tabla/idioma/')->children(); $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $idiomas->find("id=" (int) $idioma_id)->first(); if($p && $p->viewable()) $page->htl_idiomas->add($p); }

I don't think we are changing any defaults in this area, unless Antti can think of anything? But we are using the 4.1 (dev) rather than the 4.0 (stable) version of CKEditor, so maybe that's where the difference comes from. As far as I know, CKEditor doesn't have that capability. It's possible there may be a CKEditor plugin that provides it though, but I've not seen one yet.

One thing I want to mention is that you don't want to actually have a field of your own called "status", just because that is already a built-in field for every page. That is on our reserved words list, so I don't think PW will let you create a field with that name, but just wanted to mention it.

User information is not stored with files/images at present. However, you may want to install Teppo's Changelog module and Netcarver's Field change notifier module, which may accomplish some of what you are looking for.

Marc, you may want to change your hook from "save" to "saveReady" or "saved". If you use "saveReady", then you won't have to perform your own $page->save(); since you'd be hooking in right before $pages does it's own save. This is the same as a before "save" hook, except that it's been confirmed that a save will definitely occur, so a little safer. However, you'll probably want to add something at the top of your hookSave() function like: if(!$page->id) return; so that it doesn't get involved with pages that are about to be saved for the first time. If you use the "saved" hook (available in the dev branch of PW), this is essentially the same as what you are already doing, just a little safer, since it wouldn't get called if an error occurred in save(). Though for most practical purposes it's equivalent. I would probably look into using "saveReady" just because that could reduce what's currently happening in 2 saves to just 1.

Previously this worked in Firefox and IE, but not in Chrome/Webkit. However, if you are using the latest Chrome and the latest PW (dev), it now works there too (thanks to a recent update from Soma).

Thanks Diogo, I've corrected that. Those quick start tutorials were written by somebody that never finished them... and they were written back for the original PW 2.0, so I'm not surprised there might be errors in there. I need to take some time to go through these for QA, because I don't think the author is going to finish them. But people seem to like them... every time I remove them, somebody gets upset.

While they can't be included in an actual language pack (which is meant for translating the static text in PHP files), they can be exported as SQL dumps. The profile export module was written before multi-lang features existed in ProcessWire, and I need to update it to support it. But it should be fine to create your own SQL dump with translated field names, etc., and import that (via mysqli client, phpmyadmin, etc.) when needed.

It's worth mentioning that wire('input') or wire('any API variable') would in fact work everywhere. So if you only needed to remember one way of accessing API variables, that one would be the most portable.

Selectors have to have a defined value after the operator. There is no defined value in "modified>created", as those are two fields. You can go straight to SQL to accomplish this one: $pageIDs = array(); $result = $db->query("SELECT id FROM pages WHERE modified>created"); while($row = $result->fetch_row()) $pageIDs[] = $row[0]; $pageArray = $pages->getById($pageIDs); // $pageArray contains what you want

At the top, I'm thinking you want to add something to avoid acting on pages that aren't of your defined type. Something like this: if(!$page->template != 'project') return; Because this is a single-page reference field (from what I can tell above), I don't think this line would work: $page->project_status->remove(1157); That's calling the remove() method of $page, which just unset a value. Since the page likely doesn't have a variable named "1157", the line above essentially does nothing. What you would want to do instead is set project_status to be a blank value, or another page. $page->project_status = null; // this $page->project_status = $pages->get('some other page'); // or this

Sounds like a typo, is that would only work on an image field set to contain a max of 1 image. Where did you find it?

Since you are using the PageEditPerUser module, I'm thinking you'd want to edit that one rather than Page Edit. Another alternative is that you could just setup alternate templates, since access is managed there by default. But if you go the PageEditPerUser route, you'd want to modify it to hook into "Page::addable" in addition to the existing Page::editable. The "Page::addable" hook works in basically the same way as the editable one. If you want to see the default logic built into it, the Page::addable function can be found in: /wire/modules/PagePermissions.module

Thanks Michael, I have updated it to have the Sourcedialog plugin and that seems to work nicely. It is now the default option when creating new CKEditor fields. If you've already got CKEditor installed, you'll need to make a couple replacements in your "Setup > Fields > [field] > input" tab. In the "CKEditor Toolbar" field, replace "Source" with "Sourcedialog". For "extra plugins" replace "codemirror" with "sourcedialog" (or just add sourcedialog if codemirror isn't there).

Some additional updates posted to the LanguageSupportPageNames module. Previously you could only define multi-language page names after the page already existed. Now you can define them when you are adding the page. See screenshot.

Didn't realize that Chrome supported in-editor resizing. That's new. It didn't used to. Thanks for finding it and for the PR, I'll check into this here this week.

It looks okay to me. I would double check that $timestamp is an integer (which PW wants if you set it as a literal unix timestamp), so you may want to typecast it: $timestamp = (int) $timestamp; PW will happy take a string or integer, but if it's a string, it assumes it has to run it through strtotime() first. Whereas if you give it an integer, it knows it's a unix timestamp and doesn't attempt to translate it.

Joss–you are the man! You just made my day. I completely missed this before (I have Flash disabled). I came back to this thread to revisit some music links that people are posting. Thankfully one of Soma's messages here made me start to wonder if I was missing something. I'm completely floored you made a ProcessWire song, that's just awesome– Thank you for doing that, I love it!

Is 'timestamp' a field in your system, or one that you are assigning purely for runtime use?

Nico, I don't think that you can catch an include like that. You probably have to set a custom PHP error handler to capture it. It sounds like what you are getting is ProcessWire's error handler.

I don't think this error is coming from the Concatenate fieldtype, because it does not deal with the file system. I'm also not familiar with what a ".frm" file is? It sounds like there must be some other 3rd party module installed that is triggering this error, but I don't recognize the error or filename format. What modules do you have installed that might be manipulating files?

I think it's good to initially develop things in an isolated environment so that there aren't too many factors to consider. Especially with something fairly complex, as this sounds. So that's why I was thinking building it front-end and getting it working is a good way to get started. And once you've got that, converting it to another environment (like an Inputfield) becomes simpler. Yes, a Fieldtype can give an Inputfield a copy of the $page being edited. But as for "live" changes, you'd have to use Javascript, just like anywhere else. Modules are easy -- just a matter of filling in the required components. It's the other stuff you are talking about that sounds more complex. But if you want to learn more about module development, have a look at the /site/modules/Helloworld.module file. This wiki page on module creation is also a good intro: http://wiki.processwire.com/index.php/Module_Creation

There's also good old wget with the recursive option: wget -r http://domain.com