Leaderboard

Hi, Not sure, but it could be relative to notices that you have on the top of your page

Edit September 2022 See this thread: --- I would have taken another way. As each photo are Page, he could create a module which work with a custom MySQL table where he update the like of a page with some informations aside, like the userID (the user who like the page), the pageID (the page being liked) , a likeStatus (like or unliked) and a timestamp. I made a small module to show the idea : then in the frontend, you can render a 'like' button on choosen templates, and finaly get the total number of likes of a page and the most liked page, see: <?php namespace ProcessWire; $likesmod = $modules->get('LikeSystem'); // render a 'like' button $content = $likesmod->render(); // total like of the page $content .= "Number of likes for this page: " . $likesmod->getTotal($page->id); // most liked page $limit = 1 $mostliked = $likesmod->getMostLikedPage($limit); $content .= "<br>Most liked page: " . $pages->get($mostliked[0]['pageId'])->title . "(" . $mostliked[0]['pageId'] . ") " . " (N likes: ". $mostliked[0]['likesCount'] . ")";

hi @MilenKo you should read this post made by Ryan, and adapt it, it contain nearly all answers. Anyway your code should work if the comments/template are correct.

I have just sent out a general update via email that resolves the problems mentioned. Thanks everyone

Not sure how to help you, but you might be better off creating a TemplateEngineMustache module that extends the TemplateEngineFactory module: There is already sub modules created that you could look at for other template engines like Implementation of Twig: https://github.com/wanze/TemplateEngineTwig Implementation of Smarty: https://github.com/wanze/TemplateEngineSmarty Implementation of Jade (by dreerr, thanks!): https://github.com/dreerr/TemplateEngineJade https://github.com/dreerr/TemplateEnginePug I personally use TemplateEngineFactory with TemplateEngineTwig. Hope that helps

Finally got a chance to try it and this module is great, and will solve innumerable content management conundrums.. Here's my first use, on a quotes rotator section: Field Config: var colheaders = ['Author', 'Publication', 'Quote']; hot.updateSettings({ colHeaders: colheaders, minCols: colheaders.length, maxCols: colheaders.length, rowHeaders: false, minRows: 1, minSpareRows: 1, maxRows: 5, width: 900, contextMenu: true, autoWrapRow: true, autoWrapCol: true, colWidths: [200,200,500], }); edit screen: output:

Hello @zaib I'm not quite sure what your issue with repeaters is. Can you please be more specific? Here are the docs if that helps: http://processwire.com/api/fieldtypes/repeaters/

hi sirhc, you could create a page reference field on your photo-template and when a user clicks on like you can add this user to the pagefield. if you have lots of users (likes) that could cause some problems on the page edit screen i guess, but if you set the field to hidden it should work. like count is as easy as counting referenced pages (users). show all liked photos would be an easy selector like "template=photo,likes=youruserid" most likes this week... hmmm... that's not possible with the setup above. then maybe it's better to create 2 new templates: 1) likes (just the parent for all likes) 2) like (pagefield referencing the photo, user that liked) then you can create a new "like" page whenever a user likes a photo and then you can also count all likes of that week: $pages->count("template=like,photo=yourphotoid,created>xxx,created<yyy"); and counting all likes for one photo would be even easier: $pages->count("template=like,photo=yourphotoid");

Hello for all, also had problem with this warning, and read this and this and find why that's added in PW. My problem was that I don't have CPanel permissions (only to login to website admin/backend). Website is multilanguage (3 languages, Montenegro, English and Russian) and try few options for all languages, but always after logout/login get warning message. There is little confused note: "Default is 'C'. Specify '0' to skip the setlocale() call (and carry on system default)." I try with "0" to all, but that don't solve problem. Also not sure about "C", maybe need to change note to this: "Specify 'C.UTF-8', or '0' to skip the setlocale() call (and carry on system default)." Because webiste is hosted on one of the popular european hosting providers, I assumed that there is probably set_locale supported/installed for languages like English, and Russian, but not sure about Montenegro, and try this: Montenegro: C.UTF-8 English: en_US.UTF-8 Russian: ru_RU.UTF-8 And that fix problem. Regards.

To me the main distinction is between the bulk importing of data (for which modules like ImportPagesCSV are great) and the occasional addition or editing of data which you do via Page Edit. But in any case it's not difficult to do what you are asking about. Add a textarea field in your template named "country_import" or something. Then use a hook to Pages::saveReady() to process the field contents and add them to the "countries" Page Reference field. In /site/ready.php: $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); // Only for the appropriate template if($page->template == 'YOUR-TEMPLATE') { // If the import field is not empty if($page->country_import) { // Get the individual country titles in an array $country_titles = explode(', ', $page->textarea_1); // Find the country pages with those titles $country_pages = $this->pages->find([ 'template' => 'country', 'title' => $country_titles, ]); // Add the country pages to the countries field $page->countries->add($country_pages); // Empty the import field $page->country_import = ''; } } }); You could use the same principle for other fields if you think there's a major benefit to it.

