MilenKo

Hey @justb3a I can tell you've done an interesting module and even though I did not test it yet, I could see it already fitting to my needs. Since I see that the module development is discontinued, does anyone know of existing issues for some basic user subscription? I am building a profile for a tech support company and the client would like to collect client's name, email and eventually phone number in order to broadcast occasionally some promotions, discounts, new services etc. Since the client is located in North America, it won't be that much of a problem if GDPR is not fully operational (as far as I understood from the earlier questions), however I would see how to make it work so that any European client does not fall through and complain of non-EU-GDPR-compliant website ? So any known issues I should be aware before I implement the module?

Hello @ukyo I've been using your module for a project that I gradually develop and it was working great up until today when I upgraded to version 2.0 through the module upgrade checker and upgrader. After the upgrade while trying to return to the admin page, I got this error: Compile Error: Cannot declare class MarkupFontIconPicker, because the name is already in use (line 10 of ..\site\assets\cache\FileCompiler\site\modules\MarkupFontIconPicker\MarkupFontIconPicker.module) This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Error has been logged. As soon as I disable the module, the admin is back to normal again. I've tried to re-install the module manually and it seems to be working but I did not test it yet extensively so will do and report back.

Thanks @tpr for the static variable and "cache" approaches. I believe that after reading the @teppo detailed instructions about the different approaches, I would start using the <picture></picture> approach for new sites, however would give another try to the automatic webp conversions through .htaccess and code calls in the instructions. I have no doubt that in the next one or two versions, Apple would be having already the WEBP implemented which would simplify the things, however until then, it is good to know the best practices and most important, which way works best for us and users. Since my profile is fully completed but it is not yet live since I am adding the content now, it won't hurt me to try all the kindly suggested approaches and see for myself which one to keep. Btw, HAVE AN AMAZING AND PRODUCTIVE 2020 YEAR!

Hello to all mighty people and Happy New decade start. Wish you all the greatest goodness, joy and happiness. Well, and a lot of great code as well ? I've implemented WEBP images to optimize my soon to be released profile and by a lucky coincidence I discovered on my Mac that no images are showing when using the Safari. I thought that Apple would have embraced the idea by now when several other browsers have already done that but it seemed like I was wrong. I tested the .htaccess approach, however I could not make it working under Safari, so I decided to add a little function to my _functions.php: //WEBP Image Support function webp_support($imgURL) { // Check if the browser headers contain image/webp support if(strpos($_SERVER['HTTP_ACCEPT'], 'image/webp')) { // If yes, use the webp image url return $imgURL->webp; } else { //Else, show the original image url return $imgURL; } } After that, in every image call I do the following: <?php $img = $page->images->first // Call for the image location $image = webp_support($img->size(100,100)) // Used to size an image and convert it to WEBP //Image call in the markup echo "<img src='{$image->url}' alt='{$image->description}' >"; That seems to be working fine and show the WEBP format on Chrome, Opera and Firefox under MacOS/Windows/Linux but show the original image version under Safari. I did not test with the Windows version of Safari since it is a long time not updated version and it won't make much sense to support the newer format anyway. My question for you is if there is a simpler approach than my current to show WEBP images to the supported browsers and fallback to original If not?

Hey guys, I've been using the MenuBuilder for quite a few projects (thanks @kongondo for the great module and support!), however this time it is my first when I need to use a menu in the sidebar if some pages are added to it. It all works as soon as I add a few items to the menu, however there is one little issue I am having - not knowing how to show the block title ONLY if the menu contains some items added. I've been looking through the module functions etc. to figure it out, however for some reason I am always getting the items count as 1 even though I've added 9. <?php //Building the array of options. The ones that are not used can be removed //They are left here for the learning process only. $options = array( 'wrapper_list_type' => 'ul',// ul, ol, nav, div, etc. 'list_type' => 'li',// li, a, span, etc. 'menu_css_id' => '',// a CSS ID for the menu 'menu_css_class' => 'category-list',// a CSS Class for the menu 'current_class' => 'active', 'default_title' => 0,// 0=show saved titles;1=show actual/current titles 'include_children' => 4,// show 'natural' MB non-native descendant items as part of navigation 'm_max_level' => 1,// how deep to fetch 'include_children' 'current_class_level' => 1,// how high up the ancestral tree to apply 'current_class' ); // Render the menu by title $cat_menu = $menu->render(1108, $options); echo "This menu has: " . count($cat_menu); echo $cat_menu; ?> The big question here is, how can I add a check if my menu with a specific ID/title would contain some items or is just empty in order to show or not the block title etc.?

