ryan

Thanks for finding this elitLG! As you probably guessed, that's not the intended behavior-- you shouldn't have to calls setTrackChanges on your own. Thanks for the good example, I was able to duplicate here as well. I have updated the fieldtypeWakeupValue hook function in LanguageSupportFields.module to have the setTrackChanges(true) so that you don't need to do the above. This is now in the dev branch where it'll run through a little more testing just to make sure there aren't any side effects.

That's correct. If your file system has a limit like that, and you expect to have that large of a quantity of pages (which I don't think we've seen anyone do yet) then you'd probably want to only put file/image fields on the templates where you need them. If you have 60k+ pages, all with file/image fields, chances are you aren't editing them often, so you could also use this module to remove the directories.

I understand the benefits of combining CSS/JS files on a site. There are many places where they can be a real benefit, and fewer places where they may not. ProcessWire admin is one place where it wouldn't be a benefit. The issue with combining CSS or JS files with the PW admin is that the files are rarely the same between requests. It all depends on what process, inputfield and other modules are requested by the action. There could potentially be dozens, hundreds or thousands of different combinations (depending on your site). So combining these would be adding overhead rather than reducing it, as we'd be losing much of benefit of browser caching. Compare that to what we're doing now, where the browser can retrieve these files once, cache them and then use them in any combination without having to re-retrieve them every time the combination changes. ProcessWire loads things on-demand, so the selection of CSS/JS files in any request can change a lot. We want the browser to cache them individually so that they can continue to be used on every request without reloading.

Some recent additions for 2.3 that are now in the dev branch (I could use help testing if anyone has time): Added "required" support to all fields I've enabled required field support for all fields in ProcessWire (no need for advanced mode either). Now you get a "required" checkbox on the "input" tab of any field in Setup > Fields > [field]. If you are dealing with a published page and save it, you'll get an error if any required fields are blank. The page will still be saved. So it's more of something to annoy you into completing the required field. But if you are dealing with an unpublished page, it won't let you publish it (in the page editor) until you complete all required fields. While seemingly a small thing, the scope is more broad than it sounds as it applies to a lot of different Inputfields. I could use help testing this one out to make sure I haven't missed anything or introduced any new side effects or issues anywhere in ProcessWire. Other additions Fieldsets can now take advantage of column widths, enabling you to have multiple fields in a column. Fixed some bugs that occurred with fieldsets in tabs and fields getting brought into fieldsets they weren't supposed to. Add Interrobang's PHPdoc comments. Add ability to disable PW from throwing an exception when you call an unknown method (for porl's Twig module and other future ones like it). Clean up and optimize the /wire/templates-admin/styles/inputfields.css - it had some redundancy before. Also added a style to call out required fields. Other admin themes may want to do something similar (see the InputfieldStateRequired style in that file). Some other small things in the commit log (Apr 07-Apr 12)

I think that letter case for "n" might possibly cause this if statement to fail. It would have to be "NullPage" not "nullPage". But I agree with Antti that checking $page->id instead is probably easier and less prone to typos, etc.

@Pete, looks good to me. Earlier this morning I had plugged in something very similar into the default profile. I've just got it in the dev branch right now, along with a bunch of other updates.

This was there before I think, but I don't think it's what we want (?). It's the latest posts that people are looking for in this field rather than latest topics. Now it seems to be feeding us a combination: topics that have the latest post in them, but instead giving us the first post in the topic (which may be old). That seems confusing to me, which is why I left it out of the original feed. Ideally it would give us the actual latest post, but I didn't see that option in IPB. Seems like a strange omission? There must be some technical reason for it.

