BitPoet

At least for links to pages, you can enable the builtin link abstraction feature that came with PW 3.0.6. I haven't used it myself (wrote my own link abstraction shortly before 3.0.6 came out and mine ties into other modules/workflows I use), but from what I saw in the code, it should deal with any path changes on its own. You're left to handle images yourself though (I think).

Any spell checker plugins active in the browser?

Status update: JsonNativeField version 0.0.4 now has configuration options for all field types in the field's input settings. Coming up next is some more data validation (i.e. "don't shoot your foot" checking) both in the UI when switching input type and in the module code when saving to and loading from the db. This will be the major step towards moving the module from alpha to beta stage.

The field needs to be of type File (or Image if the added files are images to be used as such e.g. in CKEditor).

I admit I haven't thought too much about nesting, and the wiring around the field's json data would obviously need to be completely different. InnoDB does support searching in nested structures, but PW already treats subfields on the left side of a selector in its own way and throws away anything starting at the second full stop. A different syntax would be necessary, e.g. $pages->find('jsonField=/subField/field:foo') There might be issues where search expressions need some kind of escaping (e.g. searching for literal text "/subfield"), but this would allow for wildcard queries. $pages->find('jsonField=/subField/*/name:foo') Or even searching arrays (any element or by index): $pages->find('jsonField=/subField/fields#*/name:foo'); $pages->find('jsonField=/subField/field#12/name:foo'); Here's a tiny adoption of my module to allow this search syntax. There's no back and forth conversion though, just a textarea containing the JSON. <?php class FieldtypeJsonDocument extends FieldtypeTextarea implements Module { public static function getModuleInfo() { return array( "title" => "Fieldtype Json Document", "summary" => "Fieldtype utilizing native MySQL support for searching JSON documents.", "version" => "0.0.3", ); } public function getMatchQuery($query, $table, $subfield, $operator, $value) { $database = $this->wire("database"); list($path, $value) = explode(':', $value, 2); if(empty($value) && !empty($path)) { $value = $path; $path = ""; } $path = '$' . ((empty($subfield) || $subfield == "data") ? "" : ".$subfield") . (empty($path) ? ".*" : str_replace('/', '.', preg_replace('~/?#(\d+|\*)~', "[$1]", $path))); $table = $database->escapeTable($table); $value = $database->escapeStr($value); if($operator == "=") { $query->where("JSON_SEARCH({$table}.data, 'one', '$value', NULL, '$path') IS NOT NULL"); } else if($operator == "*=" || $operator == "%=") { $query->where("JSON_SEARCH({$table}.data, 'one', '%$value%', NULL, '$path') IS NOT NULL"); } else if($operator == "^=") { $query->where("JSON_SEARCH({$table}.data, 'one', '$value%', NULL, '$path') IS NOT NULL"); } else if($operator == "$=") { $query->where("JSON_SEARCH({$table}.data, 'one', '%$value', NULL, '$path') IS NOT NULL"); } $this->log->message($query->getQuery()); return $query; } public function getDatabaseSchema(Field $field) { $engine = $this->wire('config')->dbEngine; $charset = $this->wire('config')->dbCharset; $schema = array( 'pages_id' => 'int UNSIGNED NOT NULL', 'data' => "JSON", // each Fieldtype should override this in particular 'keys' => array( 'primary' => 'PRIMARY KEY (`pages_id`)', ), // additional data 'xtra' => array( // any optional statements that should follow after the closing paren (i.e. engine, default charset, etc) 'append' => "ENGINE=$engine DEFAULT CHARSET=$charset", // true (default) if this schema provides all storage for this fieldtype. // false if other storage is involved with this fieldtype, beyond this schema (like repeaters, PageTable, etc.) 'all' => true, ) ); return $schema; } public function getInputfield(Page $page, Field $field) { $inputField = $this->modules->get('InputfieldTextarea'); return $inputField; } public function install() { if($this->config->dbEngine != "InnoDB") { throw new WireException($this->_("InnoDB database engine needs to be used for native JSON support")); } $dbver = $this->database->getAttribute(PDO::ATTR_SERVER_VERSION); if(version_compare($dbver, '5.7.8', '<')) { throw new WireException(sprintf($this->_("MySQL Server version needs to be at least 5.7.8 for fully working JSON support, installed version is %s"), $dbver)); } } } There would probably be a bit of recursive shuffling necessary in sleep-/wakeup-/sanitizeValue to build nested structures based on WireData/WireArray so accessing subfields and filtering PageArrays is possible, but that should be doable too. How difficult the backend input + display parts get depends solely on your exact requirements.

Does your uploadhelper.php create a new page? If yes, it needs to be saved once before assigning to any file/image fields. If you assign to an existing page, make sure that you in fact retrieve the correct one (and not the NullPage instance returned when a $pages->get call finds no matching page).

There's $pages->getById(): <?php $ctas = ...; foreach($pages->getById($ctas) as $p):

What I meant was comparing regular web server logs. Assuming you're using apache, you can enable logging for mod_rewrite and see if requests to /some/path are correctly re-written to /index.php?it=/some/path. If you can't see anything wrong there, I'm at a loss too. A good place to hook would probably be Pages::saveReady.

I'm not sure if my module would really fit this task, as this seems a rather straight-forward use of page tables while JsonNativeField is for free-form key-value storage per page without constraints. It's also a few weeks from being complete enough to use in a real world scenario. As for switching database engine: changing an existing database is a little more involved than just changing a config entry. I wrote a script to automate the conversion a while ago:

Unexpectedly found a half day to spare, so I've pushed 0.0.3 to GitHub. New features: Field settings for custom date, date+time and text fields can now be made on the inputfield's input tab, e.g. date and time formats, placeholder text or text validatoin patterns (numeric field settings are on the todo list) Names for custom fields are limited to start and end with ASCII letters and only have alphanumeric ASCII characters and hyphens in between Custom field name of "data" is silently stripped to avoid bollixing up all entries The custom fields table in the backend is now sorted by name (new entries simply get appended) The module is still alpha. Things are getting smoother, but there are still a few items on the todo list.

No, the true culprit is here: protected function ___renderList() { $out = "\n<ol id='{$this->id}_items' data-id='{$this->id}' data-name='{$this->name}'>" . $this->renderListItem("Label", "1", "itemTemplate"); The pageSelected function in InputfieldPageAutocomplete.js then checks if the select page's id equals the value in the item template, and with "1" matching the id of "home", it returns without appending the page. I can't definitely say if this is intentionally excluding home, but my guess is that it was only meant to exclude items already present in the list in whatever scenario those might occur. In that case, excluding the template item in the selector for the duplicate checks would be sufficient: pageSelected: function($ol, page) { var dup = false; $ol.children('li:not(.itemTemplate)').each(function() { var v = parseInt($(this).children('.itemValue').text()); if(v == page.page_id) dup = $(this); });

I admit that I don't have too much clue about all the steps and timings in FileCompiler, but it does look like something got bent around to cause the endless recursion. Perhaps deleting the jumplinks directory in site/assets/cache/FileCompiler and deleting the database entry in the caches table cures the problem? If yes, it's likely some kind of naming clash, though that may already be fixed by your latest changes.

Does moving your module code out of the PW path fix anything?

I've run some local tests, and I can't reproduce the problem. Can you make sure there isn't any external software (firewall/proxy, browser addons etc.) interfering with the request, i.e. compare the request URI sent by the browser and the entries in the web server rewrite and access logs? The whole URI should be passed to index.php in the "it" GET parameter. If it is, I'd also take a look at third party modules as a possible culprit.

Just a short update: if MySQL (or the OS it's running on) and PHP are configured with different time zones, results will be wrong. You'll likely not notice anything off on local dev environments where everything is configured with the same time zone, but to prevent issues on deployment, MySQL needs to be made timezone-aware and PW's database connections need to tell MySQL which timezone to use for conversions, which should IMHO be done through a not-yet-existing $config property. That's why I've filed feature request #19. I'm now holding my fingers crossed and waiting to hear if it gets considered. This will mean that, assuming it does, the module will require at least the PW version that gets the new $config property.

Could it be that the .htaccess file got convert to an ISO encoding?

Depending on how mod_security2 was built, it might not be possible to disable it in .htaccess.

LazyCron is a core module, a compatible version should be in the wire/modules folder.

There's the option to publish/unpublish pages with the Schedule Pages module if you want to completely avoid custom code, though deleting/trashing pages based on a field value is just a few lines with the Lazy Cron module.

Just a quick status update: I've started implementing different field types (text, integer, float, date, date+time) with native inputfields. Types can be switched back and forth, and I'll make it hookable so custom inputfields can be added as well. Will be a while though, since it looks like I'll be busy with a lot of other stuff until the end of next week. Here's a teaser though...

Done.

Might also be a memory issue or a case of format incompatibility between your images and GD. Maybe this thread could be helpful:

What seems a bit strange is that the full image is displayed alright on click on the thumbnail, but the thumbnails and pwimage don't work. If it were read permissions, the full image shouldn't be visible either. My first three items to check would be: Third party modules Apache's mod_security Browser security plugins The raw requests made for the thumbnails might also be worth a look.

Another proof-of-concept module: JsonNativeField Leverages MySQL >= 5.7.8's native JSON column type for key-value storage. This gives us the opportunity to store arbitrary (textual) fields in the database and allows us to search for them with plain subfield selector syntax, including wildcard operators. Possible applications are storing submitted form data or adding user-defined properties to their profile. Currently, the module is still really, really alpha, but I wanted to get input early on. Let me know what you think. Download from GitHub. Here are a few screenshots for anybody interested but unable to try for themselves: 1. First page with json field and custom subfields: 2. Second page with json field and custom subfields: 3. Searching through all subfields in the json field: 4. Searching only in a specific subfield: The interface is really rather crude still. The "delete" buttons only work after saving (have to attach listeners to the newly created entries yet), and I've got to straighten out supported operators for Lister to pick up. I'll see if I find some time tomorrow to work on these issues and brush up the visual side a bit.

I can't test it right now, but one thought is that maybe user language might not get initialized correctly for the instance. Does setting the language explicitly before retrieving the subjects help? $mi_studiehandbok->user->language = $mi_studiehandbok->languages->get('default');