BitPoet

My first suspicion would be a Textformatter that might be active on title_formatted and add the a tag.

Sure that these pages really don't exist (perhaps just PageTable entries that live under tree-info)? Not directly related (as it might cure the symptom but not the issue): for a site-wide search, it's often a good idea to limit the templates targeted in the search.

The module has been lying around on GitHub for some time now, so I thought I'd give it its own forum topic so I can give it a module list entry. SymmetricEncryptedText Symmetric encryption for text based fields (supports multi language fields). Module page. Link to the GitHub repo. Description This module adds an encryption option to all text fields (and those derived from FieldtypeText). Field contents are encrypted using a symmetric key when a page is saved and decrypted when loaded from the database. The module by default uses sodium (if loaded) in PHP versions >= 7.2, otherwise it falls back to the bundled phpseclib. Multi-Language fields are supported too. WARNING! Setting a field to encrypted and saving values in those fields is a one-way road! Once encrypted, the contents cannot be unencrypted without writing a program to do so. Disabling the encryption option on a field after the fact gets you encrypted "garbage". Usage Download the zipped module through the green button at the top right of the GitHub repo or (once available there) from the official PW module repository Extract in its own directory under site/modules. In the backend, click "Modules" -> "Refresh", then install "Symmetric Encryption for Text Fields". Go to module settings. An appropriately sized, random key will be generated if this is your first use. Copy the supplied entry into site/config.php Add fields or configure already present fields. On the "Details" tab you can enable encryption for the field in question Edit a page with such a field, enter a value there, save and enjoy Existing, unencrypted values are left untouched until a new value is saved. That way, you can do a smooth upgrade to encryption, but you have to save all pre-populated pages to have their values encrypted in the database. Thus it is recommended to avoid adding encryption to already populated fields. Advanced Usage You can hook after SymmetricEncryptedText::loadKey to retrieve your key from somewhere else, e.g. a different server.

Just insert a "Timestamp" entry in the CKEditor Toolbar field wherever you want it to appear.

Are you working with one of the shipped site profiles and the basic-page template?

Thanks for pointing that out. I never changed that setting in production, so I didn't think of that. The latest github master (0.1.4) now uses the settings defined in TextformatterHannaCode's config both when inserting the pattern and as the trigger for autocompletion.

Like you do with "title", you reference the images field by its name (look in the field settings if you are unsure). So $child->images gives you the images field. Depending on whether you have set the field to hold one or more images, it returns either a Pageimage instance or multiple images in a Pageimages instance. In the latter case, you have to state which image you want to get, e.g. with $child->images->first. Each image field has properties like url, (file)name, description or tags. To "output" the image, you have to output the correct HTML. <?php // image field set to single image and named "image" foreach($page->children as $child) echo "{$child->title} <img src='{$child->image->url}'>" ; // image field set to multiple images and named "images" foreach($page->children as $child) echo "{$child->title} <img src='{$child->images->first->url}'>" ;

That would be nice, I second that, but the truth is that not all modules are incompatible with older PW versions just because the author never updated compatible versions. Lots of older modules still work because the file compiler upgrades them smoothly and there is no incompatible API call or deprecated PHP function used. Perhaps we should have an entry in module info listing compatible versions, that way changes in the source code repository to that entry would be immediately reflected in the module list. We (as in "the module authors") would probably still need an email reminder when a non-minor version upgrade occurs (like the imminent bump to 3.1) to check and update all modules in that regard. I'm not a fan of the "follow the other flies" concept - it's one reason why so many people install bad plugins in WP even though there are newer and better ones available.

After building the ProcessMentions module and another autocomplete module for images, I found that I am going to need even more of these, but things were going to get repetitive. So I refactored the whole thing into a basic autocompletion module and individual "actions". The result is Autocomplete for CKEditor (GitHub). To try out, Install the module and actions Enable actions in the settings of any CKEditor field Edit a page with this field, type "@" and some characters for the and enjoy There are still a few things I need to implement. ATM, it only supports single characters as triggers for the autocomplete. I'd like to change that to combinations so I don't run out of special characters at some point. I also have to add a few more configuration options (like search only at the beginning or also in the middle of the searched string). The documentation for custom styling also needs some work. I have tried to keep things generic. Implementing your own actions should be quite straight forward. The README at GitHub illustrates the main steps and the supplied action classes have inline documentation. I would love to get some feedback or even see some third party InlineCompleteAction implementations.

It's a known issue that was fixed in 3.0.80.

It stays encrypted. Same when you set an encrypted field back to unencrypted. I'm still pondering how to tackle that properly (if at all), since decrypting every occurrence of a field in one go is likely to run into timeouts when the count gets high.

Glad to hear that. I also toyed with asymmetric encryption using phpseclib's pure PHP implementation, and that really did a number on the CPU. Symmetric encryption (and using native code in sodium or openssl) thankfully behaves a bit more deterministic in that regard.

I might be misunderstanding your issue, but it sounds like you are using the pw-modal/pw-panel classes on links. In that case, the link target is loaded into an iframe, which is like a regular page visit, not an ajax call. To use ajax, you'll have to manually fire such a request somewhere using $.ajax and write the javascript code to display the returned value(s).

Were you logged in to the backend when it worked? If yes, you might have a permissions issue.

