Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,465 profile views

nurkka's Achievements

Jr. Member

Jr. Member (3/6)



  1. Hi everybody, in another post some weeks ago @ryan mentioned that the language-alternate fields were deprecated and that he doesn't expect many will ever use them. As I am using language-alternate fields for image-fields and url-fields, I wonder if there is any other, non-deprecated solution? Thanks and best regards
  2. You could use the redirects plugin: https://processwire.com/modules/process-redirects/ It also allows to import the redirects as comma separated list, where each line contains one redirect.
  3. Hi everybody, is it possible to hide a page in the default language of a multilanguage website? The page’s settings tab doesn't seem to allow it, because there is no checkbox next to the default language’s url and it can’t be left empty. For the time being I implemented a checkbox "hide in default language", and if checked, the page outputs a wire404(); But is there any native way to do it? Thanks and best regards
  4. Hi everybody, some time ago I implemented a blog in ProcessWire with the comments function. The comments have avatar images which were displayed based on the commentators email address. To manage the avatar images and some other data, I added custom fields to the user template. This used to work perfectly, but today I noticed that the avatar images were missing. $user = users()->find("email=mail@example.com"); echo $user->first()->get('name'); // works perfectly echo $user->first()->get('user_display_image'); // doesn't work anymore UPDATE: I just found out, how to get the field value again. One has to check the option »Make field value accessible from API even if not viewable«. Screenshot: I assume, the functionality must have been changed sometime between 2019 and 2021. With the above setting it works again.
  5. Thanks BitPoet, the following code worked: function custom_debug_if () { return true; // simply for test reasons } $config->debugIf = 'ProcessWire\\custom_debug_if'; Using if(wireIsCallable($debugIf)) instead of if(is_callable($debugIf)) in ProcessWire.php made no difference. Thanks again and best regards!
  6. Hi everybody, while testing $config->debugIf, I noticed, that it wouldn't work with custom functions. Example /site/config.php: function custom_debug_if () { return true; // simply for test reasons } $config->debugIf = 'custom_debug_if'; This doesn't work because the if(is_callable($debugIf)) in ProcessWire.php returns false. The debugIf-documentation says: * 2) Your own callable function name (i.e. "debug_mode") in /site/config.php that returns * true or false for debug mode; How is it possible to use this feature? Thanks and best regards!
  7. Hi! The feature Automatic Page Name Format of the PageTable field has stopped working after a ProcessWire upgrade. I was using the following configuration string, which worked perfectly before: Y-m-d_H-i-s_\d\o\w\n\l\o\a\d The config string was interpreted as PHP date format, where you can escape characters to mark them as non-date-formatting characters. The PHP docs state the following: PageTable generated the page names like the following example: 2017-03-13_12-17-24_download But after a ProcessWire upgrade (I assume it must have been version 3.0.123) the page names are now generated as follows: y-m-d-h-i-s-d-o-w-n-l-o-a-d The config field settings description now states: So, I tried several other configurations, like: Y-m-d:H-i-s \d\o\w\n\l\o\a\d Which renders the date part correctly, but the string "download" is unfortunately also processed as a date format. I assume the configuration setting is somehow filtered by ProcessWire before it is passed to the php date function. This was not the case in older versions of ProcessWire. Sorry, I haven't the time to test with which version the behaviour changed. The feature stopped working somewhere in january 2019, so I assume it must have been the upgrade to ProcessWire 3.0.123. Has anyone similar issues with the Automatic Page Name Format in PageTable?
  8. Hi kongondo, I just wanted to report a little UI inconsistency: I was editing a CKEditor-textarea and inserted a link by using "Select Media from Media Manager". In the Media Manager modal window, I used the table view, in order to see the filenames. Now, selecting any of the thumbnails didn't give any visual feedback. The red frame indicator only appears in the grid view, but not in the table view. I did a clean install of Processwire and Media Manager, but the issue persisted. Update: I think I found the issue. Here is a fix for insertMediaLINK($s) in MediaManager.js: Before: $inputs.each(function () { // skip current input if ($(this).attr('id') == 'media-' + $dataValue) return; // invert checked status $(this).prop("checked", inverseState).change(); }); After: $inputs.each(function () { // skip current input var $dv = $(this).attr('id').substr(6).replace('-tabular', ''); if ($dv == $dataValue) return; // invert checked status $(this).prop("checked", inverseState).change(); }); The line was taken from removeMediaThumbsView($a) in InputfieldMediaManager.js.
  9. Problem solved – Ryan pushed a fix: https://github.com/processwire/processwire/commit/f5f83e814880c862b5bfd0ee935b8c9e7699bd74
  10. Thank you both! In the meantime I have found the corresponding line of code in the FieldtypeOptions module. Before saving the options, ProcessWire checks, if the current user is a superuser. So any non superusers cannot save option values (in the current / newest ProcessWire version 3.0.148). So I modified the corresponding if statement, in order to allow users with "field-admin" permission. Thanks again for your suggestions. I took the opportunity to take a closer look at Tracy Debugger and I will definitely keep the page field select module in mind.
  11. Hi, I'm maintaining a multilanguage website where two different design companies have access to the processwire backend. For one of the teams I created a custom user role called "designadmin", where I activated the permissions "field-admin" and "template-admin", so the designers are able to edit fields and templates. This worked very well, but now, they wanted to create a select options field, and then change the values of the options. When clicking "Save" in the ProcessWire backend, the changed values won't save and are immediately restored to their previous values. Screenshot: When logging in as superuser, these values can be changed and saved successfully. How can I give the design team the permission to change and save options values, without giving them superuser access? Thank you for your help!
  12. Hi @kongondo, thank you for your feedback. I am glad that you like my suggestions. And I would be happy to help you with testing!
  13. Hi kongondo! Recently, I used Media Manager in a client project. In this real world use case, the media library very quickly grew to an extent, where it was too confusing for the client. Of course I know how to apply filters, but for my client, configuring and applying filters was to complicated - even with the relatively new feature of pre-defined filters. So I thought I would ask you, if you could image to implement some additional filter-features, that would make it easier for clients: - It would be great, if it was possible to set a default filter for every MediaManager-Field. I have a lot of different "image-types", like icons, fotos, sketches and so on. With such a feature, it would be possible to limit the displayed images to just the "type" of image, that suits the context of the current MediaManager-field. Like when applying some product icons, you don't want to choose from the whole library with all the staff portraits. - Another great feature would be, if pre-defined filters could be applied with one click in the overview. I tried to sketch this in a fake screenshot: In this way, an admin could pre-define all needed filters, and the user/client could just apply them with one click - without worrying about or even understanding the actual filter definition. I guess those features don't exist already, but if so, I would be very happy, if you could point me to any existing solution. Otherwise it would be great to have those - or similar - features in a future version. Thanks again for the great module!
  14. Thanks for the detailed explanation of the new module version! Some time ago, I wrote a simple module for a client website that converted every href-value on page render. It stripped out a certain folder name, i.e. it converted »/container-1/page-1/« to »/page-1/«. That worked fine, but for my client it caused a really big usability issue in the backend, because they saw the original links in the WYSIWYG-Editor, and not the resulting links. As much as I understand, the new Multisite version will also leave the original links in the WYSIWYG-Editors, like »/www.example.com/about/« instead of »/about/«. Do you see any way to just display the »right« links to backend users, while not really altering them?
  15. Thanks for your reply, Soma. And also thank you for developing the fantastic Multisite module! To further test this, I set up a clean installation of ProcessWire 3.0.30, activated link abstraction and put some internal links into the body-fields. Then I dragged and dropped the page branches around the page tree. PW’s link abstraction always correctly modified the links in the body-field. Then I installed Multisite, and link abstraction unfortunately stopped working. When trying to save a page with any link in the body-field, PW displayed an error message like »Session: Unable to resolve link on page "pagename" in field "body": /link-to-another-page/«. PW’s link abstraction internally saves page-ids as link-attributes in the database, like this: <p>This is an <a data-pwid=1023 href="/child-page-1/grandchild-page-2/">internal link</a>.</p> When Multisite converts links like »/www.example.com/child-page-1/« to »/child-page-1/«, PW isn't able to recognize them anymore and therefore cannot save the corresponding page-ids to the database. So I assume, link abstraction won't work together with Multisite. A powerful feature of Multisite is, that editor users see the »real« links in the backend. Modifying the links on page render, as you suggested in a previous post, would confuse those users, because they would see links like »/www.example.com/child-page-1/« in the WYSIWYG-Editors. The only solution I can think of right now, would be to convert all modified links back to the original links on page save, let link abstraction do it’s work, and modify them again, when displayed in the backend or frontend. Do you think that would be possible?
  • Create New...