PW uses the .module extension for the same reason Drupal does... so that the file can quickly be identified (by PW's module loader) as a file containing a plugin module rather than some other PHP file. We've had a request to make it also support .module.php, so will likely be adding this shortly in the dev branch. But for now my suggestion would be to set your editor to recognize .module as a PHP file. For instance, I use VIM and place this in my .vimrc file: set nowrap syntax on au BufRead,BufNewFile *.module set filetype=php

The scope of Google Analytics is so broad, I don't think I'd ever expect something outside the GA app itself to implement it. Take the Real Time features for instance. You've done a great job of implementing the most important and most useful stuff. If I had to wish for anything it would only be that I could get more detail on the referrers. Like when I see a new referrer show up, I'd love to click to see the URL where the referring link actually exists. Sometimes I can't even do this in GA since it strips URL variables... leaving me to grep my access log to find the actual referring URL. But if there's some way to see not just the domain, but the path too, that would provide the same level of detail present in GA. I'm not sure what the best behavior would be here, as I'm guessing everyone has their own workflow and timeline they want to look at in GA. But I do know that the first thing I do when I get into GA is to set a date range. It's rare that I want to look at the last month or year. Usually I want the last 24 hours, last 2 days, last week, etc. I've often wished that GA had a select box where I could choose "last 24 hours" for instance, rather than having to select starting and ending dates.

I agree with Soma's reply. Also wanted to mention you could always register your own autoload function too. In my case, I either go the route of including a "tools.inc" file at the top of my templates that has all my shared functions (and/or classes if needed), or I use the module route as Soma mentioned.

Great update! I love the way it works with the tabs now. Not seeing the overflow issue anymore either. This covers about 90% of the things I use GA for. This module will get a lot of use for sure.

Good idea. I will plan to add this to the default profile too and we can recommend that people include the generator tag in their own sites...perhaps as a prerequisite to being listed in the upcoming PW site directory? This would make sense so that if the generator tag ever changes we know the site is probably not running PW anymore and shouldn't be linked from the directory.

See the $session variable. You can store objects, but always have to be careful, like with objects that may reference others and ensuring those object's class definitions are present before they are instantiated in the session. ProcessWire's $session isn't much more than a wrapper on top of PHP's $_SESSION, and you can still use PHP's $_SESSION if you want to. More about objects in sessions here. Personally, I prefer to recreate objects myself on each request. It should be possible to do what you are asking to do but the details of it will be PHP-specific rather than ProcessWire-specific.

Good to know we've go more in North America than I thought. Just testing the waters with the plans here, so not sure where we'll eventually do it, but the locations I mentioned seem the most likely place since my client is making it available to us (something that could keep our costs way down). Ultimately if there's demand for it, we'll do it here in North America too. Though I'm still debating if we're big enough as a project to warrant a conference yet, but we're definitely getting there.

We were on opensourcecms.com for a couple of months and slowly rose to the top of the ratings with a few hundred legitimate votes. Then overnight we went to the lowest rated with more than 2000 votes coming in a manner of hours. Basically, some Joomla fanboy decided they didn't like PW's rating and decided to slap it down to last. We eventually figured out that the site's ratings were heavily manipulated and we even figured out how to do it and notified the owners of the site about the exploit. While appreciative, I don't believe they have actually fixed it yet. So we choose to keep ProcessWire away from there until there is an honest rating system. People do actually give legitimacy to those ratings, and I want to disassociate ProcessWire from anything dishonest. For the record, we are not the only CMS project that is intentionally staying off opensourcecms.com. Also want to mention that opensourcecms.com is under new ownership (by a company associated with Typo3, I think) and they seem to be good people, so hope we can pursue getting back on opensourcecms.com someday in the future, but don't want to consider it till the system is cleaned up. So far I've seen a redesign, but not a re-do of the way ratings are handled.

Last I checked it wasn't and the RSS options seemed a bit limited. But Pete's been putting in some upgrades to the forums lately and so this may have changed. I will make a note to check this when I get back unless Pete already knows the answer.

If you do actually have a directory called /ProcessWire/ and you are accessing the URL /processwire/ then it doesn't matter if your OS is case sensitive as it's Apache that's connecting URLs to directories, not the OS. I'm running on MAMP in OS X and it is not case sensitive with the URL paths, meaning /ProcessWire/ is no different than /processwire/.

Here's more detail on the options WillyC mentioned: http://processwire.com/api/fieldtypes/comments/ For example, to set a new action attribute for renderForm so that it posts to a page called /post-comment/, you'd do this: $options = array('attrs' => array('action' => '/post-comment/?id=' . $page->id)); echo $page->renderForm($options); Then your post-comment template could do something like this: $id = (int) $input->get->id; if(!$id) throw new Wire404Exception(); $p = $pages->get((int) $input->get->id); if($p->id && $p->viewable() && $p->comments && count($input->post)) { // process comments echo $p->renderForm(); } else { throw new Wire404Exception(); }

That's correct. Just to reiterate what WIllyC was trying to communicate -- WireArray is an Array meant to store Wire objects. If you need to store something else, then regular PHP array is your best bet.

If you don't need to have the user maintain any specific profile data or password, etc., then you can also just create one user and use it to represent all your social service logins. Or you could create one per service (facebook, g+, etc.). This only works if the user can't change anything on their PW account. It's basically the same thing that PW is already doing with the 'guest' user and role, assigning that user to anyone not already logged in.

This isn't far off from what PW is trying to do, at least relative to other systems out there. The only things we have in root are: /index.php /wire/ /site/ /.htaccess There are a few readme/txt files in there, which of course are just for initial reference and don't need to stick around with the site. It is no problem to make your /wire/ a symlink to a shared /wire/ directory located somewhere else. But probably best to keep /site/ where it is.

I'm guessing it's not the CSRF protection, but that's a good thing to mention too. If that CSRF error was the one that you are getting, you can disable CSRF protection by adding this line to your /site/config.php: $config->protectCSRF = false; However, I would check the sessionName and sessionFingerprint considerations first, as a CSRF error may be a side effect of a cookie conflict too.

PW doesn't care where you run it or whether you move it between subdirectories, etc. So you should be fine. The only thing you need to consider is local links you may have in a TinyMCE field. Since that is raw HTML that TinyMCE uses, it may have direct links in it (if you've inserted images or links through TinyMCE). In that case, you'd want to do an search/replace on your DB dump file replacing "/ProcessWire/" with "/", before importing to your live site. There is also a module that can manage this for you called PageLinkAbstractor (currently being re-worked under the name LinkManager). But this module is one you have to start with and stick with, so probably not as helpful here. But I usually just do the search/replace when migrating from a local subdirectory site to a live root level site. Again, only necessary if you've got image, file or URL links in your TinyMCE rich text fields and are switching from subdir to root.

I agree with DaveP that it does sound like there is some sort of cookie conflict in your domain. I don't think copying and pasting between tabs should be a problem at all. Are you working with two different copies of ProcessWire on the same domain? If so you'll want to change your sessionName in /site/config.php for one of them. Does your IP address change during the session? If so, you want to disable sessionFingerprint in your /site/config.php

Looking good! Thanks for posting this. I look forward to seeing this one in the modules directory. I think the reason your fx() function is getting called twice is because there are likely two hooks being attached to Pageimage (as a result of your init being called twice). I'm guessing that you have two image fields using this fieldtype? So your init() is getting called twice and two hooks are getting added. If you are keeping this as a Fieldtype, you may want to move your counter to the init() function or use self::isHooked('Pageimage::fx()'); However, I'm also wondering if this module might be better on it's own rather than extending FieldtypeImage? At least, I don't currently see a reason for it to extend FieldtypeImage, though I may be missing something or you may have more plans yet. But am thinking that your function would only get called once if it weren't extending FieldtypeImage.