ryan

This module installs a page on your Setup menu in the admin where you can manage comments (assuming you have a comments field installed). Download from the modules directory at: http://modules.processwire.com/modules/process-latest-comments/ Features include: Easily find the latest comments needing approval or moderation. Shows comments from all pages on 1 screen, paginated and in chronological order. Enables you to change the status of any comment, edit the text or delete. Filtering by status/type, cite, email or IP address Screenshot: I've been wanting to build this for a long time, and something like this should have been there from the beginning, as it's a bit tedious to keep track of all your comments on a large site without this. So this module may be moved into the core for version 2.3, in which case it'll be renamed to ProcessComments, so as not to conflict with those that may have this installed.

Soma is correct that you can set the "visibility" to "hidden" in the field settings, and then the field can exist on the page but won't appear in the page editor.

Which module did you try to install? Do the errors persist even after restoring the default admin theme? What admin theme did the errors occur in? I'm not sure I've got enough understanding of the problem to know what solution to offer, so the more you can post about it the better (screenshots of the error messages might even help). But since you mentioned an issue that started as the result of installing a module, you've got me curious about what module could do this. One thing you might try is to go to the Admin > Modules and click "Check for new modules" as that will reset the cached module information. If you can't access that screen, let me know and I can tell you how to do it manually too.

You may also be able to setup an automatic sort by editing the repeater's template file and setting it under the 'Family' tab. Note that the repeater templates aren't visible in your templates list at first so you'll need to check the box to "show system templates" in the filter menu.

It's been awhile since I looked at this, but I seem to recall some issue with DOUBLE going back into PHP that wasn't an issue with FLOAT, so put it off to research later. I need to take a closer look again. But what you did by modifying the schema directly towards your needs is a fine way to go in this case. ProcessWire is not going to go and change your schema back or anything (unless you change the fieldtype), so it should be safe. But please let me know if you run into any issues with losing precision on the DOUBLE when going to/from PHP.

Repeater fields can't be cloned yet. I couldn't find a way to make it workable in the short term, so I set it to throw an Exception if you try to clone an repeater field (preventing the clone from happening). It could be that you have one of the versions between when repeaters were added and when the repeater cloning issue was discovered, so you may want to upgrade to the latest. Though let me know if this is occurring even on the latest version. But I think that's very likely the issue, and that you need to create those fields without the clone. Please let me know what you find.

I think the question might be too broad for me to know if I'm answering the right thing. But if you are able to get a URL to the thumbnail, you can always add it to a ProcessWire image field like this (assuming your field is named 'images'): $page->images->add("http://domain.com/path/to/file.jpg"); Or if it's a single image and output formatting on: $page->image = "http://domain.com/path/to/file.jpg"; The first example is more likely the one you'd want. When you save, it should download the image and put it into the system.

These things aren't in the repeater at present. But the repeater fieldtype is still in it's first version, so will be expanding upon it and these seem like good ideas.

I'm not sure about the implementation side in this module, or whether this is a good idea for the module or not. But on the ProcessWire PageList side, the client would have to lack view access to the pages in order for them not to see them in the tree. That could also be handled on the fly by the module with a hook to Page::viewable. There may be other ways too I'm not yet thinking of.

SmartyPants is separate from Markdown, though the two often go together. I think they are both originally from the same author actually. SmartyPants just adds auto replacement of regular "quotes" to curly “quotes”, replacement of straight apostrophes to curly apostrophes, replacement of 3 dashes to em dashes, replacement of two dashes to en dashes, and replacement of 3 periods to ellipsis. As far as I know, the language support is limited to those that would use those characters. Since what SmartyPants does is all pretty simple, it wouldn't be too hard to make a textformatter plugin for another language that does something similar. I think the quotes and apostrophes are the only ones that require some context logic to make sure they are going where they should and not where they shouldn't.

Thanks for posting this, these seem like some useful additions and some good insights on sitemap.xml too.

This thread started as a result of our 1500th post, and we are now well over our 15,000th, in a relatively short period of time. Now thinking of the huge celebration we should have when we reach our 150,000th post. Thanks to everyone here for making this such a great community! --- Edit: I removed the 500th member thing, as Pete correctly pointed out to me that the system still has some banned users in it, so we don't have a way of telling exactly who the 500th real member is. Sorry Ralph99.

I've put together a Process module skeleton that may be good as a starting point for any Process module. It is well commented and fully functional as a demonstration. It also includes instructions on what to do with it when using it as a starting point for another module: http://modules.proce.../process-hello/ I'm planning to make more skeleton modules to cover all the bases.

That comment is still the old version before the page was saved. You might need to re-retrieve it from the page in order to get the version with the populated ID. But this may be something you could just drop into your existing code without having to change much else: $email = $this->db->escape_string($comment->email); $status = Comment::statusPending; $result = $this->db->query("SELECT id FROM field_comments WHERE status=$status AND email='$email' ORDER BY created DESC LIMIT 1"); $comment_id = 0; if($result->num_rows) list($comment_id) = $result->fetch_row();

