tiagoroldao

I've been lurking these waters for quite some time now, being a mildy inactive frequenter of the forums. Almost everything I do on my own is PW-based now (I work as a frontend developer for a University, on my "day job"), but I just realized I had never published any work here! This is a website for which I did the implementation (it isn't my design). PW makes creating specific hierarchies amazingly simple, so I can build a very specific html history-driven website in a snap, which is amazing... So here it is: http://mmbiotechnology.com/ (It is all in Portuguese, I'm afraid. On a related note, it uses the amazing language localized url module... Or rather is doesn't, as no one bothered to write up the english version -,- ) Cheers

While working on a ajax driven web service of sorts, I found this exact same problem (on PW 2.3 / PHP 5.3) When I serve the page as JSON [ header('Content-Type', 'application/json') ] it throws a 404. This doesn't happen if I send html regularly, but it also doesn't happen if I send jsonp (setting header('Content-Type', 'application/javascript') ) Are these issues related? Or am I doing something very wrong? I couldn't find anything regarding issues setting the header, not even here: http://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/?hl=%2Bajax+%2Bdriven Forget it, I'm a moron I'm rusty in PHP, spending my workday as a Frontend Dev... header('Content-Type: application/json') works just fine!

Well, this stopped for me when using tinyMCE, it happened only when using plain text, with no formatting... Sorry for the delay responding, I came across this issue during a project, one that ended up being a pain in the arse... And one that yielded nothing - clients from hell Clarifying - this is a problem specific to a plain (no formatting) body (the "original") textarealanguage field. any other textarealanguage (not the Body) works ok. Anyhow, a different issue made me think of a possible feature - control over the field lang substitution behaviour. When a field is called via the selectors, it is automatically translated to the other available languages, if it is empty.(right?) This may not be the desired behaviour (as when doing something like the echo (headline || title) behaviour ) is there a way to control this?

Hey Soma, great module! I'm trying to use it, but get the same problem nikola did: Unknown Selector operator: '' -- was your selector value properly escaped? It happens only on the root page.. I've reproduced it sucessfully on a clean install - it occurs to me when using a textAreaLanguage - whenever I change the default language's text, it throws an error! If I leave the default language blank, it saves just fine. Update: Okaaaaaayyy weird things are happening... So I've been experimenting, and the module tries to do some url rewriting, mapping a /page toa /lang/page, depending on which the textAreaLanguage's languages we are writing. On the standard Body (made to be a textAreaLAnguage) a "<a href='/templates/'>" maps to a "<a href='/pt/templates/'>", but a "<a href='./templates/'>" (notice the extra dot) throws the infamous error. Weirder still, a new "new_body" field (plain textArea field, no formatting) accepts no url format at all, not /pt/templates, nor /templates, neither ./templates....

Like a charm, and like you said exactly! Thanks!

Thanks for the reply! Just tested it, using a superuser login as well as a regular editor one, and both don't work, with either include=hidden or include all, for both hidden and unpublished pages..

I've been trying to use the PageAutoComplete fieldtype to connect some autors (teachers and students) to a particular work, but allowing to set unpublished (or hidden) student and teacher pages as well. For that, I've established a filter: template=teacher|student, include=all or return $pages->filter("template=teacher|student, include=all") In any other compatible fieldtype, it works just as it should, using php code or just the selector, showing me every teacher/student. But using the PageAutoComplete, it never finds the hidden or unpublished pages. Is it a bug? Or am I doing something wrong?

Thanks a lot Soma! I detected a bug in this last iteration, while trying to use it, on line 81 of InputfieldRangeSlider.module: $display = "$( '#RangeSlider_{$this->name}_display1' ).text( '$this->prefix' + ui.value + '$this->suffix');"; $constrain = "$( '#Inputfield_{$this->name}1' ).val( ui.value );" // !!! there is a semicolon missing here // for change event checks $constrain .= "$( '#Inputfield_{$this->name}1' ).trigger( 'change' );"; When I added the semicolon, everything started working again! PS: I'm fairly new to web coding and communities, is there a place where I could have posted this bug? (in the Git, or something like that?) Cheers

Thanks a bunch, diogo! I mean to say, {"text":"obrigado!"}

Extra information on the cheatsheet would be nice, and in terms of complicating the experience, I really don't see any problems - I agree with Diogo: The only issue I can think of is when/where to stop (i.e. which modules are worth keeping, and should one even make that judgement) /how to add information... But I would love to have even third party modules not in the distribution acessible - provided they don't overcomplicate the cheatsheet - filters that could be off by default, maybe? Afterthought: would it make sense for someone who make a third party module to submit entries to the cheatsheet? This may be completely off, and ruin the whole concept of the cheatsheet, i dunno.. Just tossing out ideas

You've made the gradients actually look good.. No easy task Congrats, looks good!

I swear I searched for it

I've been working on a medium-to-large scale project using pw (browsable alumni works and news repository, for a multimedia design school). I assume this kind of project is just what PW was written for: loads of information that can be cross-searched, etc.. And for it to work smoothly, sharing fields is the way to go, of course (do correct me if I'm wrong..) The "problem": some fields acquire diferent roles in different templates ("title" can be a Title or a student name on a student Template), and may benefit from independent descriptions (for setting protocols - specially important on a repository) Multiple field descriptions would be awesome (specific to each template), but I imagine the work that such a change could mean may not be worth it... I haven't explored the DB very deeply, but I assume the description is in a field entry, and would have to be in the field-to-template entry... Or maybe I'm reading it all wrong Any thoughs? Am I completely off the ball park?

This thread just saved me a whole lot of trouble, but it wasn't easy getting here.. Shouldn't the docs on the core installation of pw be updated as well? The first information I had came from there, and is very confusing.. (it still states that it is limited to 3 segments, with no mention of the config file...)

Extremely helpful! Between that and the ocasional thread searching in the Forum, I'm basically set!

Just tried to replicate it, and a page with no fields other than title does indeed start published.. But it doesn't seem to be related with having a template file or not - a page with title and body, with no template file, has a normal publishing behavior (it starts unpublished - that is, both with the "unpublished checkbox checked and the "no template" warning)

Yeah, in this context it becomes a very small issue.. I'm still baffled at how well these forums work! o.0

@Ryan: it seems that a lot of these processes, like $wire->addHook(), that could be amazingly powerful to make certain thinks simple, aren't explicit in the api guide/cheatsheet, etc.. Which is strange, seing as they are all so clean. Is this by design? Are we not supposed to do things this way? EDIT: Ok, so that was dumb. Just found the apigen Documentation, which has basically everything (although browsing the actual source is also a breeze). Still, there are some replies in this forum that could easily be made into a collection of "intermediate developer" examples.. Cookbook style

Yes and no, interrobang You're right, and I just solved it using your solution... But you seem to have stumbled into a protected field, maybe? Using "sortfield" as a temporary field throws an error, renaming it to something like "mysortfield" makes it work like a charm! EDIT: so sortfield it's the sort setting for a page's children.

Yes, and I most certainly will. Thanks! Is there a way to treat the fields before sorting, is it possible? For instance, something like sorting a strtoupper(field), or maybe sorting by a sum of 2 fields..

First of all, my congratulations to Ryan on this amazing piece of software! This is my first post in these forums, but I have been a silent noob for a few months, learning while using processwire for every web project in the Multimedia Design course I'm currently finishing! On to the bug/problem (is this the right place for this post?) : When I try to sort a PageArray object using the $a->sort() method on a string field, say, the title, the API places the ones starting with uppercase first, and the lowercase last, like so: A,B,C,D,a,b,c,d... Am I doing something wrong/missing something? Cheers, Tiago