BitPoet

You're inside a function, so there's no global $datetime object. wire('datetime') should do the trick.

Yes. Sorry. Not sure what's the error with wireEncodeJSON, might be a namespace issue or something else. But your code looks fine to me. Maybe outputting $jsConfig in a comment block or calling json_last_error_msg() can give you a clue about the empty array.

By default, the ProcessWire object is only output in the backend or if you have frontend editing active. Otherwise, you need to add it to the html head in your your php template like this: <script> var ProcessWire = {config: <?= wireEncodeJSON($config->js(), true, $config->debug) ?>}; </script>

The topic comes up regularly, so there's already a ton of information in the forum. If url segments for the building template aren't needed, this solution should cover the requirements:

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.