teppo

OK, this made things much clearer. First one is something I can definitely live with. Having two levels would've solved certain annoying issue, but I'll just solve it some other way. Second one seems to need a bit more testing, though I'm already seriously questioning whether this is the solution I want to end up with.. Anyway, thanks Ryan!

Oh well, it was pretty obvious that someone had to try this

I thought module had to be in /site/modules/ModuleName/ModuleName.module but I'm a bit confused about why it actually works from /site/modules/whatever/ModuleName/ModuleName.module also -- and why won't it work when there are two odd folders (/site/modules/whatever/somethingelse/ModuleName... etc.) instead of one? Yes -- and that's not the problem here. Module is working fine from site/modules. What I'm wondering here is why some third party modules seem to work at /wire/modules/ and some don't.. but I'm guessing from your reply that it's considered really evil to put any non-core-modules there. Would still like to know, though. Our upgrade process is a bit different -- many sites share one wire-folder and svn:externals combined with some shell scripting handles upgrades nicely. This way having external stuff (such as modules) within wire folder isn't actually that much of a problem and I was just experimenting if I could share modules between sites with this method.

Just wanted to make sure if I understood this correctly: modules can't be placed in /wire/modules/? At least AdminBar doesn't seem to work from there, though certain modules seem to have no problem with that. Is this just how things work or is AdminBar somehow special -- or am I doing something wrong myself? Another thing is that a module seems to work properly in following directories (using FieldtypeCropImage.module as an example): /site/modules/FieldtypeCropImage.module /site/modules/FieldtypeCropImage/FieldtypeCropImage.module /site/modules/shared/FieldtypeCropImage.module /site/modules/shared/FieldtypeCropImage/FieldtypeCropImage.module ... but when placed in /site/modules/shared/Thumbnails/FieldtypeCropImage.module it won't work anymore. Could someone please explain why this is happening? Is there some kind of "max one non-related directory between modules-directory and module / module-directory" rule or..?

Since "everything goes" I'd really like to suggest two wonderful books for those who haven't read them yet; "Getting Real" and "Rework", both by 37signals. Seriously, I can't get enough of these -- currently reading Rework for the third time (I think..)

Now that's what I'd call "perfect timing." Was just about to start building some forms-related templates, now I guess I'll give this a try first Just a quick question, @netcarver: how stable would you stay that this code is at the moment? Is it usable for a simple project already or more like "something you can try but don't count on it working" -- or something inbetween those options? Edit: I did notice that "experimental" line in your README, but I'm still asking.. different people do have different meanings for stuff like "beta", "alpha" and "experimental", so..

It's common sense to name things based on meaning -- search, sitemap, home, basic-page / default etc. -- but I'm interested in hearing if you folks are defining / following more specific rules than these. This is something I've been thinking quite a bit lately and unfortunately I feel a bit lost here. IMHO this becomes an important thing especially when you have multiple developers working on / providing support for same projects, which they aren't necessary familiar with. It's one of those things that make it easier for a new developer to jump on board of a project and instantly understand what's happening under the hood (or at least make educated guesses.) So after this (longish) explanation, I'd really love to hear what you think about this subject -- what kind of naming conventions do you apply for your templates and/or fields? (If any.)

That's definitely a good start, though even if those files are inaccessible, I'd still be a bit worried about any invalid parameters being passed to ProcessWire.

Great to hear that it works, although I'd be somewhat careful here: That condition checks if URL is valid and thus removing it could potentially allow non-valid queries into PW which in turn could result in strange behavior and/or security issues. I'm not an expert in this area, though, so I might be worried for no reason -- of course Ryan knows best how this stuff works so I'd ask for his opinion before implementing this "fix". Most likely better option would be to determine how their rewriterules work and create one that's specific to IdeaWebServer to ensure that URL's still get filtered correctly. -- Somewhat offtopic, I did some research conserning IdeaWebServer and you might want to take a look at this (still unresolved) WordPress ticket: http://core.trac.wor...org/ticket/9763. So clearly there are existing problems with other platforms too. You did say that WP works now though, so it might be that they've fixed that problem and the ticket was just forgotten. Anyway, the point of above comment is that if this really is software developed and maintained by one specific service provider, then that's not a very good situation for it's users. But that's naturally just my opinion -- on the other hand it does seem like they've got very good customer service, which always makes things easier.