Here's a short (or not so) proof-of-concept implementation that adds symmetric encryption to FieldtypeText and derived types. Supports multi language fields and uses either AES256 from phpseclib or sodium's sodium_crypto_secretbox if available on PHP >= 7.2. Key creation is done in the module's configuration settings. There's also a hookable loadKey method to retrieve the key from somewhere else (needs to return the base64 encoded key).

No, DatetimeAdvanced just lets you search datetime fields using subfield syntax like "datefield.year=2018" in selectors, directly output those too, e.g. $page->datefield->year, and provides strftime() and date() formatting functions on fields. Input and stored values stay the same.

I started to make that LDAP stuff more generic but got a bit overtaken by changing realities, but I'll take a look and see what I can put together when I find a minute. I'm letting the server itself do the authentication (with IIS not really much to configure) and just let PW take care of authorization. The same can (and used to) be done with apache and an ldap/sasl/kerberos auth module as well. The essential part then are the script that import the users (that one should probably take all configuration from the module, something else I'll take a look at) and relevant groups (using the famous UserGroups module). One of the nice things about PW is that most information (and code) is still current after a few years So stay tuned.

Not sure about anything beside what @kongondo linked, but PW does definitely cache things, both field values and pages. Pages are kept in memory as any calls to Pages::get and Pages::find are routed through PagesLoaderCache. Equally, field values are retrieved only once, as Page::getFieldValue (which is in turn invoked by other get... methods like getUnformatted) only calls Fieldtype::loadPageField if the raw field value isn't yet populated (and $page->fieldname and $page->get('fieldname') both delegate their work to getFieldValue).

OpenSSL is just one possibility. I've also used phpseclib and am just in the process of figuring out libsodium, but all should be viable tools there. I guess standard AES256 and CBC mode should both be sufficiently secure and reasonably well documented, and openssl_random_pseudo_bytes should likely be safe enough in an up-to-date setup. Yes, you can either encrypt or search. I guess offloading en-/decryption to the database server would be possible with specialized field types, but searches would be absolute performance killers (all such fields would have to be decrypted in-memory, then flat table scans would have to be performed).

@Loges: Somewhere in the middle of my (unfortunately growing) todo list is a field encryption module (or, precisely, a whole set of them for different scenarios). The bad news is that it's been there for a while and regularly been overtaken by reality (speak crypto api changes, now a badly under-documented libsodium, breached algorithms, etc.) and I've been hesitant to roll out something that might not be future-proof. You should be able to implement something quickly though if you don't aim for a generic, fool-proof-in-any-environment solution. With PW's hooks api, you could even add encryption to existing field types like FieldtypeText and its descendants. Here's a short rundown of my thoughts that might get you started with your own module: Use symmetric encryption, store your key in a property in site/config.php, make sure to avoid insecure combinations like AES256 with ECB You need at a minimum the following hooks: FieldtypeText::sleepValue where you encrypt the field values for storage in the DB. Be aware that the value passed to that might either be a string or an array of strings (in multi language sites), each of which you need to encrypt. FieldtypeText::wakeupValue where you decrypt the db values for use inside PW. You get either a string value or a LanguagesPageFieldValue object (multi language sites) for which you need to decrypt the value for every language (use getLanguageValue/setLanguageValue). FieldtypeText::getConfigInputfields to add a property (InputfieldCheckbox) that determines whether to use encryption (and is checked inside sleepValue/wakeupValue) in the field's configuration Use a truly random initialization vector (IV) for encryption, which is, depending on PHP version and configuration, sometimes harder than it sounds. Of course, back up your encryption/decryption key really good

@ryan just commited my fix with a little type checking added, so the latest dev version from GitHub will behave nicely and clone _END fields to.

That line number hints at PW version 2.6 or 2.7. Have you tried with a recent release? If the error still persists, it's likely a version/configuration problem on your server. PHP 7 is a bit more opinionated about the return values of session handler functions, and older versions of memcache session handlers didn't always return strings where expected. So upgrading the memcache PHP module might help, or switching to regular file sessions in php.ini would be a workaround.

Keep in mind that the regular processInput method is still called afterwards, so any assignments to the page's fields will be overwritten by the submitted data. You need to fetch the $input argument from $event->arguments(0), read the submitted value from there and assign your computed value to $input["reservationdeadline"] (peek into the POST data in the developer console if you're unsure what date format to use). Don't modify $page, let the regular PW logic handle that part. Though you'd probably find it easier to remove the "required" option and run your logic in a saveReady hook.

and peeked again in the github repo to find that the setLocale part was added in 2017, so 2.7.2 won't have that (yet). So, yes, my line is likely a no-op.

I peeked into the setLocale method in Languages.php ($locale is fetched from the translation in wire--modules--languagesupport--languagesupport-module). } else if(strpos($locale, ';') !== false) { // multi-category and locale string, i.e. LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=C foreach(explode(';', $locale) as $s) { // call setLocale() for each locale item present in the string if(strpos($s, '=') === false) continue; list($cats, $loc) = explode('=', $s); $cat = constant($cats); if($cat !== null) { $loc = $this->setLocale($cat, $loc); if($loc !== false) $setLocale .= trim($cats) . '=' . trim($loc) . ";"; } } $setLocale = rtrim($setLocale, ';'); if(empty($setLocale)) $setLocale = false; } LC_ALL=de_DE is a different case, as it contains no semicolon and is therefore passed verbatim as the value to setlocale.