Soma

You can set the description to have multiple row. Rather than just one input it will be a textarea. You could even use markdown or something and use textformatter on output. I would go for page per image.

I had to rewrite some of the tutorial for adding a script in admin.php. Due to some effect of an installed third party module, the custom script was added after Jquery core js. This usually isn't the case when adding a script via admin.php. I wasn't aware of it at that time and only later remembered that adding a script the way I proposed in admin.php will add our script BEFORE the jquery core script in admin, thus not working when using $ jquery syntax. It's simply because of the order the JS's get added. After investigating, I found the third party module that was, for some reason, changing this behavior. Reason was: it was loading the JqueryCore in the init() method, thus resulting in my script getting added after JqueryCore. I've changed the tutorial to account for this simply by calling the JqueryCore module before adding the custom JS. So instead you would have to do it like this to make sure it gets added after JqueryCore js. $modules->get('JqueryCore'); $config->scripts->add($config->urls->templates . "scripts/scroll.js"); Sorry for the confusion.

Of course when setting the edited page in context, it will also get used by other admin code and the current admin page is gone. If you still want to have your own Process you could work around it like $currAdminPage = $this->page; $this->fuel->page = $this->pages->get($this->input->get->id); $editForm = $this->modules->ProcessPageEdit->execute(); $this->fuel->page = $currAdminPage; return $editForm;

The context is missing for the "page", not sure about the detail ATM anymore but you can get around it by adding this wire()->fuel->set("page", $this->pages->get((int) $this->input->get->id));

Have you taken over the config with the user salt?

Works perfectly fine for me.

But then no matter what you enter it does show the same error http://wire.madaboutbrighton.net/klajsdlas http://wire.madaboutbrighton.net/hello.php ... Currently the installer shows at http://wire.madaboutbrighton.net/ which normally would be at http://wire.madaboutbrighton.net/install.php There's no way I see why PW is causing this issue. It could be an already installed PW or an .htaccess somewhere. The database credentials are stored in /site/config.php after you entered them and when PW was able to connect to DB. It doesn't matter what folder or sufolder PW is put. It doesn't try to connect to a db at that point as you haven't yet come to enter it. So something's wrong on the server and how you have set things up. If htaccess is already enabled, it is somehow already trying to route to the index.php, that's maybe why it would somehow already tries to load ProcessWire.php core. But there's no way PW already knows you're database. When I try to reproduce something alike, I can only get domain.com/randomstr to show a PW error but no sight of DB or ProcessWire.php. I can even delete the index.php and /core/ProcessWire.php and install PW fine to the very end.

Why exactly was nsa listening to SSL?

SSL means sweet sugar lullaby?

I also wanted a solution on a site that kinda has this issue with lots of these, instead I created a hook on what Ryan mentions. Also I changed it to replace only those preceded with a whitspace, so those that actually make sense between two words intact. https://gist.github.com/10330802 <?php /** * TinyMCE replace nbsp with regular whitespace * * Only nbsp preceeded with a whitespace will get replaced, this leaves * single non breaking space only bewtween words * * ProcessWire 2.x * Copyright (C) 2012 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class TextareaStripNbsp extends WireData implements Module{ public static function getModuleInfo() { return array( 'title' => 'Unicode (x00a0) Stripper', 'version' => 100, 'summary' => "Replaces the Unicode non-breaking space character /\s\x{00a0}/u with a regular space for all InputfieldTinyMCE when saving.", 'autoload' => true ); } public function init(){ $this->addHookAfter('InputfieldTinyMCE::processInput', $this, 'hookFixNBSP'); } public function hookFixNBSP(HookEvent $event){ $value = $event->object->value; // replace only nbsp with a preceeding space // this ensures nbsp to not wrap words still works $value = trim( preg_replace('/\s\x{00a0}/siu', " ", $value) ); $event->object->value = $value; } }

You don't know swiss-german. That is crazy.

Have you updated the module to 1.0.3 then already but modules manager in admin is showing it's not updated? I'm not sure I understand.

Oh, I shouldn't have said that! One thing I remember was that language packs are installable via modules manager? Just really only 1-2 minor things, I get that's the perspective I have as a PW long time user.

So for the modified, just ignore it for now. Depends much on how Ryan will handle the modified date on module directory. Regarding the versions, the "modified date" wouldn't always mean the module has updated its version. It could as well be an readme update or just the maintainer updated the modules info page. ModulesManager only looks for the version of the module to mark an newer available version.

#1) https://processwire.com/talk/topic/5000-module-repository-last-updated/

This has come up already... Module config doesn't work with language fields. Since its stored as json and you are actually using inputfields here not fields. Look at LanguageSupportPageNames how it can be done. Apart from that your code would be wrong. It's InputfieldTextareaLanguage with inputfield type InputfieldTinyMCE.

$user isn't updated since you're in a template and $user was set before you execute this code. $users->setCurrentUser($u); echo "<br />After setting current user: " . wire("user")->name So the new current user would only be available via wire("user") or $users->getCurrentUser(), that will get the new current user.

You don't need to overwrite $page. And the 404 is usually: throw new Wire404Exception(); And how about echo $child->render(...); ?. PW never does echo something.

One way without module would be to just enbale urlSegments on home/root template. Then do create urls with domain.com/1003 Then in the template something like this: if($input->urlSegment1){ $id = (int) $input->urlSegment1; $p = $pages->get("id=$id, include=hidden"); if($p && $p->id && $p->viewable()) { echo $p->render(); } else { throw new Wire404Exception(); } } else if(count($input->urlSegments) > 1) { throw new Wire404Exception(); }

Any more useful infos or code that shows what you're talking about?

Ah, sorry it's not $page->pagefieldmulti->has(1001) then it would have to be a selector if($page->pagefieldmulti->has("id=1001")) ... if($page->pagefieldmulti->has("id=1001|1002)) ...

It's not me it's PW having a designed built in solution. If you hardcodre it into textile textformatter it should be optional.