Seems to work now. Thanks Ryan!

So it seems. Unfortunately I've no idea how to work around that problem -- I hope someone else does. You might want to check from your client / whoever manages that server if there's any chance they could fix this. OR you could always try to persuade your client to switch servers -- this kind of problem is quite likely to affect pretty much any existing CMS and many other applications, not just PW -- but quite often that's not exactly simple task either..

Sorry @pawel, my last post was pretty vague. I meant mod_rewrite -- is that mentioned in the output of phpinfo() and if it is, what are the values of http_mod_rewrite and http_redirect_mod_rewrite? Or if those don't exist, do you see _SERVER['REDIRECT_HTTP_MOD_REWRITE'] and is it "On"? IMHO document_root itself shouldn't make any difference here, unless I'm confusing something.

Sounds a lot like htaccess wasn't properly supported there. It IS supported at some level, right -- what does phpinfo() say about it?

Not sure if this would help, but have you tried setting the RewriteBase-option in htaccess? "Optional: Set a rewrite base if rewrites aern't working properly on your server."

Hello there and welcome to the forum! Just to make sure, you uploaded a fresh install package and definitely not a pre-installed site, right? You didn't install this somewhere else (local or your own server) before this? I'm asking this because it seems like PW is expecting database user, password and hostname. And that shouldn't happen unless this is an installed version. You could also try downloading new fresh package from https://github.com/ryancramerdesign/ProcessWire again, just to make sure.

@soma, actually I failed to explain this properly. It's not enough that name starts with a number, it must BE a number. As far as I can see, this seems to be caused by function "row" of MarkupAdminDataTable.module, more specificly this check: if(is_string($k)) { // Associative arrays get converted to: // Anchor Text => URL $v = "<a href='$v'>" . $this->encode($k) . "</a>"; } else { $v = $this->encode($v); } So unless I'm missing something, 123 (username in this test) isn't a string (is_string($k) === false) and because of that link isn't created (and name is dumped.) Right?

For some reason Admin Data Table breaks when you insert a row which starts with number. See attached screenshot -- link doesn't show up and instead it's URL is printed out as plain text. Screenshot is from (unmodified) admin/users, but I'm seeing same strange behavior when adding rows to custom made Admin Data Table too. So far I've tested this with 2.1 and 2.2 and I'm seeing same bug in both. Can anyone else produce this or is there something wrong with my PW installation(s)?

@diogo: used that for couple of projects, only simple stuff though. So far seems to work well and handles some stuff that PHPs built-in mail() doesn't, no complaints

I see where you're going with this and truly respect that; quite often framework is simply overkill. I guess I was mostly referring to bigger projects, where you really do need huge amounts of code And yeah, PHP has native functions for so many tasks that it's somewhat frightening. Won't go there now, that's another issue..

Individual framework components I've used in other projects include forms, database tools, i18n and l10n, authentication / authorization / session management and filters. These are all things that PW handles itself, so I don't really see much need for them anymore. Things that I do still find useful, coming from Zend Framework, are it's web and web services components, such as Zend_Feed, Zend_Gdata (Google API tools) and HTTP, REST and XML-RPC clients. Also I could see some use for it's server tools, though I do admit that I've never had to use them before @apeisa, that's a very good point, though I'd leave the "when you are not that seasoned developer" part away to keep things simple -- security experts (and common sense) have taught us that we shouldn't reinvent the wheel, even if it's fun. If we do, we're most likely going to make same mistakes that others have made (and fixed) before us. Not to mention that especially on client projects where time and money are limited a framework can lower production costs considerably and still keep quality high. Naturally all of this mostly applies to serious stuff, client projects etc. Personal projects are very different matter