Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by teppo

  1. Critic's Choice for Best Free CMS goes to... http://t.co/AIoKrpp1

  2. 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..
  3. 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. } ...
  4. 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?
  5. 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!
  6. 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 (, IP ranges ( and CIDR format ( 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)
  7. You've got one extra ")" near the end of that row, right before last PHP end tag. Try this instead: <meta type="robots" content="<?=($page->no_follow ? "nofollow" : "follow")?>,<?=$page->no_index ? "noindex" : "index"?>" />
  8. I'm not sure why you're converting that date to Unix timestamp, but that's probably why this is failing. Try something along these lines instead: wire('db')->query("UPDATE pages SET created='2012-11-15' WHERE id={$page->id}"); The type of db field created is timestamp, which doesn't by default accept Unix timestamps (...) as it's value.
  9. There seems to be a bug in ProcessPageType (dev branch) that affects at least user list: renderList() tries to render MarkupPagerNav with params $pages and $pagerOptions, which fails since $pagerOptions is by default null and MarkupPagerNav expects an array. Following changes seemed to fix this, at least in this case. Haven't had the chance to test further yet -- currently on a lecture, can't spend too much time debugging/testing.. - protected function renderList($selector = '', $pagerOptions = null) { + protected function renderList($selector = '', $pagerOptions = array()) { This came up while adding users to a site (26th user => page won't render.)
  10. Couldn't agree more with Adam. If what the client wants is exactly what Joomla, WordPress or some other system already has to offer (very unlikely, but possible) that's fine by me -- honestly, I've absolutely no problem with that. Actually most of time it'd be waste of time and money (my time, their money) to reverse-engineer an existing solution. Not to mention that it's just no fun at all. One thing ProcessWire is very good at (and many other systems seriously lack) is flexibility. As a ProcessWire user you can freely discuss with a client what she really needs, throw in wild ideas and if you both agree that those ideas would benefit the client more than some existing plugin/module with tons of unnecessary features, bells and whistles you can just build it -- without any unnecessary hassle and with remarkable ease. This way you're actually selling solutions, not features. Of course with ProcessWire you can also be sure that whatever you build with it is most likely more secure, way more flexible and much easier to maintain than anything you could build with pretty much any other platform. And just for the record, this comes from someone with years of experience maintaining WordPress installations. ("Years of testing", yeah right -- more like "years of hastily fixing bugs by replacing them with new ones.") All that said there are probably situations where you should either consider going with another system or just ditch the case. Sometimes it's just not worth it.
  11. Subdirectory shouldn't cause any problems, I've been forced to do this couple of times without any trouble. Regarding shared database you should take into account that ProcessWire tables cannot be prefixed, at least not without (lots of) very ugly hacks. I'd suggest that you first of all make sure that no other system wants to use same table names. On the other hand I'd also like to suggest that you at least consider getting separate databases for each system, unless that's absolutely impossible for some reason. Makes things easier, less error-prone and (most importantly) more secure. This subject has been discussed here in more detail.
  12. @mindplay.dk: if I'm following your post correctly, you're saying that by default trailing slash should be added to pages which can (currently) have children and omitted from pages which (currently) can't? I do see where that's coming from, but I still have to disagree here, mostly based on the previously mentioned fact that those things (family settings etc.) can be changed quite easily while URLs changing is generally speaking a bad thing. What you're saying about files and folders is absolutely right; in this context files/folders act exactly as they would in, say, pretty much any UNIX style operating system. Thus /foo/bar/ would refer to folder /bar/ in another folder /foo/ and /foo/bar to a document called bar in folder /foo/. Up to this point we're probably seeing things exactly the same way. That's also where things get slightly more complicated: I prefer to think that each ProcessWire page really is in a (virtual) folder, so when you're accessing /foo/bar/ you're actually getting served default file in particular folder; in this case /foo/bar/index.* (suffix doesn't matter here.) There's nothing wrong with this, it's always consistent, very common and has been used for many, many years already all around the web. Even if that particular page had only one file and thus didn't really need to exist in a folder, this is still completely valid. If pages that can't currently have children had to be accessed as files instead of folders, strictly speaking that should also mean that same address with trailing space added should not work -- otherwise they would be folders and not files, and like you said that's a different beast altogether. Just give it a try in whatever OS you're currently running. Most likely if you create a folder /foo/ and try to access it as foo (without trailing slash) you're still redirected to correct folder, but if you're trying to edit / view a file called foo and add that trailing space you'll only end up with an error ("foo/: Not a directory" or something similar.) To sum this up current behavior is imho very much consistent with how the OS beneath your site actually behaves and that's another reason it should not be changed (unless you're actually suggesting that user accessing /foo/bar/ should only get 404 in case that admin has decided that bar can't have children, thus making it a file instead of a folder.) See where I'm going with this?
  13. Sorry to bring an old topic back to life, but there's something I've been trying to make sense of lately regarding module naming: what should one call a module that is clearly related to other module, but still technically speaking very different from it? This problem seems to show up quite often especially with Process modules that require hooks etc. I'm currently working on something that is directly related to Process Page View and I'm having some trouble deciding whether to name it a) something completely different (Page-something perhaps?) or b) Process Page View [insert-specific-feature-here] even though it's not really a Process module itself. What do you folks think? Or am I just overthinking this? Also: I'm currently a bit worried when I look at the modules page of my test site and already see quite a few "module groups" with only one module in them; "Admin", "Comment", "Custom", "Lazy", "Schedule" and "Multisite" to name just a few. This isn't a big problem yet, but it does imho somewhat undermine whole module group concept. I don't have an answer on how to fix this, but I do feel that something needs to be done -- and preferably rather soon. Edit: for some reason what Ryan said up there ("Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'.") didn't really sink in before I had posted this. If I'm getting this right, it would mean that if my module adds hooks to Process Page View it should be named after that -- thus it's name would start with Process, even though it's not a Process module. Still doesn't sound quite right considering technical differences etc. but perhaps it's the right way.. Guess I'll have to think about this a bit more. (Also the worries I mentioned above about current module naming conventions, or lack of them, still seem valid.)
  14. Critic's Choice CMS Awards voting ends tomorrow. Last chance, folks! http://t.co/NcMQTUZ9 #CMS #ProcessWire

  15. Agreed. Family settings are easy to change and if URLs are based on those (or actually any other variable that could potentially be altered later) you're going to end up with multiple URL variations for one page, which can't be a good thing no matter how you look at it. In my humble opinion it's much better to stick consistently with one than alter it based on each specific scenario. I also believe that (again for consistency) URLs without trailing slashes should always indicate files, though based on what @mindplay.dk said way up there ("it makes every page look like it's a folder - which the majority of pages are not") the whole concept of "file" in this environment might be slightly shady..
  16. Looks really nice, nothing wrong with simplicity. By the way, was that "£2000" option in your contact form actually supposed to be "More than £2000"..? Also noticed that clicking the logo results in 404 error and link next to copyright goes to current page. Minor, but thought I'd still mention them.
  17. ... yeah, that's what you get for changing things while on mobile. Now it should be fixed
  18. Thanks Ryan IP logging was intentionally left out to avoid collecting too much "identifying" data, but right now I'm thinking of adding it anyway -- it shouldn't come as a surprise to anyone that this can (and will) be logged, not to mention that Apache already keeps track of this information. This was also suggested when I asked a coworker for comments earlier today.
  19. This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.
  20. Didn't realize that. That at least partly solves the problem, though I'd imagine that this could cause some confusion in certain rare cases when uninstalled module is suddenly installed again. Not sure if that's such a big deal, just thinking out loud. Cough. Yeah. Sorry for that, it was a typo -- it was really late when I wrote that post after all. What I meant was that A requires and installs B, B requires and installs A.. Even though my post was pretty confusing, you've understood it perfectly. That's exactly what I was going after.
  21. First of all, can't help admiring your attitude Based on very quick look at the code, LanguageSupport seems to use external installer / uninstaller script to manage dependencies. This is probably something I'll have to take a closer look at tomorrow (11 pm here, seen way too many lines of code for one day already) but according to (equally quick) test it doesn't seem to solve my problem straight away: LanguageSupport installs ProcessLanguage and ProcessLanguageTranslator, both of which are uninstalled with LanguageSupport itself, but I can still remove either one of those latter modules without affecting ProcessLanguage if I so decide. Not sure if that's a problem for LanguageSupport (possibly not, don't really know it's inner workings well enough to say) but it's essentially same behaviour I'm experiencing with my modules (in which case it is a problem.)
  22. I'm having a minor nervous breakdown here, so I'd appreciate if someone could tell me exactly what it is that I'm doing wrong. I've got two modules that need each other to work properly. What I'm trying to achieve is that when user installs one of these modules, it automagically installs other module. Also when user uninstalls one of them, other one is also uninstalled. My question is if there's any way to have two modules which a) install and b) uninstall each other automatically? I did try setting up some hand crafted install/uninstall magic, but results ranged from bad to worse, especially regarding automatic uninstallation. Anyway, since ProcessWire these days manages automatic installations / uninstallations itself, that's what I've been mostly focusing. Results, as you can see below, haven't so far been that great. (Sorry for very long post -- I tried to keep it simple, but there were quite a few things to mention and I didn't want to accidentally leave anything important out.) First part, installation, was easy to setup using AutoInstall logic and following settings: A: 'installs' => 'B' B: 'requires' => 'A' This way module B cannot be installed alone, user has to install module A first. When she installs A, B is installed right away and everything is cool so far. What I can't seem to get working is the AutoUninstall part. If user uninstalls A, B is uninstalled too, but things get complicated when she suddenly decides uninstall B first. That way module B is uninstalled but A stays intact, which is not cool at all. Seemingly there's nothing I can do to stop that either. A: 'installs' => 'B', 'requires' => 'B' B: 'requires' => 'A' As you can see above, I tried to solve this by making module A require module B, which makes it impossible to uninstall B first, but that also seems to render AutoInstall useless: while uninstalling module A an error pops out: "Module is required by other modules that must be uninstalled first." After that module A is uninstalled but module B left intact. Bugger. A: 'requires' => 'A', 'installs' => 'B' B: 'requires' => 'A', 'installs' => 'A' My next experiment was telling module B to install module A (and thus also uninstall it) which actually seemed to work -- but with the slight setback that it also caused a loop which ends with PHP timeouting. After timeout both modules are uninstalled, but that's not exactly the way I'd like it to happen. A: 'installs' => 'B' B: 'installs' => 'A' At my final moment of desperation I removed requires from both modules and instead told them to just install each other. Which, naturally, only made things worse; with that setting neither module (no matter how much they claim that "This will also uninstall other modules - A" etc.) can uninstall the other. No errors, nothing. Other module just sits there like nothing happened. I've banged my head on wall with this for way too long already, so I'd appreciate if someone could point me to the right direction. And if what I'm trying to achieve isn't possible with automatic installs / uninstalls, that's also very nice to know.
  23. Each page knows when it was added and when it was last updated, since this data is contained within pages database table. There's no such data available for file fields. Your best bet would probably be creating either a custom fieldtype or (perhaps easier method) a module that hooks to page save, checks if file fields exist and if their contents have changed and then keeps a log of newly added files in page-specific (hidden) text / textarea field. JSON format is nice for storing that kind of data. There might be a better way or this method may contain some unexpected problems, can't really test it right now, but that's what I'd suggest.
  • Create New...