teppo

Having a repeater field called "rep" on my home template I added this to template file: echo $page->rep->getRandom()->name; ... and on each page load it echoed the name of one random item. Actually tested it with both 2.2 and 2.3 and neither had any problems with this. So, what exactly is your code doing / not doing when it doesn't seem to work?

Hello there and welcome to the forum! Always nice to see new faces around About that error, could you perhaps post some sample code about exactly how and where you're using these inputfields in your module? That would be very helpful in solving this. (I've used integer inputfield in module before and haven't had any problems, so I'm guessing it might have something to do with the way it's used.) Edit: it would also be helpful to know what kind of module we're talking about here -- is it a Process module or..?

Actually I've recently implemented something like this to a client as a module, though only to solve one very specific problem. Essentially their site has repeaters with checkboxes to select which fields of that particular repeater should be disabled from page edit.. and based on those choices things are handled slightly differently at template level. If all those fields were visible at all times it would've been quite confusing to use so something like that pretty much had to be done. Based on my experience so far I can say that this kind of feature would be useful - although cases where I've really needed it (ie. where taking a step back and slightly rethinking things to avoid unnecessarily complicating things hasn't helped) have been very rare so far. But that's just me, there are definitely lots of good use cases for this as you've already pointed out

I'm not sure that these options should really be combined with the image itself. I do understand your point and the needs you have here, but in my opinion these options are very closely related to markup generation and styling of the page and that's not something an image field should have an effect on. The fact that ProcessWire itself doesn't create / affect markup in any way is exactly what many of us like so much about it. What you've described above sounds to me like a very good way to handle this, as long as these settings are page-specific. On the other hand if they're image-specific I'd suggest looking into repeaters, since this kind of behavior would be very easy to put together there. Creating a new module, like @diogo suggested above, is always one solution - but in my opinion that sounds slightly overkill for this particular case.

This may have been discussed already in the AdminBar thread, but I simply couldn't find it there. Problem seems to be that buildForm method of ProcessPageEdit preserves GET parameter modal by default, while it's otherwise similar cousin in ProcessPageAdd doesn't. I'm just wondering if it would be possible to make these two methods work the same way in this little detail - unless, of course, there's actually a logical reason for this minor inconsistency? Edit: Went ahead and checked what kind of changes this would require. Seems to me that these would be enough: @@ -160,7 +160,7 @@ $form = $this->modules->get('InputfieldForm'); $form->attr('id', 'ProcessPageAdd'); - $form->attr('action', './'); + $form->attr('action', './' . ($this->input->get->modal ? "?modal=1" : '')); $form->attr('method', 'post'); if(is_null($this->template) || !$this->template->noGlobal) { @@ -309,7 +309,7 @@ $this->pages->save($this->page); $this->session->message(sprintf($this->_('Created page %1$s using template: %2$s'), $this->parent->url . $this->page->name, $template->name)); - $this->session->redirect("../edit/?id={$this->page->id}"); + $this->session->redirect("../edit/?id={$this->page->id}" . ($this->input->get->modal ? "&modal=1" : '')); }

Ryan, thanks for your answer. For now I'm going to go with what you suggested and alter db schema to my needs, but it's good to hear that this not only is possible but quite likely will be doable in the near future

So, I've been wondering (since this evening) if it would be possible to extend default integer field with two features / settings: signed / unsigned size (nothing too fine-grained, most importantly INT, BIGINT and perhaps something like TINYINT) The main reason I'm suggesting this is that I've banged my head on a wall that is int(11) couple of times now and I'd very much prefer having better option than using a text field in those cases. Sure, a text field combined with proper filtering + sanitizing usually gets the job done just fine, but at the same time it feels more than a bit hackish and introduces yet another chance for human error to thrive. Signed / unsigned part would be just a "nice to have" extra feature and probably wouldn't be of use for most PW users, but from a DB design point of view it would make a heck of a lot of sense; if I'm only interested in positive integers (which is almost always the case, by the way) why would I allow negative input and especially if I'm not allowing it at UI level then why should it be allowed at DB level? Oh, and that extra space "unsigned" results in is a nice bonus I do know that this would be quite easy to put together as a new fieldtype, but I wanted to try tossing it around here first, just in case that someone else would feel that it'd be worth adding to built-in field. Obvious downside of this whole idea is that changing settings like these would require changes to DB schema, so what I'm asking for may not be possible at all -- in which case I'm probably just going to put together a new "big integer" field..

