teppo

@Macrura: if I'm getting this right, you're just adding a page to a PageTable field, and when Version Control is installed, this fails with a 500 error (internal server error). The page (review) itself gets added and saved properly, apparently. To be clear, which template did you remove from Version Control enabled templates -- the one used for reviews or the one containing the PageTable field? Also, is there anything added to the error logs of Apache or PW? I was kind of assuming that this module would attempt to store values for the PageTable field itself, which could've easily resulted in an error (don't think that I ever tested that), but since it's not in the supported fields by default, that's unlikely. Unless you've manually added PageTable to the list of supported fields? Any additional info would be helpful. I'll continue testing, but at the moment I'm kind of lost here, and haven't been able to reproduce this issue. Edit: added PageTable to supported fieldtypes locally. Doesn't work (as expected), but doesn't seem to break anything either. Will continue debugging.

Also: http://modules.processwire.com/modules/inputfield-textarea-markup/. Self-promotion, again

I guess this counts as "on the web": http://www.phparch.com/magazine/2014-2/december/.

@apeisa: definitely. I've been test-driving a few locally-hosted solutions, with mixed results (some were "kind of useful", but none really convinced me). Sensio Insight seems interesting alternative, though so far it seems to think that my code is safe, which is a huge red flag to me .. oh, and for the record: programmatic vulnerability scanning is helpful, but I'm always a bit worried that people could trust it too much. There are too many logical issues for it to be "perfect", and thus it might give some users false feeling of safety.

This is the key point here: API. It improves the security a lot compared to having to rely on plain SQL, which is always more or less prone to human error, leading to injection vulnerabilities, etc. Another thing is that most modules seem to avoid potentially harmful methods like exec, shell_exec, passthru, etc. Not sure if that's really anything specific to ProcessWire, though Anyway, one can still easily write a ProcessWire module that trusts user input too much, or trusts input from wrong users, or simply displays too much to unauthorised users. This is why some sort of security audit process would be most welcome, though perhaps as an addition, not something that automatically applies to every module submitted to the modules directory.

Hopefully we won't be going to 2.6 without, at least, merging some things from current dev branch to master (2.5). Just saying. New features are one thing, but there are also bugfixes there, as far as I can remember correctly. IMHO minor versions (x.x) should always be stable and contain no known bugs. Unless support for 2.5 is dropped instantly when 2.6 comes out, which I hope we won't be doing -- upgrading from one minor version to another shouldn't be required just to get bugfixes in

The gelocation snippet I built earlier was purely on the frontend (JS). Didn't want to host (and keep up to date) the IP database locally, and wanted to avoid extra load and delays server-side. Drawback, of course, is that it might not work (sometimes the user just won't get redirected) and the redirect always happens after the page has been loaded (whether the delay is noticeable or not). Whatever way you go, there are still issues to deal with

Looks like this could come in handy. Just recently wrote a snippet to do the same via ipinfo.io, but db-ip.com seems to be at least cheaper. Do they provide HTTPS support, or is it just plain HTTP? Didn't see that in the docs Also, is there particular reason not to use WireHttp? Mostly out of interest; probably won't matter much in real use.

No worries, we've all been there. Glad to be of help

@mrkhan, there seems to be a slight misunderstanding here. Your $pid isn't page ID, it's a Page. You don't need $pages->get() to grab the page, you already have it. // title of the page echo $page->page_side_menu->title; // URL of the page echo $page->page_side_menu->url; // body field of the page (assuming that it has field called body) echo $page->page_side_menu->body; // .. or, if you really want to store it in $paged first: $paged = $page->page_side_menu; echo $paged->title; See what I mean?

There's no need for $pages->get() there; if your page_side_menu field is a page type field, it should already contain reference to said page. In your case "echo $page->page_side_menu->title" should be enough, though you'll first want to check that it actually has something selected. This also depends on how this field is set up, i.e. can it contain one page or multiple pages, does it return NullPage or just null when empty, etc. Check the field settings for these. .. oh, and the source of your problem is actually that if you output (echo) a Page object, which this field probably contains, ProcessWire will automatically output it's ID (see the ___toString method of Page object), but if you give it as an argument to $pages->get(), it's used in it's original object form, which probably won't work there (because it makes no sense at all).

@kixe, have you seen this thread already: https://processwire.com/talk/topic/741-a-guideline-for-module-naming/? That's a good start, especially when it comes to "reserved module names", though for something like your module it doesn't exactly give any foolproof answers.

Was just reminded of this module as I stumbled upon the Wild Beasts x Mattis Dovier GIF-novel. Also read an interview where the artist (at least I think it was him..) declared that GIF is making a come-back, or something. Can't really disagree after seeing the GIF-novel

Whether or not you change your mind, the issue you had is actually well explained in that puke you mentioned: you're trying to use method count() of something that isn't an object, and thus can't have its own methods. This non-object in your case is the $pages, used in a function. The reason for this is that in functions and class methods you have to use API vars with the wire() function -- wire('page'), wire('pages'), wire('session'), etc. In other words, your code should work just fine if you just replace $pages with wire('pages') You're right in that ProcessWire has built-in pagination support: https://processwire.com/api/modules/markup-pager-nav/.

@kixe: are you using the latest version of this module? Could you make sure that the Google Maps URL is properly embedded, i.e. on it's own paragraph in a field with this textformatter enabled, not really a link, etc.? Are there any other textformatters before/after this one? I can't seem to reproduce your issue: http://www.flamingruby.com/blog/testing-google-maps/. This is what the "view source" mode (in the RTE) for the main column of that page looks like: <p>https://www.google.com/maps/place/The+Great+Pyramid+at+Giza/@29.9797402,31.1351772,17z</p>

Agreed with Martijn, that's probably better in most (if not all) cases. If you really want to use this module, something like this should work too: if ($page->your_field) { $value = "<p>" . $page->your_field . "</p>"; $modules->get('TextformatterVideoEmbed')->format($value); if (strpos($value, "<p>") !== 0) echo $value; } Only benefits of that approach would be having a common way to present videos on your site, and using oEmbed instead of relying on your own case-by-case embed codes. Other than that, I don't really see much value in it