SiNNuT

I don't exactly know what's going on here but it sure sounds cool

Great work Ryan! I've already been using the new stuff for a while now but reading this announcement reminds me of how much actually changed or has been added since 2.3 stable. And all for the good. Awesome.

It's not about an error with PW or php but just a rather arbitrary xdebug limit, nothing to worry about. With setting it to 200 i've never encountered this 'error' again.

Or you could lookup all the Saturdays in a given time-frame and build a selector from this. I don't know the inner workings of the selector engine and the queries it produces so maybe not efficient at all, but i've tested it and it seems to work. $start = new DateTime('2013-12-31'); $end = new DateTime('2015-01-01'); // grab all Saturdays between $start and $end $periodInterval = DateInterval::createFromDateString('first sat'); $periodIterator = new DatePeriod($start, $periodInterval, $end, DatePeriod::EXCLUDE_START_DATE); // build selectorValues string $selectorValues = ''; foreach ($periodIterator as $date) { $selectorValues .= $date->format('Y-m-d') . '|'; } $selectorValues = rtrim($selectorValues,'|'); // 2014-01-04|2014-01-11|2014-01-18|2014-01-25 etc. $results = $pages->find("test_date=$selectorValues"); foreach ($results as $result) { echo $result->title; }

Good request and seconded. On websites that do allow i choose my passwords on regular words based on at the moment thoughts or observations. Just make sentences. I i were to chose one now it would maybe be: 60W lightbulb on the ceiling. Good luck cracking that http://lifehacker.com/5796816/why-multiword-phrases-make-more-secure-passwords-than-incomprehensible-gibberish While we're at it; i would also like users to be able to login with username or email adres.

Not to state the obvious but have you tried deleting the module files from the server? On the exportprofile page it says something about incompatibility with multilang fields. Is there any chance this hampering you? Maybe try deleting/renaming the MarkupSitemapXML.module as a last resort?

What i really don't understand is how curly quotes would ever turn up as â because that is the html entity for the letter a with a circonflex. I'm assuming you've given a bad example here. If things show up correctly on the admin side there must be an issue with the rendering bits of the live site. Have you checked the encoding of the corresponding template file itself? Any textformatters on the field? What is your render code? Is there a url we can look at?

currently getting this on the site: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Error has been logged.

I've just been playing around wit Hanna code for the first time, pretty cool. I think i might have discovered some bugs, or at least an error/omission in the instructions. If you make a Hanna code with a hyphen in it and you then use parameters the Hanna code doesn't get executed. Given the example Hanna on https://github.com/ryancramerdesign/ProcessHannaCode: if(isset($parent)) { // If $parent is an ID or path, lets convert it to a Page $parent = $pages->get($parent); } else { // otherwise lets assume the current page is the parent $parent = $page; } foreach($parent->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; // echo "<p><a href='$child->url'>$child->body</a>"; does not work as i expected, it only outputs the last child->body instead of foreaching over them } // below is used in the body field of a fresh install from dev 2.3.15 [[menu_items]] //this works [[menu_items, parent=1006]] //this works [[menu-items]] //this works [[menu-items, parent=1006]] //this does not work, it doesn't execute and just displays the literal text Also, in the example above, if i echo $child->body the Hanna code stops working. It's looks like echoing $child->body from the body field of a parent does not work, or at least not in the example above. Maybe this is all for obvious reasons but it took me a good while with trial and error to figure out. All tested with PW dev 2.3.15, Hanna 0.1.5 on a Win7 machine.

How big of a player is Bitnami anyways? Before this bullshit contest a had never heard from them. Gonna give it one last shot to muster some votes.

I've never ever seen a core tab and i've done a lot of installs from dev branch over the course of time, including the most recent.

Ah..that article of Joel Spolsky is somewhat of a classic and should be mandatory reading for every (new) (web) developer, who don't know something about this subject. That other article is a bit misleading i think. It doesn't propagate storing/using htmlentities in the database. It's really about using the right character for the job; and in utf-8 the caracters in the htmlentities are just another character. http://www.fileformat.info/info/charset/UTF-8/list.htm And remember, the so called htmlspecialchars (crime 1 on that link) are always converted by TinyMCE, even in setting raw: http://www.tinymce.com/wiki.php/Configuration:entity_encoding So my recommendation: keep TinyMCE setting 'raw'. (If you want you can always use the php htmlentities function on your output, for example in a template file)

Without any hacking with ip changers, torbrowser and stuff like that, you can vote multiple times as long as your ip changes (maybe clear browser too). I myself have voted 5 or 6 times, at home, 3G, parents, work, friends etc.

