ryan

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.

Nice module slkwrm! Don't forget to add to the modules directory.

I like MadeMyDay's solution. A couple other possibilities are: 1. Use MarkupCache rather than template caching. That way you can cache just the parts of the output that you want to, and leave the things like your counter uncached. 2. Create an autoload module. Add a ready() function to it and have that function increment the counter of $this->page (using the same method you are already doing).

I'm not sure why you'd be getting a Page by accessing that, I would think it should be null. What do you see from get_class($repeater->images)? However, I want to mention that Pagefiles/Pageimages aren't indexed by number, they are indexed by filename, so am thinking at the moment that $images[0] may not relate to anything. $repeater->images->eq(0) is probably what you were after, or $repeater->images->first().

It's also just fine to use jQuery UI tabs if you prefer. WireTabs are mainly useful for tabbing PW's Inputfields, which jQuery UI tabs don't let themselves as well to.

I think the same applies whether site profile or not. Where have you written all your code? I'm guessing primarily just /site/templates/* but possibly /site/modules/ too.

Just wanted to clarify that it keeps the template names and meta data in memory, not the template files themselves. If you are seeing the basic-page.php file open in your debugger, and a page using that template is not being rendered, that doesn't sound right, so let me know.

The simplest solution would be to just put the 'featured' page reference on your homepage, and select the featured page from there (via a PageListSelect input). But if you need to do it from a featured checkbox on the actual page being featured, then you might want to add another component to finding the featured page: $featured = $pages->get("featured=1, sort=-modified"); That would pull the page that was most recently modified and featured. It would also be relatively simple to un-feature pages via a module or in your template, etc. $allFeatured = $pages->find("featured=1, sort=modified"); $featured = $allFeatured->pop(); foreach($allFeatured as $p) { $p->of(false); $p->featured = 0; $p->save(); }

PW keeps the meta data for all the templates and fields in memory. So I would expect to see basic-page somewhere in there whether it's used or not. This is basically just caching. Templates and fields aren't assumed to be infinitely scalable in quantity like pages are, so we take advantage of the performance benefits of having those things ready-to-go in one query. However, you shouldn't see any "template files" loaded that aren't being used in the request.

I think you guys are right on about this. I remember years ago (1990s?) I was using a full blown IDE, debugger and profiler. But I've rarely used such things in PHP. I suppose from-scratch debugging in PHP is a lot simpler than things I've used in the past, so it just hasn't come up as a need. I did experiment with XDebug years ago, but seemed like it was costing me more time than it was saving. Now I'm curious again, thinking I might benefit from a PHPStorm + XDebug setup in some situations (like mindplay.dk has mentioned as well).

Awesome module and really nicely produced! Thanks for making this. I ran into a couple really minor things, but figured I'd mention them before I forget. 1. Saw a couple PHP notices at the top of the screen, but can't remember exactly at what part. However, I'm guessing anyone with debug mode on will see the same. 2. Getting an overflow on the search keywords screen: Great job with the module and the code.

You'd just want /site/templates/ right? Or perhaps /site/modules/ too if you've got any module dependencies in the templates. If you want to make it installable as a site profile, then you'd want to run the site profile exporter and include the /site/install/ directory too. But you'd want to double check that none of your module-specific passwords are getting included in the profile.

The size() function is basically returning a brand new Pageimage object, so if you wanted kelvin to do the same, take a look at the size() function in /wire/core/Pageimage.php -- let me know how this works out.