BitPoet

I'd expect that calling $cachedPage->yourcommentfield->renderForm() in your uncached page's template should do what you want.

There's a typo there, it should be "->" instead of ">-", sorry for that. <?php // Expressive version: echo $p->nativeField->get('fifth-row')->value; // If the native field's name adheres to PW's field name rules, you can shorten that: echo $p->nativeField->fifthrow->value; // Stringification returns the stringified value, not the object echo "{$p->nativeField->fifthrow}"; That would be another step further. For now, it's just configuration options for each different kind of input (text, int, float...). I'm not sure if that would offer much advantage over regular fields, but I'll give it some thought.

I've changed that so it only checks for minimum MySQL Version. Still, the module is very much alpha code and work-in-progress. I haven't gotten around to apply and test the field type configuration options, and there are quite a few rough spots in the existing code. FYI, I decided to rename my helper classes as I realized that JsonData and JsonValue may make nice names for core classes. To avoid clashing and hogging names I've prepended "JN", so it's JNJsonData and JNJsonValue now. The new release is still in testing stage and can be found here.

Hi Ivan, I never really looked at API usage up to now (and once I did, I noticed that the module really should be namespaced). Here's a short example for filling values in code: <?php namespace ProcessWire; /* Fill the JsonNativeField field "nativefield" in Page $p through API */ $fdata = new \JsonData(); // This is the class for a JsonNativeFieldValue $fdata->set('first-row', new \JsonValue('text', 'Text in first row')); $fdata->set('second-row', new \JsonValue('integer', 123)); $fdata->set('third-row', new \JsonValue('float', 3.1415927)); $fdata->set('fourth-row', new \JsonValue('date', time()); $fdata->set('fifth-row', new \JsonValue('datetime', time() + 3600)); $p->of(false); $p->nativefield = $fdata; $p->save(); /* Change value for "fifth-row" in our field */ $p>-nativeField->set('fifth-row', new \JsonValue('datetime', time() - 3600)); $p->save();

Call $table->setEncodeEntities(false) before rendering.

Unless things changed lately, MAMP activates OPCache by default. Make sure that the following settings are the same in your php.ini: opcache.validate_timestamps = true opcache.revalidate_freq = 0 Also check in MAMP config settings if caching is enabled for PHP (not sure if that option is still there, but with PHP 5.5, you could enable frontend caching).

You have to add the buttons in the CKEditor Toolbar configuration in your field's input settings. Unfortunately, this is another core CKE plugin where the basic documentation is hard to find, but a peek into its source helps. The valid names for toolbar items can been found by looking for calls to addButtonCommand(). Two toolbar entries are missing in my example: ImageButton and HiddenField.