Curly qoutes looking garbled has got nothing to do with the fact that it's a raw character or its htmlentity equivalent. I'm not saying that it is very very wrong to store htmlentities in the db but it is just not neccesary, and there are some downsides to it. http://stackoverflow.com/questions/9299152/do-i-need-to-use-html-entities-when-storing-data-in-the-database There's a lot more to read if you google. PS maybe you could mark this thread as solved.

Working fine on Win7, Chrome. Just installed with the 'Futura' color scheme. This was actually the first time i bothered with changing the default admin theme, but i like it. Biggest shocker though is that the installation screens have also been updated; gone are the 'vintage' screens i've looked at so many times (but it's a good change)

The password requirement has been retired for at least a couple of months now on the dev branch. https://github.com/ryancramerdesign/ProcessWire/issues/278

Hah, that's great, reminds me of some of those 80's cartoon intro's for some reason.

I've just tested it on a clean install (from the latest dev version) Setting: entity_encoding:named entities:8212,mdash,8221,rdquo,233,eacute in 'Additional TinyMCE Settings' works as expected. It replaces only the defined special characters to it's named entity upon opening and editing a page, including working with the html source modal window. It leaves the rest unbothered, so if i for example enter a '€' it will not convert it to the named equivalent. So you don't need to mess with a 'core' setting in InputfieldTinyMCE.js. Some reasons why things might not work for you: lose the single quotes around the entities setting, i don't think they should be there you've got two named entities following each other, where it should be a repetition of: odd(numeric),even(named) try clearing your browser cache, re-login and see what that does. PS i wouldn't bother with the apply_source_formatting setting; it seems to be removed or at least deprecated ( http://www.tinymce.com/wiki.php/Configuration3x:apply_source_formatting )

Looking at it from an 'awareness' angle i actually really like the way you've done it. Education wile you make and edit content.

This is in context of an RTE? <br /> needs 'shift+enter' and <p> needs enter. Isn't this always intentional behavior of the editor? What needs to be 'solved'?

What settings have you tried and how? In PW TinyMCE is set to 'entity_encoding: 'raw'. This happens in \wire\modules\Inputfield\InputfieldTinyMCE\InputfieldTinyMCE.js , line 35. This means that All characters will be stored in non-entity form except these XML default entities: & < > " (see http://www.tinymce.com/wiki.php/Configuration:entity_encoding ) Have you tried setting it to 'named'? Mind you, PW being a UTF-8 project i don't think this setting is desirable, but you could (and probably should) pair it with the entities option http://www.tinymce.com/wiki.php/Configuration:entities to make your own list. For example this is what Drupal is using in it's TinyMCE config (named is default so they don't explicitly set it) : // The default entity_encoding ('named') converts too many characters in // languages (like Greek). Since Drupal supports Unicode, we only convert // HTML control characters and invisible characters. TinyMCE always converts // XML default characters '&', '<', '>'. 'entities' => '160,nbsp,173,shy,8194,ensp,8195,emsp,8201,thinsp,8204,zwnj,8205,zwj,8206,lrm,8207,rlm',

What exactly do you mean by 'sitename'? PW doesn't really come with a sitename. If it's the default admin url 'mysite.com/processwire', you can set it in the install routine, but i think you can also change it at a later point.

There's definitely enough reading material on the interwebs on the relatively poor performance of 'order by rand()'. For example this: http://jan.kneschke.de/projects/mysql/order-by-rand/ .Quite interesting (but also 2007, maybe MySQL has improved?). But seeing Soma's test results i wouldn't be too worried about it in most real-life scenarios with PW. And if you say that you keep a cache for a day i would say the problem is non-excistent. In theory looping 4 times through the 'solution' i proposed (you only have to do the count once) should give random entries and possibly be faster on really large number of pages. Unfortunately i have not got a way to test this properly.

That's nice Soma. PW seems to have optimized this as much as possible with the way the db is laid out. Impressive results to be honest. I would not expect this to be almost as fast as $pages->count(). I was thinking about this to randomize the offset and then grabbing a page based on that: $pageCount = $pages->count("template=basic-page"); $startOffset = rand(0, $pageCount-1); $results = $pages->find("template=basic-page, start=$startOffset, limit=1"); Dunno, maybe this is my noob thinking and it's probably not efficient at all.

If you go to Admin>Setup>Fields and then edit the field with the tinymce Inpufield Type, there is a tab called "Input". On there you have the TinyMCE advanced configuration options. In the valid elements part replace "-p" with "#p". This will allow empty p tags. This should also pad the empty paragraph with a non-breaking space but for some reason TinyMCE seems to replace them with a regular whitespace. some more info here: http://processwire.com/talk/topic/4204-stop-tinymce-from-removing-entities/ and here http://www.tinymce.com/wiki.php/configuration:valid_elements