Thanks for posting- Looks good. We don't have anything like this yet, so I'm sure this'll come in handy!

It's quite a mystery. Can't say as though I've seen something like this before. It has me wondering if there is some mod_security setup or something else that is interfering with the usual behavior... that's the only thing I can guess, but I'll keep thinking.

Marc is this server running Apache or some Apache clone? The reason I ask is that it's not behaving like Apache. ProcessWire should never get control of the request due to these two directives: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d That basically says: "In order to give control to PW, the requested file or directory must not exist." So assuming it's actually Apache and it understands those directives, we have to look at why it's not associating that with what's actually on the file system. I would probably try adjusting the RewriteBase line to be "RewriteBase /". If that doesn't work, you might want to look at enabling the VirtualDocumentRoot line (at the bottom of the htaccess file). The 'nobody' permission should be okay. That's most likely the user that Apache is running as. You've got me curious please let me know what you find.

You could also try turning of session fingerprinting from your /site/config.php. Fingerprinting keeps track of your IP and HTTP user agent, and destroys the session if either changes. That sounds like what's happening to you. /** * sessionFingerprint: should login sessions be tied to IP and user agent? * * More secure, but will conflict with dynamic IPs. * */ $config->sessionFingerprint = true; // change to false

I'm running 21k pages on one site right now, and no difference in speed than if it was running a dozen pages. Though of course, I'm not doing anything that loads all those 21k pages at once (I don't think that would even be possible).

That's pretty bizarre. Have you tried another browser, just in case something is going on with the cache? Also, none of the URLs you mentioned have trailing slashes--try adding one (if you haven't already). Can you give us an "ls -al" of the piwik directory and the contents within it? I'm interested to see the permissions and what's in there.

The $event->arguments is just an array of arguments that were passed to the function you hooked, in the order they were passed to the function. You can also retrieve them by name if you prefer, i.e. $event->arguments('page') would retrieve the argument named '$page'. In addition to being able to read these arguments, you can also change them if your hook is a "before" hook… letting you modify what ultimately gets sent to the function you are hooking. There's also $event->object, which is the object instance containing the function you hooked. So in the example from my previous post, $event->object would be $pages. That's probably not very useful, but when dealing with hooked methods on other things (like a Page or a PageArray) it might be exactly what you need. Lastly want to mention $event->return. If your hook is an "after" hook, then $event->return will contain the value returned from the function you hooked. Like with arguments you can modify this value if you want to. If you add a hook somewhere, and there isn't any function to hook, then you've just added a new function to that class. When someone tries to call that function, it'll call your hook instead. There are other things you can do with hooks too, like add properties to an object (rather than just methods) and entirely replace a function with your own. But these are less used things.

Thanks joshuag. The PageLinkAbstractor module has been expanded and renamed to LinkMonitor. I've been using it for a couple of weeks locally and still have a few bugs to work out, but overall I think it'll be a nice addition. Has anyone had a chance to try out the dev branch yet? I'm thinking about merging it into master here pretty soon, and just want to make sure I'm not the only one that's used it.

I think that's the first installation I've seen using the new Blog profile. Good to see.

One other thing about this module that's maybe interesting from a module development standpoint: It installs a page (/service-pages/), and the template for that page loads and runs the ServicePages module when it is viewed. So it installs the means to run itself, and it's not autoload. I might be wrong, but can't think of another module that does this, and maybe it's a good pattern. At least, I thought it was fun when building it. I've been thinking about building a module starter kit that includes skeletons for various types of modules and install/uninstall patterns (ready to build from), and this type of pattern would be one among a few others.

The recursive loop comes from your $p->save(); which is again triggering your pageSaved() hook, and continues doing so infinitely to a deeper and deeper level. There's probably a bunch of ways to solve this. But here's two really simple ways. First is to just set some landmark variable (we'll call it skipMe) so that your hook will know to skip over pages that it is creating itself. Your landmark variable (skipMe) doesn't need to be a PW field or anything, as you can make up any name/value on the fly and set it to a $page for temporary use like this. public function pageSaved($event) { $page = $event->arguments[0]; if($page->skipMe) return; $p = new Page(); $p->template = 'basic-page'; $p->parent = '/about/'; $p->status = Page::statusUnpublished; $p->title = "This is the pagename"; // set some landmark so pageSaved knows to skip this one $p->skipMe = true; $p->save(); } The next option would be to just have your $p->save(); skip over all hooks: $p->___save(); When you call the function name with 3 underscores in front of it, it does so without executing any hooks, thereby preventing the infinite loop. However, this may or may not be what you want, because it would also skip over any other Pages::save hooks that might be present.