In this week's post we'll take a closer look at the importing side of our upcoming export/import tool. Plus we'll look at something new in 3.0.70 called markup region hints, which are worthwhile if you are using markup regions in PW3. https://processwire.com/blog/posts/pw-3.0.70/

The JquerySelectize module, that all of the other Selectize family modules require, has been updated (to version 1.0.1) as follows: 1) Checks to see if the core version is 3.0.67 or higher (version at which selectize was added to core), and if so, will load the core files, and not this module's files. Using the ProcessWire core versions of selectize.js improves the user experience, because of the adjustments that Ryan made to the plugin, which relates to hitting enter key after typing a tag (which would by default submit the form). 2) In addition to loading the CSS & JS from the core, when working in versions 3.0.67 or higher, the module still provides a skin selector. While most users will probably stick to the core non-skinned version of Selectize, the module provides this option to choose a different skin. There are some scenarios where choosing the default or bootstrap skins for selectize can be preferable, as they may be higher contrast or more pronounced with color usage, and can help in some ways with accessibility for users with any type of vision impairment. Currently the update/behavior only applies to Selectize modules family that require and use the JquerySelectize module, so if you are using core image tags and have this module installed, it won't change the skin; However there is a plan to try and hook into the image field rendering and enable this module to add the custom selected skin to the css files.

You can find more information there: https://processwire.com/docs/security/file-permissions/

You could try to copy the root dir containing the site and do a chmod -R 777 on it (just for testing purpose!) - result ?

Hi @adrianmak You can achieve this by using hooks and my ReCaptcha module. First install the MarkupGoogleReCaptcha module then in file ready.php, write the following code : /* * replace the LAST occurence of $search by $replace in $subject */ function str_lreplace($search, $replace, $subject) { return preg_replace('~(.*)' . preg_quote($search, '~') . '~', '$1' . $replace, $subject, 1); } /* * replace the FIRST occurence of $search by $replace in $subject */ function str_freplace($search, $replace, $subject) { $from = '/'.preg_quote($search, '/').'/'; return preg_replace($from, $replace, $subject, 1); } $captchamod = wire('modules')->get("MarkupGoogleRecaptcha"); wire()->addHookProperty('Page::captcha', function($event) use ($captchamod) { $event->return = $captchamod; }); wire()->addHookAfter('Page::render', function($event) { $template = $event->object->template; $page = $event->object; if ($template == 'admin' && !wire('user')->isLoggedin()) { $captchaScript = $page->captcha->getScript() . '</body>'; $captchaHtml = $page->captcha->render() . '</form>'; $event->return = str_freplace('</form>', $captchaHtml, $event->return); $event->return = str_lreplace('</body>', $captchaScript, $event->return); } }); wire()->addHookAfter('Session::authenticate', function($event) { $page = wire('page'); $template = $page->template; if ($template == 'admin') { if ($page->captcha->verifyResponse() == false) { wire('session')->logout(); wire('session')->redirect(wire('config')->urls->admin); } } });

Hi @Davidov There are two ways how to get it working $teacherItem->teacher_photo->first()->maxWidth(250)->url; Or change your image field setting to: And then you will be able to use your existing code

Nice site! Maybe i should also try to start using the uikit admin theme... @last screenshot: Gallerie should be Galerie

