teppo

Downloading now, will comment after testing

Happened to have a PW site open, so I did some grepping (is that a word? should be..) and seems to me that you're absolutely right. No short tags found from core files. @Natetronn, I'm trying to avoid getting all evangelical here, so I'm keeping this as short as possible: IMHO learning enough PHP to write templates effectively is much easier task than learning enough of most templating languages out there to do the same. PHP has very good documentation (php.net), wide user base (try googling pretty much any problem you're having and add "stackoverflow" to your query, it's rare to find a question someone hasn't already answered there) and there are many fantastic tutorials floating around. "It's easier than you think." That said, I don't have that much experience with templating languages -- mostly I've used Twig and several in-company solutions, so I'm not much of an expert on this subject. All I can say is that after years of learning, fighting and cursing various templating languages and their shortcomings, being able to write templates in pure PHP is a bliss for me

From PHP documentation: "Before 5.3.6, the only values recognized are TRUE or FALSE, which are the same as setting or not setting the DEBUG_BACKTRACE_PROVIDE_OBJECT option respectively." Perhaps that could explain the error you were getting? Edit: actually it seems that before PHP 5.2.5 debug_backtrace() didn't allow ANY parameters. Not exactly sure if that could mean "not even false", but if that's the case this might be the real reason for your problem. I'm sure there's a PHP guru somewhere around here who knows this for sure, though.. Ryan?

@Lars282, syntax for adding pages is pretty much the same as with users, with some extra params to consider (such as template.) You can find more information here: http://processwire.c...ariables/pages/, under "Examples of saving and deleting pages".

Hello there! I'd consider adding a role with very few privileges (basically only page view access), name it "unapproved" or something like that. The register form could create new users via the API and assign that non-privileged role to them. After that an admin could check their info and assign whatever role they actually need. You can find many posts about creating forms from the forum and creating new users is instructed in the API documentation: http://processwire.c...variables/user/. Also, here's some discussion about adding extra information for users: http://processwire.c...extending +user. You could also edit the user template like @Soma suggested above -- not really sure which is the "correct way" here..

@netcarver, I'm not talking about generic URI field, I'm talking about generic URL field (like it's name already suggests.) Mailto is among many URIs, but it's also an URL -- and a very widely used one too. I'm having some trouble understanding why field titled "URL" wouldn't support a (very) common URL scheme, that's all. There are many situations where you'd want to disallow mailto links (such as when looking for HTTP URLs), but also many situations where you'd want to allow them. The way URL field currently works seems to be that it allows _any_ real or imaginary protocol, as long as they conform to certain syntax. It had no problems with "htpsss", for an example. Just to make things clear, what I'm suggesting here is only adding support for standard "mailto:" syntax.. and to be honest I don't see that as a huge change, since nonstandard "mailto://" is already supported and thus URL field already is pretty generic

@apeisa, typical use for us would be a repeater with one URL field which could contain any kind of link -- helpmenu, highlights, etc.. you know what I'm talking about here. Of course this could be achieved with two fields instead of one, but I'd rather have only one for simplicity. Also: mailto is valid URI scheme and "mailto:example@example.com" is valid URL, so I'd consider it a bit strange for the URL field not to support it. Perhaps I'm just being too strict here, but that's how I see this

Awesome! Seems like you've got all the important stuff implemented already, but just a quick question: are you planning to add trackback support / is it already supported? Also, there's something strange going on with comments; if you leave a comment which contains errors (might consider explaining what exactly went wrong, by the way - "there were errors" isn't very informative, especially since required fields are not clearly pointed out) it seems to break the browsers back button. This happens at least with Chrome. Not a big problem, but a bit annoying still.

Not really sure if this is just how it's supposed to work, but currently URL field doesn't allow standard mailto links. This is somewhat annoying, since more often than not we want to allow those while still making sure that the URL is valid (thus using URL field and not just simple text field.) I know it's possible to bypass this by typing "mailto://", but a ) that's non-standard and b ) that's not something a typical user would try.. instead they keep asking me what to do Is there any way this could be implemented in URL field -- or if this is a feature of sanitizer, could that rather be updated to recognize mailto links as standard URLs, or would that cause problems elsewhere?

Just came across this and found it quite interesting; Spark project (by Acquia) brings inline content editing for Drupal: http://buytaert.net/...iting-in-drupal. Seems way more streamlined than Mercury Editor and other similar solutions. There was some discussion about similar concepts in the AdminBar topic and at IRC some time ago, so I'm sure that I'm not the only one interested in concepts like these. Would love to see something similar brought to ProcessWire at some point.. ;-)

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.