LostKobrakai

Also keep in mind that these functions are sometimes disabled for security reasons, depends on the hoster.

I'm not sure if we're talking about the same thing. You would only once set up a template, which can show a gallery and then use this multiple times. If you're saving the images for the galleries as part of your content-type or as part of the subpages which shows only the gallery is up to you. And if you don't want to create those subpages by hand than have a look at urlSegments. My last post links to a tutorial about it.

You could do this by creating seperate templates for each of those sites. You could devide the content and gather the information from the subsites to show them on the main site or leave all content in the main site in the backend and let the subsites be empty (besides title) and call content from the main template. bio (all content saved here) - location - some other page or bio (some content, rest from subpages) - location (some content) - some other page (more content) Another way would be without creating separate templates and just using urlSegments on the /bio template. If your templates share parts of the design (markup or logic), than take a look at this topic about including partial content.

Great, one last thing: I don't know how you could do this, but from the interface it seems that one could choose multiple classes to extend. While previously selected classes get replaced if you try, it would be really great if it would be noticeable beforehand.

For the most part, yes. Also keep in mind that sometimes the index.php or .htaccess can change, too. As long as you're not using any new features from the dev branch it should work without problems.

Process module do not need to implement Module. Process already does, so the "extends Process" is enough. Also if I choose Process as type the tag for it's extend seems to be transparent or lighter in color. Edit: It's the disabled state… But then the x to delete should be hidden. For the FAQ you could add a line how to change the headline like here.

ProcessWire will do so, as long as the name is automatically converted from the title. As soon as you're changing the name by hand this is not the case anymore.

Would it be possible to add FieldtypeOptions to the supported fields? Currently it's not working. P.S. Maybe the preview shouldn't close on clicking. It's throwing an error for me, but with SystemNotifications installed one can't look at the whole error message, because the click on the number closes the preview.

If you created the _init.php yourself, then have a look at it's chmod. Maybe the apache service on the vps can't open it because of that. If it's from a site profile, than it should have the same chmod as the other files, so it should work as long as you can access the backend as well.

You could automatically update extends/implements for Process modules. They're just extending Process. Also I'd suggest adding a placeholder name after the prefixes to avoid overwriting the base classes if one does not add his own name (e.g. ProcessName instead of Process). Also it would be nice if the form would adapt to show the options for creating a page automatically for Process modules.

I'd definitely vote for starting from scratch. If you really want to reuse parts than just copy and merge them into the new templates. This avoids unnecessary clutter from the old templates/styles. For the Foundation thing. There's nothing special about Foundation, it's just some css/js. If you're unsure about how it works I would suggest just taking the any of your sites and try to rebuild it in a static html with the building block you'll find in the docs of the framework. This way you'll get used to it. It's mostly just some special classes and sometimes specific markup, but you should get started by copy&pasting from their examples. Also Foundation is really baseline from the styling perspective, so you'll need to put your own styles above this baseline. It's more about providing a gridsystem and some responsive components.

Maybe the dev branch should be made the default, so we can at least use the github search xD

There's no need to justify why a module exists. It's always nice to have options, even if they solve the same thing in different ways.

$user->usergender is not the id of the selected field it's the label. Just like you would get the page from a pagefield and not the id. This will get you the id. $user->getUnforamatted("usergender");

Locking in LazyCron is done with a file (https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/LazyCron.module#L149). That works no matter how your module is called or instanciated.

These message and error functions are coming from the Notice class and are not related to the logs, but you can set the flag Notice::log or Notice::logOnly, so they get logged to the messages or errors log. You could extend this to add your own notices, which will be logged to your log file and show up as notice. The FileLog.php is essentially what the api has to offer. I can't see what more you're expecting from it. It's about writing log-messages to a file.

For process locking you could take a look at LazyCron. Integrating the ProcessWire logging api shouldn't be much of a hassle (http://processwire.com/api/variables/log/). You can just create a own log file and use it.

I'm talking about actual copy&past of the array. Nothing fancy here. $this->addHookBefore('InputfieldForm::render', $this, 'modifyMarkup'); public function modifyMarkup($event){ $form = $event->object; $form->setMarkup($yourModifiedMarkupArray); }

The inputfield never knows where it's used. $this->addHookAfter('ProcessPageEdit::buildForm', $this, 'populateField'); public function populateField($event){ $page = $event->object->getPage(); $form = $event->return; }

You don't need to access it. Copy the array to your module, remove the keys you don't need to change, change the markup of the leftover ones, set it to the form with the mentioned function. To get the form you need to use an other hook as InputfieldWrapper::render, which is not aware of the form it belongs to. The wrapper hook would rather be needed if you need to change the markup directly and not via the $defaultMarkup array.

A .htaccess rewrite rule should do it. I'm just not good enough with it to give you a written rule.

http://modules.processwire.com/modules/fieldtype-concat/

The api variables are only available in the template scope. They aren't global in any way. As soon as you're creating a function you create a new scope, therefore the variable is not accessible anymore. That's the reason for the above posted ways to access the api.

Look at $form->setMarkup().

InputfieldWrapper::render is quite a beast of a function. Either you try to edit the markup strings of $defaultMarkup or if that isn't enough for your case it's most likely the easiest to modify the markup after the function is done.