Soma

Just tried and it works for Thumbnails. I guess then it has something to do with allow_url_fopen php setting not enabled which is required for loading from external urls? http://www.php.net/manual/en/filesystem.configuration.php

Can't you just put this code in your main template? if($user->isGuest()){ throw new Wire404Exception(); // or redirect } else { // not guest }

Use maybe has_parent=id|id2 I think that should work

Try increasing max redirect in modules settings.

You could always test for the width and if smaller don't do a size(). if($page->image->width() < 500) { $img = $page->image->url; } else { $img = $page->image->size(500,0)->url; } Also have you tried doing a $page->image->width(500); Does it also upscale? However I think it should be taken care by the size itself.

And even after 2 years PW you think you knew everything you discover something new.

You can extract the month of a date with $month = date("m",$page->date); // 03 $month = date("n",$page->date); // 3 But not sure what you're looking for. Foreach it?

Cool thanks! Bisch voll im Schuss!? ;-) Why didnt this post appear in my no read list?

You mean like this? http://modules.processwire.com/modules/pdfcomposer/

LOL Damn joss this is brillant! Shame I didn't notice when viewing this on mobile back then, the audio wasn't showing up, just noticed now...

Yeah I know about this issue. Since LanguageLocalizedURL module by mcmorry was first a single file module. I think this could be added but it's an edge case and I think all modules should have their folder by default. I could check for the class name (if provided) and search for single files, but not sure it's worth for now, since this is still "alpha" and considered to be integrated into core there still lots of work to be done anyway.

I did mean previously that eval() to execute php is bad practice theres more elegant ways to archive what you're speaking.

I could build this site in PW in 1-2days and it will be fully flexible content block type you can build those pages and have all configurable and sortable just powerful with sliders and colorpickers. Think outside of the 'page' and step back. Use them as blocks. You got jquery at your fingertips for the whole page tree, repeaters, page references. This may sounds as it would be silly but see pages as repeaters and there's nothing that can stop you. See one one page as a page you look on the screen and you'll be limited by what it can do. PW is build to work this way and performs and scales very well. There's plenty of module already and they`re easy to understand and build/maintain. I'm not a very good coder but PW makes me look like one.

Ryan dont you think users unpublished should have strikeethrought?

Pw has no template tag language and will never have in core level. However this is an easy task and would make a simple textformatter module. Basicly what wanze does but more convenient.

Just did a little test round. So far it's working great. Just noticed a problem when logged in and having checked another language than default for my user (in profile). When calling the url for default it stays on the user language and doesn't switch language at all. When I make my user have defualt language checked it works like a charm. I'm using latest PW. Edit: Forgot about the homepage issue. This is indeed something we would need to handle. It would be great to have support for language segment in url like /de/ueber-uns/ and /en/about-us/. Yes this is how we build most sites. Do you mean to have a root page that has the site inside? And have that gateway page names like "en" and "de" ? How would then rootParent() behave. Sure there's the workaround with parents but you get it. Now also having maybe, if possible, some possibility to publish languages individually. How would you go for it if you need it with this support? However I think if there's an easy way to do it, then-or anyway the LanguageLocalizedURL becomes obsolete, because this module solves the main issues with LLU, which I'm not unhappy about. Remember it was created because there were no support in core yet.

So far I can't reproduce what you're saying that the "ready" repeaters are included when foreach the repeater field. What version are you using? I think there was a bug some time ago fixed.

So I think the behaviour you get shouldn't be unless you have the page unpublished and preview it as superuser? Could also be something with viewing it as superuser logged in?

http://processwire.com/api/cheatsheet/?filter=status&advanced It's correct the status is a bitmask of on (default) hidden and unpublished as you can see from the cheatsheet. Usually you can check or set with $page == Page::statusUnpublished. However I think there's something mysterious that you get the unpublished ready repeaters, not sure what is about, but usually you don't get unpublished pages when doing finds, but since you do a direct call, I can imagine that this is the problem. Ryan help! I think it may also work if you do this? foreach ($page->find("subitems") as $item) { echo "id: {$item->id}<br/>"; echo "status: {$item->status}<br/>"; } Edit: Just realized doesn't make sense "$page->find("subitems")" lol Looking at repeaters code there's something going on with the status, not sure since repeaters are little special this code may the key: in wakeupValue() function // #499 FieldtypeRepeater.module // hidden pages (assumed to be a ready page) should never be included when page is being viewed (outputFormatting) if($hidden && $outputFormatting) $pageArray->remove($p); // unpublished items may only be included if the page is also unpublished (and presumably being previewed) if($outputFormatting && $unpublished && !$page->is(Page::statusUnpublished)) $pageArray->remove($p);

I get it that it can be useful to have this option (and there is). But isnt it a two sided sword? You said to make pages load as fast as possible... But this technique also means when I browse your site to these pages I have to load extra files not there before and not cached yet. I get it that when therea really huge scripts needed on different pages it can be useful. But how aboit require.js?

Looks like it's there 2 times. AND you don't install modules in core /wire/modules/ but in /site/modules/ because when you update you replace wire folder.

Looks ok. Does it work?

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

Do you ever sleep?

You can't use setTargetFilename on multiple. You should be able to just rename them after uploading: foreach($u->execute() as $key => $filename) { $file = pathinfo($filename); $newfile = md5($file['filename']) . "." .$file['extension']; @rename($entry->images->path . $filename, $entry->images->path . $newfile); $entry->images->add($newfile); } However this works, you create a new page everytime which stays there if there's an error. Best practice would be to first upload to a protected temp folder and create page and add files if everything went well... See also my script example here: https://gist.github.com/somatonic/4150974