Or going the other way round, adding the pipe to the whitelist (and forcing quotes for it): $ptions = [ 'whitelist' => ['|'], // selectorValue() normally strips out pipe symbols, so allow them 'quotelist' => ['|'] // Have selectorValue quote values that contain a pipe symbol ];

You should also be able to see the Ajax request and the returned data that causes that error in the dev console. This should give you more of a clue, as the error reads like the returned data isn't JSON at all. It's probably an error or warning from PHP that JS tries to parse.

An itemClass would accomplish the same as adding your class to itemMarkup. I'm not sure where exactly the problem lies, but you could test if adding your desired class before or after the {class} in itemMarkup solves the issue if it's a simple case of precedence within identically specific selectors.

It's possible using the native permission system by creating page-edit-lang-[language] permissions, i.e. both page-edit-lang-default and page-edit-lang-de (or however German language is named in this PW instance) and only giving page-edit-lang-de to your translators (your regular editors roles gets both). To prevent translators from changing non-multilanguage fields, you also need to create a page-edit-lang-none permission and assign that to the regular editor roles, but not the translator role. This blog post gives a good introduction to the underlying concept.

Just to add, if the points from @ryan and @horst aren't enough (they should boost import times quite noticeably) you could try dropping the FULLTEXT keys on the relevant fields' tables before the import and recreating them afterwards (ALTER TABLE `field_fieldname` DROP KEY `data` / ALTER TABLE `field_fieldname` ADD FULLTEXT KEY `data` (`data`)). Finally, a big part of MySQL performance depends on server tuning. The default size for the InnoDB buffer pool (the part of RAM where MySQL holds data and indexes) is rather small at 128MB. If you have a dedicated database server, you can up that to 80% of physical memory to avoid unnecessary disk access.

@kongondo's FieldtypeRuntimeMarkup can do exactly that. You just need to add a snippet of code to retrieve and output the relevant messages.

Does the dev console give no hints?

Try renderPager() instead of renderPages(). And remove start=0, this prevents MarkupPageNav from increasing the offset. Only use it when you explicitly don't want to paginate your results. A number of times. I've put together a small example that works with the skyscraper demo since my original content is too specific. You can download the profile for that site here on GitHub and copy it into a (uninstalled) PW installation, then install PW with the skyscraper site profile (make sure to read up on the FieldtypeMapMarker issue in the README on GitHub). After installation, drop the template file from the attached zip into the templates folder, log into the backend and create a new template "paginated" for the file. In the template's URLs settings, enable page numbers and url segments. Then create a new page under home with the new template, give it a title and publish it. Voila, you should be ready to go. When you visit your new page, it should look like this: The pagination links should load the content through ajax. paginated.zip

Have you switched section 16A for 16B in .htaccess?

When you iterate over $single->zasvojenosti_select, you only get those page references that are select. You need to iterate over the possible choices like you do in the header instead. <?php foreach($pages->get(1067)->children() as $child) { if($single->zasvojenosti_select->has($child)): ?> <td>Yes</td> <?php else:?> <td>no</td> <?php endif;?> <?php } ?>

The keyword ist multisite. Have a look at @Soma's MultiSite module. It's discussed here:

TextformatterHannaCode is a nice multi-purpose tool for tasks like that. If manually addressing the correct files becomes an issue, then HannaCodeDialog is also worth a look. It integrates with CKEditor and lets you assemble small UIs for your Hanna codes.

I meant the "Zulässige(s) Template(s) für Unterseiten" part, but that's apparently not it either. Are there any family restrictions set for the other templates that prevent them from showing up in the list?

Make sure you haven't checked "Don't allow pages to change their template" on the Erweitert tab of your dummy template, and the user has page-template permissions. If that doesn't solve it, it could also be a family restriction on the template used by the parent page.

Looks like I have. Found a classic case of shoot-your-foot in the affected installations where I generously added some JS in a ProcessPageEdit::execute hook, my InputfieldFile change was wholly innocent. What I did find was a race condition between the first few added files, so there was one upload more active than configured in the beginning. I believe I caught that with a setTimeout. I still have to tweak that timeout, run a few more test drives and meditate over reasonable defaults, inline documentation and such, but it's taking shape.

Have you tried this: $regionEvents = $pages->find("template=veranstaltung,selectLocation.parent.parent=$reg,limit=$limit"); If this doesn't work, a subselector might be the tool of choice: $regionEvents = $pages->find("template=veranstaltung,selectLocation=[template=location,has_parent=$reg],limit=$limit");

Yes, it looks like the new PHP version is missing the Ctype extension. Either the package needs to be installed or the entry in php.ini needs to be added/enabled.

I'm not sure he will. Generally, a new feature needs to be used by an estimated 30% of users to be accepted into the core. There are, however, exceptions to the rule - especially where hosting issues are concerned. I'm not happy with my adaptions yet, though, since they work on some installations here but not on others. I'm still on the lookout for the issue there. However, once I work out the kinks, and if the change doesn't have to get more complicated, I think it could have a good chance to be accepted (adding a feature request at processwire-requests and finding others who vote for it would certainly help).