Soma

This sounds like best option to go for pages. Scalable flexible ...easy

Since I'm not keen to do the work for everyone here, as I already had done a lot and multiple times in this very thread. It's all here and more even in the readme of this module. With a little study you'd be able to do what you wan't.

@einsteinboi This setup is somehow strange and very unusual. I try to avoid having too much classes. For example no need for classes on <a> items. It's more flexible if using class only on <li>'s since you can style containing links. You now have twice the class for a dropdown: <li class="dropdownSubmenu last"><a href="#" class="hasSubMenu">Sub menu</a> ... Makes no sense and don't see why that's needed. A lot what you have in the markup example doesn't make sense to me to do it this way. I usually build my navigations with little to no classes and work with what MSN has by default, instead of trying to adapt MSN. With right CSS and JS every type of navigation is possible without doing much. You can however modify a lot with MSN options and simple hooks. Almost everything is possible, and even if it takes some time, writing own nested lists with all those features wouldn't be less difficult.

Ah just see the google maps urls have changed since then, so no chance to get this working.

What is normal website? The date published?

I tried this module and it doesn't seem to recognize the maps url something like

Is the form-builder page active in that language?

Sure, ever heard of google? That thing that knows all? http://bit.ly/1p1YWuB

Maybe read the docu again https://processwire.com/api/variables/input/ Youre really a hard nut

Url Segments only work for segments that are not already a page.

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.