Hello @SeriousUser depending on the website needs, it seems like a reasonable structure. Having said that I would allow myself to suggest those HTML containing fields to be replaced with one/a combination of other fields which would give you more flexibility during a theme building and most important - eliminates issues with the markup. To my experience, the markup is always better to be added to the templates which would then call for the field content. BTW, I like the diagram visualization. What have you used to construct it?

Hey,@Robin S thank you very much for the quick and useful info. I was playing with some ifs to have a name in the sorting and then convert it to the actual sorting form, however the 'case' switch seems much cleaner and simpler than my code. I will run a test with it and see how it would come out, but I am sure it would be perfect.

Hey @Robin S I've been playing this weekend with HannaCode + Dialogue and was wondering, would you know a way to provide a label for the attribute options? Presently I have the following list of attributes: Post_sorting_order Post_sorting_order__options=date|-date|title|-title|phits|-phits|recipe_comments.count|-recipe_comments.count Post_sorting_order__description=Negative sign means reverse order and I am trying to presend the options in a more human readable form (eg. "-date" to become "Date - asscending") etc. It is not much to leave it as it is, however presently to sort by comments count I am using the fieldname.count instead of something like: Comments count (ascending/descending). I've tried to modify the module to have a value of the options like: Post_sorting_order__options=date*Date(Ascending)|-date*Date(Descending) etc. but so far I was not able to modify the code to make it work..

Nevermind, looking at the code, I found the answer - every time I called the hanna code, the tabs were having identical names, so this was causing the issue. To fix it I've added a simple random string to the tab names and it is all working fine now. $permitted_chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; $rand = substr(str_shuffle($permitted_chars), 0, 10); $tab_name = "Tab" . $count . "-" . $rand; This gives me an alphanumeric string of 10 chars length which aims to avoid a chance of duplicating again the tab names. I know it might be an overkil, but just don't want to take the risk of generating random number and have them matching ? As of now, the tab ID is something like: #Tab1-wrf7te0Y2x

Hello gents. I've been experimenting a lot lately with Hanna Code and Hanna dialogue which lead me to a full "News Block" code that can be inserted easily using CKEditor. My idea was to build a few similar news blocks and allow the admin to select the categories (represented by pages) for every block tabs etc. Attached is a screen cast of what I have so far and it is working perfectly fine and as expected. As usual, there is one HOWEVER ? After some experimenting and adding few news pages (in my case as it is obvious some recipes), I was glad to see it all happening. The problem came, when I tried to insert the same Hanna Code block with the idea to show some different categories. What has happened is that the second block tabs came empty, but clicking on them started changing the navigation of the first one. From my humble experience with PHP I would guess that since Hanna code is using the same attributes, it affects the appearance of any other than the first block. So has any one ever came to a similar use and have found a solution that would allow to have multiple blocks inserted without an overlapping of the code of every one? I am thinking about experimenting with inserting a random number after the block name which would be used for the tab number and tab content, however am not sure if there is a simpler or more elegant solution that I am missing yet... Maybe it is important to mention that I am trying to accomplish a page builder using Hanna Code and Dialogue to allow selection of pages, add some limitations etc.

Hey gents, for your information, I just upgraded my profile to 3.0.143 and it is all back to normal (at least with the error 500 I had). Thanks to all of you and especially Ryan for fixing the issue.

@adrian, you were perfectly right, using the commit before the latest upgrade did fix the issue. Will post a report to Ryan to fix it.

