Didjee

I want to exclude pages with certain templates from Insert link > Select Page. Is this possible using a hook?

Hi @BitPoet, I was wondering if it is possible to get this module working in a Textarea Rich Text (TinyMCE) field within a ProFields: Table field? Now I'm getting the error messages below in TracyAdmin. The Table field 'table_directives' has 3 rows with 2 TinyMCE Textarea fields ('medication' and 'remarks') per row. PHP Warning: Attempt to read property "table_directives_0_medication__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_0_remarks__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_1_medication__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_1_remarks__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_2_medication__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_2_remarks__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_3_medication__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267 PHP Warning: Attempt to read property "table_directives_3_remarks__pages__useAction" on null in .../InlineCompleteTinyMCE/ProcessInlineCompleteTinyMCE.module:267

@virtualgadjo putting title and headline before search_index does the trick somehow ?. Now the ordering of the results is the way I want it to be. Technically I can leave title and headline out of de indexed fields in the module settings.

Hi @virtualgadjo, thanks for your quick response! I was using SearchEngine::find() for the results and not a regular ProcessWire selector. Mainly because with SearchEngine::find() you can use "_index_template" for sorting results by template (see SearchEngine module settings). AFAIK, sorting by template is a not build in feature for page selectors. But I found a way to accomplish that: Now I'm using the code below instead of SearchEngine::find() Results are first sorted by the given template order. After that, pages with $query in title or headline will be shown before pages with $query in search_index but NOT in title or headline. $templates = ["news", "blog", "archive", "plain"]; $results = $pages->find("title|headline|search_index~*={$query},template=".implode('|', $templates)); $sortedResults = new PageArray(); foreach ($templates as $t) { $sortedResults->import($results->find("template={$t}")); } $results = $sortedResults;

@teppo First of all, thanks for this great module! I've used it several times already. For a project I'm working on right now, I'd like to sort the search results like this: First based on indexed templates. This is possible with the "_indexed_templates" option, so no problem. After that, pages where the search term appears in the page title should be placed above pages where the search term only appears in the page content and NOT in the page title. Is this possible when using SearchEngine::find()?

Hi @horst, I have a setup where I use a Repeater for page sections. Elements can be added within a section using a RepeaterMatrix. When I use a CroppableImage4 field within RepeaterMatrix, it cannot be used by non-superusers (eg users with the 'editor' role). If the user clicks on the thumbnail to make a crop, they get the following error message: "Not editable. The process returned no content". I have given the user role the "croppable-image-4" permission. If I use CroppableImage4 in a RepeaterMatrix that is not inside a Repeater, it works fine. So I suspect that the problem only applies when CroppableImage4 is used in a 'nested' RepeaterMatrix. See attached screenshots for the error message and to give an idea of my setup.

Hi @teppo, first of all, thank you for this wonderful module! Do you see a possibility that ProFields Table will be supported in the future? I am certainly willing to sponsor (part of) the development costs for this!

@Robin S wow, this is really great! Thanks for spending your weekend hours on this update ?

Hi @Robin S, Thanks a lot for this module! Exactly what I was looking for ? Version 0.0.8. of RepeaterMatrix introduced the 'insert before' and 'insert after' buttons. If I limit the use of matrix types to 1 item per type, it's still possible to add a new item via 'insert before' and 'insert after' (see screenshot below). Is it possible to prevent this?

@skeltern I think this solution of @horst solves your issue.

@horst Your adjustment of the webp() function fixes the issue! Thanks for diving into this!

Hi @horst, thanks for your code example, but unfortunately it still doesn't work as expected. See the attached screenshots below, both of the overview of generated variations in the backend. I made an 'extreme' cropping to show the difference with the original image. 1) The image variations before loading the template with your example code in frontend. I marked the cropped variation with a red border: 2) The image variations after loading the template with your example code in frontend. I marked the frontend-generated 900 pixel width variants with a red border. The JPG version is OK, but the WEBP version is not ? Groeten terug uit Maastricht! ??

