LostKobrakai

Yeah, it's essentially doing the same as in the GUI, so it does have all the default settings already. If you want to understand the api of processwire it can be quite enlightening to just look into the core modules and see how things are done there.

That's strange as the admin interface probably does use that exact method when installing a module. Can you install FormBuilder via the gui in that stage?

It's best to handle the actual resizing in code, but something like 3k x 1k images certainly shouldn't be resized on client requests. There are various topic here on the forms and two module (Thumbnails and CroppableImage) which handle resizing of images on upload rather than on request. Also for such large images you'd need to make sure the server does have enough ram available for php to actually process those images, because the images need to be loaded uncompressed into the ram (around 30 MB only for a single image of that size).

I've directly commented my changes in the code. <?php echo "Starting...\n"; include_once("../index.php"); /** * API Variables are only available through the $wire variable * or the wire() function. https://processwire.com/api/include/ */ if (!wire('modules')->isInstalled("FormBuilder")) { /** * Not needed */ // require_once("./modules/FormBuilder/FormBuilder.module"); include_once("./install-config.php"); echo "Installing Form Builder\n"; echo "-------------------\n"; if (!file_exists("./install-config.php")) die("install-config.php not found"); /** * I hope $config is a variable comming from install-config.php */ if (!$config->formBuilderLicenseKey) die("Missing Form Builder license key"); /** * No need to do this manually, let FormBuilder install itself * * Hint: PW does have some neat helper functions for filesystem task if you need them. * See /wire/core/Functions.php for them. */ // Create cache directory // $filesPath = "./assets/cache/form-builder"; // if (!is_dir($filesPath)) { // if (!is_dir($filesPath)) { // if (!is_dir("./assets/cache")) { // mkdir("./assets/cache"); // } // mkdir($filesPath); // echo "Creating formbuilder cache directory at " . $filesPath . "\n"; // } // } /** * Refresh modules and install FormBuilder */ wire('modules')->resetCache(); $formbuilder = wire('modules')->install("FormBuilder"); if(is_null($formbuilder)) die("FormBuilder wasn't installed correctly"); $data = json_decode(file_get_contents("./metadata/formBuilder/modules.json"), true); /** * Install config data */ if ($data) { foreach ($data as $class => $data) { if ($class === "FormBuilder") { $data['licenseKey'] = $config->formBuilderLicenseKey; } wire("modules")->saveModuleConfigData($class, $data); } /** * Not needed and what's $handle? */ //closedir($handle); } }

To clarify Soma's answer a bit: $newNameSave = $sanitizer->pageName($newName, Sanitizer::translate); It's a class constant not a string.

Im judt using a modified concat module, which parsed a string with tags to something a lister can print out.

Could you just post that part of your code, that will make things easier and more clear to explain.

Why not simply $this->modules->install("FormBuilder");? And to set the modules settings (api key and so on), see this: https://processwire.com/talk/topic/648-storing-module-config-using-api/ Also just to make this clear beforehand, hookable function (these with the three underscores) are called without those underscores. These are only there to mark those functions as hookable.

Not sure if this is overkill, but it's self-hosted: http://sdelements.github.io/lets-chat/ Or if you want to take a look at meteor / node, something like this: https://www.codementor.io/meteor/tutorial/getting-started-with-meteor-build-sample-app

Adding the new page to the inputfield is not trivial as the actual code does completely depend on the used inputfield. With a few 3rd party inputfields this will be quite some work if all of them should be covered.

That's the difficult part as nobody can guess if you really want those fields to change or if you've maybe changed one of those fields just for that single template and won't want your changes to be overwritten.

This depends on how the inputfield that you're getting the data from is set up.

Oh, you're right, I missread the selector of Ryan, which also seems to be way more elegant than mine.