Will try to use the earlier commit you've pointed me to and submit an issue report for Ryan.

Hey @adrian thank you very much. Would you know where can I find 3.0.141 core eventually to see if that would be the latest version to upgrade to? I will change the selector code in the home.php to see if that would fix it, but for sure it is a needed selection of the pages to avoid some drafts etc. to be listed ? P.S. I've tried to remove the status selector, but am still getting the same error. Any page that I browse even if I create a template with simple phpinfo() in it and assign it to a page shows the error 500. One thing I am thinking I could do is to try to export the profile and import it on a fresh install to see if that would help...

Hello fellas. I've been working on a profile that has been almost completted but I had to focus on some other tasks which caused me to stuck with PW dev version 3.0.137. This morning I went to upgrade all the old module versions as well as the core to 3.0.142 and I got an error 500 while trying to browse the frontent. The admin works perfectly fine, but the frontend fails to load. To troubleshoot the issue, I've taken these steps so far: 1. compared the old index.php and .htaccess files with the new one, but got them perfectly matching so the issue is not coming from there. 2. Tried to switch back to the old dev version by renaming the wire folder to .wire-3.0.142 and renaming the backed up folder to wire. As a result, the website came back as it should. 3. As far as I've used some of the Profields Module components, went and manually upgraded all those to make sure it is not part of the upgrade issue. With the old 3.0.137 core it all works fine as well. 4. Cleared the cache by manually deletting the content of /site/cache folder - still got the same error. 5. Did a module refresh to make sure that all the upgrades has been properly indexed - the issue got not fixed. 6. Enabled the debugging and checked the Tracy logs to find out the following error (file attached with the exception details from tracy): [2019-10-25 12-39-03] ProcessWire\PageFinderSyntaxException: Operator '&' is not supported for 'status'. in C:\OSPanel\domains\compurox.pw\wire\core\PageFinder.php:2211 @ http://compurox.pw/ @@ exception--2019-10-25--12-31--a55174700b.html 7. Tried to grab the PageFinder.php from the old core to check if the issue is within some changes with the latest core/cores. The error still showed which leads me to the conclusion that it is not related to PageFinder module even though it is mentioned. So does anyone has other suggestions or something that I have missed besides starting to disable modules all at once or one by one to figure out which one might be causing the problem? P.S. One other Idea I have, but am struggling to find an archive of the old dev cores from 3.0.138 to 142 to see if the profile would work with some of them. At least this could have pointed me to some core changes in that specific version which I should be addressing. Unfortunately I was not able to find any archive of the afore mentioned versions and as I've been away from PW community, I did not keep a copy of them as well as I usually do... exception--2019-10-25--12-40--edade40c59.html

Great share, @Edison I will definitely test this in my next profile. How would I add the honeypot if I am using custom forms and modifying the module placing it in /site/modules/FieldTypeComments ?

Hello there. I know this is a quite old topic, however I was facing the same issue and fount an easy way to handle the browser errors: in my form I had the following: $first_name_error = translate('Missing first name'); I've added my translation string to _strings.php: _x('Missing first name', 'General'); And then in my HTML markup I had the following code showing the translation: <div class="form-group col-lg-6 col-md-12 col-sm-12"> <input type="text" name="first_name" placeholder="{$first_name}" required="" oninvalid="this.setCustomValidity('{$first_name_error}')" oninput="this.setCustomValidity('')"> </div> Btw, the same approach was taken for the placeholder as well so $first_name was translated as well in my _strings.php For sure, @soma suggested long time ago, one can disable all the error messages, however if you would prefer to have the tooltip active, this is a nice and easy way to achieve it. It took me a few hours to find the right approach, so hopefully the next one won't have to spend that much time. So far it worked with Opera, IE, Edge, Chrome. I did not test with Safari, but doubt it won't work as well ?