First of all, thanks @muzzer. It's nice to hear that someone likes and uses this module About JS showing up as disabled, I'm not really sure why that's happening. Based on your screenshot it seems to be a problem concerning multiple browsers, which makes it even more strange. I'm guessing those are both logged from one computer? In that case this problem could occur either client or server side, which makes finding it's source somewhat complicated. Anyway, to sort this out it would be really helpful if you could post here (or PM me) one or more rows from your process_login_history database table (ones related to login history rows with JS seemingly disabled) so I could at least decipher this problem is in hooks module or the login history module itself. You might also find something interesting related to this at your Apache error logs. This could, for an example, be somehow related to JSON encoding - in which case the problem should show up at both the db table and Apache error log. This is exactly what I hate about remote debugging: it's alll fun and games when you've got access to a system where the problem occurs, but mostly guesswork when that's not the case.. Logging page edits, as important as that is, isn't really part of what this module is intended for. You could always do something similar to what Antti suggested above to achieve this, but a more sophisticated solution would require another module. As it happens, I do actually have something like that planned, but that's another story entirely. Edit: I pushed a new version of this module to Github an hour ago. You might want to give that one a try too - it did fix a minor JS quirk but that shouldn't really be the cause of the problem you've mentioned here..

Hello there! I'm sorry but I'm not completely sure that I understand your problem, so I'm going to need to ask a bunch of hopefully clarifying questions first: You said that files get uploaded correctly but don't show up with SFTP.. exactly how did you check that they're correctly uploaded, was it with a shell access or..? Is the site you're working on public and if it is, could you perhaps provide a link to one of these files? Which SFTP client are you using? Just in case that this isn't really related to PW or OS but an error with that particular application.. Based on code changes you've made to fix the problem, my first guess would be that the user PHP is running as doesn't have required access to actually remove files from temp upload directory and that's causing strange behavior elsewhere. Could you check if anything strange shows up at Apache error log when you try uploading new files? Edit: you could also try removing "@" from @rename and see if (and what) error it outputs. Suppressing errors isn't very helpful while debugging..

Just ran nik's test script on couple of machines, all of which had same problem: PHP 5.3.18 (cli) (Suhosin Extension 0.9.33) PHP 5.3.3-7+squeeze14 with Suhosin-Patch (cli) (Suhosin Patch 0.9.9.1 + Suhosin Extension 0.9.32.1) (didn't know these two could co-exist, by the way, but so it claims..) PHP 5.3.2-1ubuntu4.18 with Suhosin-Patch (cli) (Suhosin Patch 0.9.9.1) That makes three different PHP versions (5.3.x) using either Suhosin Patch 0.9.9.1 or Suhosin Extension 0.9.33 (or both.) Based on some quick research Suhosin does seem like a probable cause; it would seem that it makes multiple crypt-related changes. And if that's true, this problem also seems to exist on multiple versions of it.. By the way, you've probably seen this already, but there's also an open bug at bugs.php.net that might be somehow related to this: https://bugs.php.net/bug.php?id=55717.

Yeah, let's not go there, though it does sound tempting.. Guess I'll just have to settle with one slightly oddly named module at Module list. I can definitely live with that, especially since it means that I don't need to explain to clients why one of the features they're using has it's name in English when everything else around it is in Finnish

@Soma: yeah, I did know that, but thanks anyway! I've chosen to have this particular module install itself under Setup mainly because on it's own it's just one simple view which doesn't really deserve it's own "section" of Admin and Setup is most obvious place for modules like that. Your post did make me consider grouping it with several similar modules I have sort of planned to add later though.. but that's not happening anytime soon. I guess I'm hoping for some kind of a divine intervention here - a solution that's so obvious that I've completely missed it

