teppo

Hello there! First of all, admin panel is by default located at /processwire/, not /wire/ or index.php/wire/. Then again, http://74.52.58.162/~imageeff/?it=/processwire/ opens admin panel as expected, while http://74.52.58.162/~imageeff/processwire/ doesn't, which would suggest that there's also something wrong with rewrites. Did you get any errors while / before installing PW and is your site running on Apache with mod_rewrite enabled? In case that you need help solving this, I'd suggest checking this post (and why not whole thread, for that matter) out first: http://processwire.com/talk/topic/82-install-pw-to-subdir/?p=1253.

Have you already checked this solution out: http://processwire.com/talk/topic/1067-accessing-previous-version-of-page-beforeafter-page-save/#entry9321?

Judging from your error message it would seem that there's already an existing index.php where you're uploading ProcessWire, am I right? If that's the case, you should either clean old files (unless you've already got a working site you wish to use until your PW site is finished, that is) before uploading or create a new folder and upload and install ProcessWire there instead. If you install ProcessWire in a folder and later move it to the root folder of your site, you will need to fix any existing links, though. That's not very difficult and has already been discussed here in detail, but if possible it would be preferable to install PW directly where it's going to be located at in the future.

I personally prefer the aesthetics and UX of Facebook, though I do realize that it's clearly not for everyone. Like Joss already pointed out, they've never been into eye-candy; each and every one of those little details, buttons and links serves a clear and mostly unique function. Another thing I admire is the fact that they've always been happy to make changes they believe will enhance that experience, no matter how risky or how many people they might annoy in the process. Not everything they do succeeds, but at least they have a vision and are not afraid to take the platform further -- something MySpace originally failed to do and one of the reasons it lost it's place as the top dog of social websites. New MySpace does seem like something that could offer real competition though, I guess we'll see how well that works out Regarding Facebook and PHP, they've definitely done a lot to development and reputation of the project by proving that it can be used for pretty big things and also by participating directly via enhancements and bug fixes. Then again, the vast amount of resources they possess have made FB pretty unique and not directly comparable with the rest of us; for an example they're the only company I've heard of that has built and is using their own PHP execution engine

Good point, name field probably isn't best possible solution here. And yes, if that text field would have to be strictly unique it would require a module that makes sure that this is always the case -- or better yet a new field type as Antti pointed out above

There are quite a few ways to accomplish this already: // numeric id should remain same no matter what.. and if it doesn't, no other attribute could be trusted either $pages->get(1919); // like you pointed out yourself, config values are one option; you can set them in config.php or run-time $pages->get($config->teamPagesID); // you could also use your own custom field for this and define it global if you want it to always exist $pages->get('page_id=team'); // if the name of that page is very unlikely to change (and very likely to be unique), you could even find the page based on that $pages->get('name=team'); This is just my opinion, but I'm not confident that this would be beneficial enough to justify a core addition. I'd rather suggest that you turn it into a module; under the hood $pages->get() uses $pages->findOne() which in turn uses $pages->find() and since $pages->find() is hookable you could easily inject your own desired functionality there. This would, of course, require addition of that custom page_id field I mentioned above and perhaps another module / method to fill it in (and make sure that it's really unique) but that doesn't sound too complicated either. Edit: clarification about the uniqueness of name field added, thanks @Soma for pointing this out.

Awesome stuff, Ryan! Interestingly that's something I've always found annoying in jQuery - never understood why traversing only one level would be desirable. I guess it does have it's use cases, but I'm quite happy that you decided to alter their behavior for ProcessWire..

@Joss: like Pete pointed out before, what you're describing there is not only doable but actually very simple to do in terms of module development. In the most basic scenario you'd have a module with only the required methods and most of it's functionality would happen within ___install() and ___uninstall(). This way once the user installs that particular module, it would automatically add required fields, templates and pages via API calls. At least in my experience it's quite common for a client to want new "apps" later on, when site has already been built. In my opinion it would definitely make sense to have a library of "app profiles" (perhaps not the best name, but you'll get the point I hope..) that you could install via simple installer module, possibly even complete with basic "skeleton" template files. Sorry, I know I'm being more than slightly heretic here, but I'm not really promoting the use of modules which create their own markup -- more like modules pointing out that you could use this kind of very basic markup and modify it to your needs. Granted that ProcessWire makes building these kind of things from scratch very easy, still especially for simple, repeatable things these kind of modules could cut boring manual work (making developers happy) and unnecessary costs (making clients happy) and so everyone benefits. Of course this mostly applies to things like news and events etc. which most of the time fit the needs of multiple clients after only superficial modifications (CSS) Regarding original post, I believe that having more ready-to-use profiles is a good thing and something ProcessWire will really need to grow and reach more (especially less technology-oriented) users. One of the things that make our dearest competitor WP so compelling is the fact that you can simply pull out complete template if that's what you're looking for; we should keep in mind that even though PW makes building state-of-the-art hand-made sites very easy, it's not always what a client/user will want and/or would be ready/interested to pay for. Those hand-made piece-of-the-art websites are what I'd prefer to create all the time, but sometimes that's just overkill. Not to mention that sometimes even us developers would prefer to take something basic and just start using it. Anyway, this is just a quick thought and I'd love to elaborate it further, but now I'll have to run to a meeting

@antknight, thanks for your kind words and sorry for taking so long to reply! What you're describing sounds strange, since (unless I'm misunderstanding something) while database contains timestamps in server time, PHP should output them with the timezone you've defined. This happens because class ProcessWire (/wire/core/ProcessWire.php) sets ini variable date.timezone to whatever value is found from config. Just to make sure that everything is configured correctly, if you put following lines somewhere within your site what's the output? if (date_default_timezone_get()) echo 'date_default_timezone_set: ' . date_default_timezone_get() . '<br />'; if (ini_get('date.timezone')) echo 'date.timezone: ' . ini_get('date.timezone');

Thanks, Ryan!

Hello there and welcome to the forum! This sounds mostly trivial. You can do most of that with simple ProcessWire templates - one for categories, another for products and third for articles. Depending on your needs (how you want them to show up and how many of them there will really be) products could be actual templates or just repeater items on category template. I wouldn't suggest using repeaters if you're going to need separate pages for each item or there are going to be a lot of them, but for something like ~10 items on each category where only place their info is shown is that category page they would be an easy solution. Articles could be slightly more complicated, again depending on your needs: you said they should work like a blog, which would suggest that they require comments also. For that purpose there's a built-in comments module though, so that shouldn't be too difficult either. About those admin features you've mentioned, I'd suggest that this content should be added and edited as regular ProcessWire pages. You could always add custom admin panel, but that doesn't really make much sense in most cases. Not to mention that it's a lot of work, the result of which rarely exceeds that what ProcessWire already has to offer

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?