Hi, does @ryan or anyone else have anymore progress or opinion on this, as i think it is a somewhat polarising subject. I believe having lots of different stores would be bad for processwire (as im not very keen on using the https://processwireshop.pw/ store). It would be preferable to have a one stop shop for all modules including premium IMO.

In recent PW3 versions you can prepend "http" and get absolute urls like this: $config->urls->httpTemplates

Right now I am not particular proud of myself, because I maybe had the first occurrence of an hacked ProcessWire installation known to mankind. But not because of ProcessWire itself, but of a stupid mistake I have made. Anyways I want to share my case here: Over one and a half year ago I developed a medium sized website with ProcessWire 2.6.1 for a small community. In the process of releasing the site I had troubles with getting the installation to run on the shared hosting webspace. Because the hoster hadn't configured their file permissions correct, I was forced to loosen up the file permissions inside the site/assets-folder. Because I was desperate and wanted the installation to work I ended up setting every file and folder permissions inside the folder assets to CHMOD 777. I wasn't very happy with this solution and now I know how stupid it was, but I didn't knew better and at least the installation was running. This week I wanted to make a small change to the site and noticed something strange: There was a file called sites.php inside the root folder. At this moment it was clear to me, that my installation was hacked. I immediately downloaded the whole infected installation and compared all files with my local clean installation using a diff tool (Kaleidoscope). After comparing I noticed that inside the index.php one line was inserted which included a functions.php inside the site-folder. Also I noticed that inside the site/assets/files-folder there were several php-files uploaded with the same naming convention like the generated images variants (f.e. filename-large.jpg). So what did those scripts do? Luckily not much, that is the reason I haven't noticed this hack for a long time. The database is as far as I can tell not corrupted and the site was still working properly. All those scripts were doing, was generating spam aliases and redirecting to a medical shop site using the http host of my site. Interestingly on my research I have found out, that most of those malicious scripts were intended to infect Drupal and WordPress installations. A few of those files inside site/assets/files are explicitly targeting WordPress specific functions. If you are interested I can share those scripts for further investigation. But I am not sure if uploading those scripts directly to this board is against the board rules, so if I should upload them to a external service, I am willing to do so. Meanwhile I am confident to have cleaned the site from almost all malicious scripts (I will investigate further) and I am still removing all spam search results from Google using the search console. Also I am in contact with the hoster and try to sort things out, even if it means switching the hoster (which I would prefer). Please don't be to harsh with me. I know I have made a stupid mistake and learned my lesson the hard way, but I wanted to share this story anyway to prevent others from making the same mistake. So always make sure to secure your file permissions! Regards, Andreas

It's a real shame that your site got hacked, but this is definitely something we can learn from, so thanks for sharing it. Shared hosting and lax file permissions are an easy way to get into trouble, but I'm still quite curious about how exactly the site was hacked. From what you've mentioned here (uploaded files, etc.) it kind of sounds like the login credentials might've been compromised, or did you perhaps have something on the front-end that could've caused that? Of course if it really was an "inside job", i.e. if the site was attacked by another user on the same shared server, the files inside /site/assets/ could've been planted there manually. Did you have anything else installed on the same hosting account, another site or web application or anything? If you do find out anything else, please let us know, but just in case: if it turns out that this was actually a result of a flaw in the system itself or perhaps a third party module, please let Ryan know of it before posting to the public forums. I'm extremely confident in the security of the core and have a lot of trust in most of our third party modules, but there's no guarantee that nothing will ever go wrong.

The first part of doing this would be to determine what you want your starting date to be. You could do this by setting a cookie on every pageview to track the time they last viewed it: Setting and getting the date and time of the last visit <?php // see when their last visit was from a cookie that we set if(isset($_COOKIE['lastVisit'])) { // get the last visit time from the cookie $lastVisit = (int) $_COOKIE['lastVisit']; // if it was more than 30 days ago, then just assume 30 days $minLastVisit = strtotime("-30 days"); if($lastVisit < $minLastVisit) $lastVisit = $minLastVisit; } else { // no last visit, so assume 7 days ago $lastVisit = strtotime("-7 days"); } // make a nice formatted date we can use for output later, i.e. October 1, 2011 5:00 am $lastVisitStr = date("F j, Y H:i a", $lastVisit); // set a cookie with the time of this request, and the cookie expires in 30 days setcookie('lastVisit', time(), strtotime('+30 days')); OR, if you wanted to just use a specific date, then you could just do this instead: <?php $lastVisit = strtotime("October 1, 2011 5:00 am"); $lastVisitStr = date("F j, Y H:i a", $lastVisit); // formatted version for output Displaying pages modified since the last visit Once you know your starting date/time (lastVisit), then you can use that to find pages that have been modified since that time: <?php // find the pages that have been modified, and sort by that $modifiedPages = $pages->find("modified>=$lastVisit, sort=-modified, limit=50"); if(count($modifiedPages)) echo "<h2>Pages modified since $lastVisitStr</h2>"; // loop through the pages and display them foreach($modifiedPages as $p) { $modified = date('F j, Y H:i a', $p->modified); // i.e. October 1, 2011 5:00 am echo "<p><strong><a href='{$p->url}'>{$p->path}</a></strong> last modified $modified</p>"; } If you instead wanted to use the created date rather than the modified date, then you would just replace every instance of the word 'modified' with 'created' above. And likewise you can substitute any other date fields you might add to your page. Displaying new comments since the last visit When it comes to comments, we'll use a similar approach. But we first find the pages that have new comments, and then find the new comments on those pages. Since this is more of a specific purpose, we're not using PW's built in comments render functions and instead doing it ourselves here. Also, we'll assume that you already have that $lastVisit variable set from the first code example. <?php // first find the pages that have new comments on them, sort by the comment created date $commentPages = $pages->find("comments.created>=$lastVisit, sort=-comments.created, limit=50"); // output a header that uses the $lastVisitStr var we set in the previous code example if(count($commentPages)) echo "<h2>Comments posted since $lastVisitStr</h2>"; // loop through the pages that have new comments foreach($commentPages as $p) { // find the new comments on this page that have an approved status // status=1 means approved (i.e. not spam or pending approval) $comments = $p->comments->find("created>=$lastVisit, sort=-created, status=1"); // find out how many there are. if none, then move to next in loop $total = count($comments); if(!$total) continue; // output the page that had the comments with a link to it echo "<h3><a href='{$p->url}'>$total new comment(s) found at {$p->path}</a></h3>"; // display the comments foreach($comments as $c) { $cite = htmlentities($c->cite); // prep what we need for output $text = nl2br(htmlentities($c->text, ENT_QUOTES, "UTF-8")); $created = date('F j, Y H:i a', $c->created); echo "<p class='comment'>"; echo "<strong>Posted by $cite on $created:</strong>"; echo "<blockquote>$text</blockquote>"; echo "</p>"; } }