I'm trying to make one of my modules thoroughly multi-language-enabled and I'm kind of curious if (and how) others have solved this particular situation. What I'd like to see is that this Process module, which by default shows up under Setup page at Admin, had it's name and description on that page translated, but at the same time (for the sake of consistency) I'd prefer not to make it's name appear translated at Modules page. My first idea was to make title and summary at getModuleInfo() translatable, which seems like an obvious solution, but it also makes module name appear translated at the Modules page. Perhaps it's just me, but I'd prefer to see modules listed with their original names there - not to mention that translated name not affecting sort order makes finding that particular module slightly more difficult. Headline would probably be quite easy to translate without affecting anything else, since you can override it by setting processHeadline to whatever value you prefer. But that's only partial solution. So, how do you guys usually approach this? Do you simply consider it OK that module name is translated even at Modules page?

First of all, Soma, this looks VERY nice! Will install it right now One thing that might be worth mentioning is that since Windows doesn't have getrusage() implemented (correct me if I'm wrong) this might cause some problems in Win-environment. Might be worth checking if it's available first and possibly even providing an alternative solution?

Amazing news, Ryan -- congratulations!

That sounds pretty much right. After moving PW from public_html/folder to public_html things should (mostly) work instantly, but one thing you will need to take care of are in-bound links; if you've created links to local content, they're probably relative and pointing to /folder/whatever-link-target/. You could either change these links directly from database, install Page Link Abstractor to handle this for you or use this little snippet by Soma. Another option, of course, is to export a page profile and re-install PW at public_html with that. This won't take care of the link problem, but in that case it would be quite easy to replace all "old" links in MySQL dump before running install process.

Hello there! Just wanted to say that I like what you're doing -- I've actually built something quite similar and found it very useful for (especially) larger projects, so I'm certain that this kind of module has a lot of potential I'd also like to make some suggestions, if you don't mind: * First of all, you might want to consider adding a separate directory for view files -- or perhaps making this configurable via module settings. Currently there's a small but still existing chance that view and template names could conflict. Making this user-configurable would also make this module usable out-of-the-box for those of us who prefer their own folder structure instead of flat templates directory. * Second suggestion / observation is that the way you're currently handling template names might not work as expected for templates that have been set to use alternative template filename via advanced template settings. I'm not sure if you would really consider this a problem, but I felt I should mention it anyway, in case you didn't remember that this kind of option existed. Anyway, with this setting in some cases a) multiple templates might have same filename and b) filename might not contain actual template name at all. This might cause problems, since your code seems to expect that it always does: $template_obj->filename = str_replace($templateName, $view . "-" . $templateName, $template_obj->filename) To be honest I'm not even sure that I understand why you're using str_replace() there -- wouldn't it better to simply set $template_obj->filename as $view . "-" . $templateName? This way alternative template filename, if given, would simply be ignored and view filename would always be consistent with actual name of that particular template. * And finally a quick comment on something quite subjective: code readability. The cleaned up version Some presented above is actually quite a bit easier to read and understand, partly because those comment blocks are (somewhat unnecessarily) taking some serious screen estate, but also because it seems generally speaking more polished. One very specific thing I'm having hard time wrapping my head around is your variable naming convention: $templateName = (string) $page_temp->template; // We pick the template name... $template_obj = &$page_temp->template; // ...and the template object associated. In that short code sample you're already using two naming conventions, first camel case and then delimiter separated. Picking one of those and sticking with it will make your code more predictable and readable in the long run. Trust me, I'm really not trying to be condescending here -- this is just one of those little things that will really help other programmers understand (and appreciate) your code. And that's it for the nagging. All in all it's really nice to see people posting (especially) these kind of proof-of-concept modules here. Pushing boundaries is always admirable, and that's exactly what you're doing here. Keep up the good work!