I'm not sure how many of you saw this great promotional website (http://devtoolschallenger.com/) that some folks created for mozilla. If not you should certainly check it out, not just because of the tools which are promoted, but also because of the great story and information of the website itself. I'm also curious what you guys think of the Firefox dev tools, especially with the "Developer Edition". Because of this great promotion I'll use it the next week and see how it goes, but I did long hesitate so switch back from Chrome. I've taken a look every now and then at the Firefox native tools, but somehow it never clicked and there was always something missing or managed in a strange way so I stayed with Chrome.

@kongondo $dateStr might be confusing, as it's NOT a string anymore

You can get the timestamp of the date when accessing the unformatted field data like so: $ts = $page->getUnformatted("datefield"); $day = date("d", $ts); $monthYear = date("F Y", $ts);

Is this subfield stored in the db or just runtime generated? When you're not using limit in the selector you could try to sort the result in memory after getting it from the db.

The extend is basically just an replacement for an interface, which conveniently can hold some helper methods I'm using. It's also extending Wire so all the ProcessWire api variables are injected and accessable by e.g. $this->pages or $this->templates. There's nothing framework behind this. The execution does in my case happen in an Process module, that does just list all the available migration classes and shows and update/downgrade link to run them. But you can call those classes anywhere, just make sure to bootstrap processwire, so the api is available, before executing any of the migration methods. abstract class Migration extends Wire{ public static $commit; public static $description; abstract public function update(); abstract public function downgrade(); […] // Few non abstract helper methods }

They surely do, but you're still responsible for any call with that api key.

While ryan's code does certainly work you should be aware that this code wouldn't find events, that are longer than the mentioned "5 days from now" but still currently active. Such events could start before today and end after more than 5 days. To catch those as well you'd need another OR option like you can see in this topic: https://processwire.com/talk/topic/10682-help-with-date-range-selector/

@Bernhard Which geocoding service are you using? You should certainly make sure you or others do not braking any usage limitations that you accepted.

Exactly the way I posted above. How else would your browser get your requests to the right server if there wasn't a way to get the ip address behind a domain.

The module is quite uninteresting. It's just generating a list of those mentioned classes. But I can show you what I mean by migration (not db migrations, which would be tedious as shit). The Migration class is just an abstract class, that does make sure everything is according to contract and holds some helper methods not used here. And it's extending Wire so all the processwire api variables are injected properly. class Migration_2015_10_22_13_15 extends Migration { public static $commit = ""; public static $description = "Install MapMarker\nCreate map fields"; public function update() { $this->modules->install("FieldtypeMapMarker"); $from = new Field(); $from->type = $this->fieldtypes->get("FieldtypeMapMarker"); $from->name = "travel_from"; $from->label = "Start"; $from->defaultLat = "…"; $from->defaultLng = "–"; $from->defaultType = "ROADMAP"; $from->defaultZoom = 14; $from->save(); $fg = $this->templates->get("invoice")->fieldgroup; $last = $fg->get("annotation_internal"); //annotation_internal $fg->insertAfter($from, $last); $fg->save(); } public function downgrade() { // Remove fields $f = $this->fields->get("travel_from"); foreach ($f->getFieldgroups() as $fg) { $fg->remove($f); $fg->save(); } $this->fields->delete($f); // Remove module if($this->modules->isUninstallable("FieldtypeMapMarker")){ $this->modules->uninstall("FieldtypeMapMarker"); } } } Edit: This is more about building up the same state everytime instead of migrating a current state over to another installation.

If you really want to use automatic deployment you need to do it the same way as in every other framework and not use any GUI at all for everything which needs to be created in the deployment. I recently created just a small process module, that does list all migration classes in a certain folder, which do just have a update and downgrade function. With the api and some small helper functions one can mimic the things you do in the GUI quite easily and you've the benefit that every change is also source controlled (and/or versioned). I'm currently using it manually, but these can also be called automatically by a deployment script.

Multilanguage field would mean you can supply mutliple translations to a single language, that's certainly not how it's supposed to work.