@horst I use the code below in my template to generate different sizes of a cropped image: <source type="image/webp" srcset="<?= $page->image->getCrop("default")->width(450)->webp->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->webp->url; ?> 2x"> <source type="image/jpeg" srcset="<?= $page->image->getCrop("default")->width(450)->url; ?> 1x, <?= $page->image->getCrop("default")->width(900)->url; ?> 2x"> After I re-crop the image in the backend the variations of the jpeg version are regenerated, but the variations of the webp version are not regenerated/showed in the frontend. Is there a way to overwrite the webp variants after the image is re-cropped? Deleting all variations in the backend before re-cropping the image doesn't solve this issue. See also this post (not related to CroppableImage)

Thanks Horst, that works! I need different sizes of the same crop to use in srcset for responsive images. I referred to this in your opening post:

The readme of the Github repo says: I use this to generate a smaller version of a crop (for mobile), but the image doesn't get resized: $page->image_main->getCrop("panorama", "width=640")->webp->url; Is resizing still not working as mentioned in the first post of this topic? Will it work in a future release of CAI4?

This module is exactly what i'm looking for! It works perfectly within a regular Textarea CKEditor field. Is it possible to get this module also working in a Textarea Rich Text (CKEditor) field within a ProFields: Table field?

Line 785 of ProcessJumplinks.module results in unexpected behaviour: $this->session->redirect($convertedWildcards, !($starts || $ends)); As soon as the start time of a jumplink is set (after the first hit), the redirect wil be 302 (temporary) even if the end date is empty/not set. I think only redirects with an end date should be temporary (302), otherwise permanent (301).

@Ryan: I did a fresh install using the dev branche of PW. I tested this locally using MAMP with PHP 5.3.29 / MySQL 5.5.38. I tested the following scenarios: Installed PW using the multi language profile without changing the admin name. Added a new language: no errors Installed PW using the multi language profile, changed the admin name from processwire to admin. Added a new language: no errors. Installed PW using the multi language profile, changed the admin name from processwire to sitemanager. Added a new language: getting the errors as posted earlier. Conclusion: I think this errors have something to do with the fact that the admin name is starting with site (as you already suggested here https://github.com/ryancramerdesign/ProcessWire/issues/764). It also has an effect on LanguageSupportPageNames.

@Adrian: manually adding the columns 'name1017' and 'status1017' to the 'pages' table solves the error, but I still can't see other page names than the default language (as mentioned here).

Same problem here, but I get the following error after adding an additional language: Error: Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'pages.name1017' in 'where clause' (in /var/www/vhosts/xxx/xxx/wire/core/DatabaseQuery.php line 91) My server is running PHP 5.3.10 / MySQL 5.5.38. I installed PW 2.5.3 using the 'Multi Language' profile. Additionally - I'm not sure if it's related to this issue - I can only see or edit the page name for the default language (as reported here with screenshots).

Hi, I installed PW 2.5.3 using the 'Multi Language' profile. The site works fine, but I can only see (or edit) the page name of the default language (English in this case). The page names for the other 2 languages are invisible or missing. All the necessary modules are installed. See sceenshots below. I didn't change anything in the setup or template files. Is this a (known) bug? My server is running PHP 5.3.10 / MySQL 5.5.38.

@Netcarver: I tried all possible solutions, but putting that extra line in .htaccess 'solves' the problem (at least it hides the error message). Within a week or 2 we are going to move the hosting account where the Xcache problem occurs (used for development) to a VPS. For the time being adding that line to .htaccess is fine. Thanks for your help!

This is the answer of my provider: Can someone answer the question above?

OK, thanks for your replies! I have asked my provider to solve this problem for me.

After installing PW 2.4 I get the following error in admin and error.txt: Error: XCache: Cannot init (line 0 of Unknown) The server (shared hosting) is running PHP 5.3.10. I have already changed the permission settings of /site/assets/cache to 777 (was 755), but that didn't solve the problem.