I had a similar issue, but in my scenario (with no module modifications) the line causing it was 58 if(count($values)){ I can confirm that changing the line to @Macrura correction eliminated the error in my logs.

@Kai2000 Hello Kai and welcome to the PW Forum. I remember having a battle with my comments list and comments form the first time I needed to implement those and I was able to manage it with ratings, custom styling and inline replies. Here is the topic for you in case you haven't found it. With your own custom markup for the comments list and/or comment form I would suggest as the easiest way to copy the FieldType Comments module from /wire/modules to /site/modules and apply all the custom styling to this version. As I see, @Edison beat me on this and he also helped me to show comments based on the user/site language. Just follow the steps to select your new module copy from the admin (listed in one of the links of Edison and you would have your markup in no time. It seemed a bit confusing for me at the beginning, but you will get used to it and be able to manage any complexity of your comments. Should you have some difficulties understanding the code or adding a copy of the module, feel free to reach back to me and I will be glad to help ?

Hey everyone, I got some great news about the proper date showing of ProcessWire in Russian. There are different approaches depending on the format to present the date. Here are the two best fitting the purpose: Approach 1: Approach 2: Even though I personally liked the second approach better since it just use the proper month number that would return the same value in any language, for the Russian proper date appearance I took much simpler solution where all I had to do was to swap the day and the month since plenty of websites were using it already. In a scenario where the month is first and then the date, there is ABSOLUTELY NO NEED to conjugate the month name and the date is appearing still gramatically and esthetically correct: Июль 31, 2019 To allow different date formatting per language (the default way of setting the locales did not work on my server) I've modified a bit the code I've added earlier to my header.inc: And was able to finally have the date properly showing in all selected languages by calling it inside the HTML markup: <?php // STRFTIME FUNCTION DATE FORMAT: // https://www.php.net/manual/en/function.strftime.php // $date_format - defined in /sites/includes/head.php for every language // $l->published/created shows the date the page was published/created // $locale - defined in head.php as well setting the proper locale for every language echo strf_time("{$date_format}", $l->published, $locale); ?> Please note that this approach would work for date() and strftime and there is actually no need of adding the extra DateTime field nor is necessary the code at /site/ready.php , however I've decided to leave it as it is for the learning curve and if a need be, to have a better option to manipulate the date. As far as the head.inc is included in every template of the profile but I would only need it to a few that would show the creation/publishing date, I might add a check for the page ID and include the header to only those templates that need it, however these things are some simple steps so I won't go any deeper there. Hope it helps to anyone needing to present a date in Russian or any other language that would require some names that differ from the standart PHP date/time function result. Case closed now! P.S. Forgot to mention that the strf_time is a function that I've used to my _func.php to convert the month name to utf-8 which I use by default in my profile: /** * Convert date/time stamp from different characters to utf-8 */ function strf_time($format, $timestamp, $locale) { $date_str = strftime($format, $timestamp); if (strpos($locale, '1251') !== false) { return iconv('cp1251', 'utf-8', $date_str); } else { return $date_str; } }

OK, folks. I got a prototype of fully working month names Russian ranslation that works perfectly by creating an array with the proper month names and then showing the array result for the number of the present month. Simple and elegant, but I decided to go further now and create an unified version of translation function which would check the user selected language, set the proper locale and echo the month name either from the array for the Russian translation or directly. I am surprised that I did not see any solutions for that here yet ? Having a universal function would allow me to use it over and over again for any websites that would have the Russian in the languages list simply by inserting it to my _functions.php ?

After giving it some thought, It really messes up the things when one see the month in Russian language without the proper termination so I will have to find a way to translate the month name to the proper one in order to make it gramatically correct. It would be great if some of the russian techies could share their experience ?

Alright, I got it all sorted out and is working on my Unix & Windows hosts both locally and online. In case someone stumbles upon the same issue, here is what worked for me to have cyrillic languages and 1252 ones working fine: 1. Add the following code to _functions.php or other file that you use for your functions: /** * Convert date/time stamp from different characters to utf-8 */ function strf_time($format, $timestamp, $locale) { $date_str = strftime($format, $timestamp); if (strpos($locale, '1251') !== false) { return iconv('cp1251', 'utf-8', $date_str); } else { return $date_str; } } 2. Add this code to your head.inc (note that head.inc is included in all my templates) <?php // Check the user language name // Assign the language locale to $locale // Windows locale source: https://docs.moodle.org/dev/Table_of_locales switch($user->language->name) { // Default language is English case 'default': $locale = setlocale (LC_ALL, 'en_US.UTF-8', '-parent en_utf8 used-'); break; // Bulgarian language locale case 'bulgarian': $locale = setlocale (LC_ALL, 'bg_BG.utf8', 'Bulgarian_Bulgaria.1251'); break; // Russian language locale case 'russian': $locale = setlocale (LC_ALL, 'ru_RU.utf8', 'Russian_Russia.1251'); break; // French language locale case 'french': $locale = setlocale (LC_TIME, 'fr_CA.UTF-8', 'French_Canada.1252'); break; } ?> 3. Add a field to your templates that you would like the date to appear (set the field as DateTime) and no date/time format. In my scenario I called it 'date_created' 4. Assign the field to all templates where the custom date would be needed (in my scenario I assigned it to news-inner.php as I am grabbing some news pages to show on the main page). Note that I assigned the date field to the inner page of every news, but not to the parent or Home. 5. Add this code to your ready.php (if you don't have one create it at ../site/ready.php (where your config.php resign ? ). Inside of this file add the following hook (Thanks to @Edison for the code!) $wire->addHookBefore('Pages::saveReady', function($event) { $page = $event->arguments(0); if($page->hasField('date_created')) { $page->date_created = time(); } $event->arguments(0, $page); }); Please note that you need to replace 'date_created' with your custom date field (unless you follow steps 1x1). 6. In your markup where the MULTILANGUAGE ENABLED DATE is needed, use the following call: <?php echo strf_time("%d %B %Y", $l->date_created, $locale);?> Note: Feel free to change the date appearance format using PHP strftime function format Well, that is it, it works fine with me and showing all the languages properly now. If you would like to go further, some of the months that are having more than 3-4 letters in the abbreviation could have a dot after the name, however for this you should create an array with the shorter months and show the dot if it is not one of those or do some magic counting the letters of the month and if the result is higher than 3-4 to show it, but I did not go that way as it is working as the original markup ? Another issue I noticed is the Declination of the names of the months when displaying the date in Russian. I found a function that could heal that, however I hightly doubt I would need it. In case someone wants to play with it and adapt it for PW, here it is . Note, that the page is in Russian so you might need a translator or just read the code.

After a decent night sleep and my morning coffee I had some progress towards resolving my issue. While searching the Internet I found some useful pieces of code that I was able to put together to test my server setlocale. As it appears, it is all running properly with only one issue where for the cyrillic letters to appear properly, I needed to use iconv to convert them to UTF-8: The result of the script gave me this: mardi, juillet 23 вторник, Июль 23 вторник, юли 23 Tuesday, July 23 So now I will look for a way to use the function and apply it to all locales which should not affect the French/English date but will make the proper appearance of the cyrillic chars. Since I am on a Windows host, I had to use the Windows locales instead of the unix format, however running the code on my unix host returned the proper values as well so it seems like this solution is multiplatform one ?

@Edison Hey man, adding the brackets and semicolon did the trick. Now the date gets populated during the saving and I don't have to add the earlier code to the footer of the templates. However, this did not help much to have the month translated and it still shows the month on English for any of the languages. Will try to move the profile to my real host which uses linux so that I can be sure that setlocale is setup and working properly. Maybe there is no issue but just the local server is messing things up. Moving the site to my live host did not solve the issue. There has to be something else that is messing up the things. P.S. Double checked that the DateTime field has the date format for every language as well as that the setlocale is properly set for every language as: bg_BG.utf-8, ru_RU.UTF-8, fr_FR.utf-8 and C (last one for English) Strange enough, only the date translation is not working but all other translated strings do work.