The obvious problem with this approach is that you need to understand how caching works and what results it can have; ie. after adding these headers some users won't see new versions of changed files until a year later, which could result in quite a few strange situations. Of course you could say that your files never change, which may or may not be true (or if they do, all related filenames also change.) For me, at least, it just doesn't work that way. That's also why I don't think something like this should be enabled by default -- although I do agree that PW could perhaps provide an easy mechanism to set something like this up Here's another (rather good) article about expires headers by Christian Johansen. Highly recommended, if you're going to play around with those.

Slightly off-topic, but did you guys know that PHP, since 5.3.0, also includes goto? Comeback of BASIC programming style! --- Seriously speaking, that xkcd comic at the bottom of manual page linked above pretty much summarizes how I really feel about this..

First of all, you'll get more descriptive error messages by turning debug mode on in /site/config.php. It's very useful while developing, but you shouldn't keep it on after a site has been made public -- in error situations like this it'll output way more information than you really want visitors to see. Problem here seems to be that you're using PDO commands while what you should be using are mysqli ones with $db->query(), since it actually utilizes mysqli under the hood. More information about this can be found here: http://dev.mysql.com....choosing.html. Another (minor) problem is that you're using event as a constant at that last row (that $rows[0][event] should be $rows[0]['event'].) With following changes your code should work properly. Note that I've also added extra check to the end of the script to make sure that some events are actually found. Originally you were only checking if a mysqli_result object was returned.. which doesn't necessarily mean that any data was found $day = date('d'); $month = date('m'); $table = "timetable"; $rows= array(); $results= $db->query("SELECT event,time,location FROM $table WHERE day = '$day' AND month = '$month' ORDER BY month ASC"); if ($results) { // loop through the result set and inspect one row at a time while ($row = $results->fetch_array()) { array_push($rows, $row); } } if (count($rows)) { $event = $rows[0]['event']; } else { // no data found. you might want to add some kind of error message here. } ...

Sounds very unlikely. Could you provide us some information about how things work in the server end; what configuration settings does each site have? Also: is there a possibility that file upload related PHP settings (such as temp dir, upload_max_filesize or max_file_uploads) could be site-specific? And one more thing: have you tried watching Apache error log while doing uploads -- does anything strange show up there?

If you wish that content to stay same site-wide, easiest (and probably most logical) solution would to add field for that content on your home page and let the user edit it there. As an example, let's imagine that your content is plain text (or pretty much anything that doesn't need to be iterated through) and you've created a new field called "header_content" for it. After adding that field to your home template, you could do something like this in your site-wide header file: <?php echo $pages->get('/')->header_content; ?> I hope this answered your question!

This module adds basic capability to restrict page rendering to selected number of IP addresses. Note: this is only meant to be used as an additional security measure in addition to typical username/password authentication or something similar, not on it's own! Currently individual IPs (127.0.0.1), IP ranges (127.0.0.1-127.0.0.255) and CIDR format (127.0.0.0/24) are supported. You can also decide whether restrictions should apply to a) admin area and b) authenticated users. By combining these two options you could create a site with public access restricted to selected IPs while still allowing users outside those addresses to have full access after authenticating. Better description can be found from README. And once again: all comments, bug reports, feature suggestions etc. are more than welcome! So far everything seems to work as planned, but I haven't had the chance to test this nearly as thoroughly as I'd like (that's also why this little cutie is flagged "Beta" in the modules directory..) https://github.com/t...erIPRestriction http://modules.proce...-iprestriction/ How to install Copy PageRenderIPRestriction folder to your /site/modules/, go to Admin > Modules, hit "Check for new modules" and install Page Render IP Restriction. That's it. How to use Default out-of-the-box settings don't introduce any restrictions. You can edit module settings (Admin > Modules > Page Render IP Restriction) to include those IPs you wish to allow access to your site for. Once you've filled in at least one IP address and saved module settings restriction will be immediately effective. Please note that if you fill in at least one IP address and check both "Restrict admin access" and "Restrict access for authenticated users" you will no longer be able to reach Admin without valid IP. Make sure that you've tested everything properly before turning those options on (and avoid turning them on at all unless you're 100% sure that you know what you're doing)