Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/20/2020 in all areas

  1. This latest version of the core on the dev branch focuses on comments field updates, significant refactoring/improvements to ProcessWire’s core Template class and PagesLoader class (which is used by the $pages API variable), and we introduce a useful new $pages API method— https://processwire.com/blog/posts/pw-3.0.153/
    8 points
  2. @adrian There are two options when you initialize your CommentForm that let you define what you want to be populated, and whether or not you want it to be editable. These are the 'presets' (array) and 'presetsEditable' (bool) options. I'm initializing with the new CommentFormCustom class below, but the presets options also work with older versions of PW: $options = [ 'className' => 'CommentFormCustom' ]; if($user->isLoggedin()) { $options['presetsEditable'] = false; $options['presets'] = [ 'cite' => "$user->first_name $user->last_name", 'email' => $user->email, ]; } $form = $page->comments->getCommentForm($options); As for using a local image for avatar, or deciding whether or not to show cite and email, this is where the CommentFormCustom class comes in handy. It leaves you in full control of the markup, so you can render whatever avatar image in there you want (whether CommentFormCustom or CommentListCustom), and exclude fields in your markup when conditions dictate. In previous versions, if you didn't want to show specific fields in the form then you would hide them with CSS. @AndZyk Here's how you might do that with a hook. This looks for markdown style links, i.e. [text](url) and converts them to HTML links. The regex may need improvement still, but maybe it's a starting point. $wire->addHookBefore('CommentList::renderItem', function($event) { $comment = $event->arguments(0); /** @var Comment $comment */ $text = $comment->getFormatted('text'); $textOriginal = $text; // look for markdown style links: [text](url) if(strpos($text, '](') { $regex = '!\[(.+?)\]\((https?://[^)\s\r\n;"\']+)\)!i'; $link = '<a href="$2" rel="noopener noreferrer nofollow" target="_blank">$1</a>'; $text = preg_replace($regex, $link, $text); } // populate changed comment text if($text !== $textOriginal) { $comment->set('textFormatted', $text); } });
    5 points
  3. https://processwire.com/api/ref/functions/setting/
    3 points
  4. https://affinity.serif.com/en-gb/supporting-the-creative-community/ + A new 90-day free trial of the Mac and Windows versions of the whole Affinity suite + A 50% discount for those who would rather buy and keep the apps on Mac, Windows PC and iPad + A pledge to engage more than 100 freelance creatives for work, spending the equivalent of our annual commissioning budget in the next three months (more details of this will be announced soon).
    3 points
  5. This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use. Auto Template Stubs Automatically creates stub files for templates when fields or fieldgroups are saved. Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc. Installation Install the Auto Template Stubs module. Configuration You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name. The directory path used to store the stub files is configurable. There is a checkbox to manually trigger the regeneration of all stub files if needed. Usage Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file: /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE. Adding data types for non-core Fieldtype modules The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php: // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits Inspired by and much credit to the Template Stubs module by mindplay.dk. https://github.com/Toutouwai/AutoTemplateStubs https://modules.processwire.com/modules/auto-template-stubs/
    2 points
  6. Just something I was trying out recently that might be useful to someone... With the following hook added to /site/ready.php you can adjust the CKEditor toolbar that a particular role gets for a particular field. Use the name of your CKEditor field in the hook condition. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Define toolbar for a particular role if($this->user->hasRole('editor')) $field->toolbar = 'Format, Bold, Italic, -, NumberedList, BulletedList, Outdent, Indent'; }); Or what I find useful on some sites is adding extra toolbar buttons for superuser only that you don't trust editors to use. $this->addHookBefore('Field(name=my_ckeditor_field)::getInputfield', function(HookEvent $event) { $field = $event->object; // Add extra buttons for superuser only if($this->user->isSuperuser()) $field->toolbar .= ', Table, TextColor'; }); You could use the same technique to selectively define other CKEditor settings such as 'stylesSet', 'customOptions', 'extraPlugins', etc.
    2 points
  7. That's not how this module works. It's just gives you code completion for fields that belong to the template of the current page - $config is an API variable so is something totally different. But you can add type hints for the API variables that PW makes available to template files in a DocBlock at the top of your template files. More info:
    2 points
  8. @Macrura My two cents on this: I feel like it's the other way around — $config as a data store is (for the most part) internal to ProcessWire's backend. The $config->scripts and $config->styles arrays are wired up in a way that makes sense for the admin panel to work properly. Using them for the frontend is surely convenient (I've done that myself on a lot of sites) but probably not meant to be used that way and prone to breaking. I've personally stopped using the internal file arrays for that reason and created namespaced versions for the frontend.
    2 points
  9. Some similar and some other tools here: https://technicalseo.com/tools/ Further details about this topic: https://moz.com/blog/meta-data-templates-123 If you need a module for this, try SEO Maestro.
    2 points
  10. This is actually so useful that I need to add to AOS (if you don't mind) Removing toolbar items is easy with your code but AOS may add extra buttons via CKEditor plugins. I found out that listing them in "removePlugins" is enough, so this can be used to remove extra plugins with ease: $this->addHookBefore('Field(inputfieldClass=InputfieldCKEditor)::getInputfield', function(HookEvent $event) { // do not show modified data on Field edit page if ($this->wire('process') != 'ProcessPageEdit') { return; } $field = $event->object; if($this->wire('user')->hasRole('editor')) { $field->toolbar = 'Bold, Italic'; $field->removePlugins = 'div, justify'; // plugins to remove $field->formatTags = 'p;h2;h3;h4'; // allowed format tags, separated with semicolon } });
    2 points
  11. Process Cache Control This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions. The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu: Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides: An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README. Plans for improvements If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind: Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions! Links https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots
    1 point
  12. You can also create your own .ini file and place it wherever you like: https://www.php.net/manual/en/function.parse-ini-file.php Or a static file you only require/include when needed, from inside your templates.
    1 point
  13. You can read more about these two options here https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/ You can use config.php if you preffer (API is not ready), but I would go with ready.php and setting().
    1 point
  14. @LAPS You can place it in ready.php or if you are using 'prependTemplateFile' option in config.php you can place it in _init.php or whatever you call it. https://github.com/processwire/processwire/blob/master/site-beginner/config.php#L40
    1 point
  15. I think all caching "solutions" would somehow benefit with "warm-up" (you can try a new version of AIOM that mimics how ProCache works). Most crawlers do what you want to do more or less successfully (with some gotchas you and Horst mentioned), but it would certainly look more "professional" and it would be integrated into PW.
    1 point
  16. Can't confirm. I can place images wherever I want in inline mode (pw 3.0.148). Post more details: browser, processwire version, etc. Also check details tab for this particular cke field. Maybe there's something that is causing this kind of behavior.
    1 point
  17. @kixe So the issue here is that the module has a JS file named the same as the module - this is a problem because this module is autoload, and as such the module's JS file is polluting the front end output for any of us who use $config->scripts, meaning that our scripts for use on the front end inadvertently includes the module's js file, which is not only unnecessary, but also is breaking my frontend api. a much better way of loading the JS file is to rename it and then just load the JS on the module's setting page, you can do that by checking the input and loading your js. For now i just disabled the js file, i don't even know if it is needed, or being used, and this has fixed the problem.
    1 point
  18. A little promotion... Just stumbled over this one: https://metatags.io/ - it looks nice. Any experience with this or similar tools?
    1 point
  19. @bernhard thanks, yes I like your solution. Because then I can fallback to the built-in editUrl still in special cases when needed.
    1 point
  20. @ryan released a new version (1.0.8) of this module a few days ago. Thank you! It works perfectly fine as previous versions did - even with the most recent DEV version of ProcessWire. There are also some new features included. Grab your copy now from the modules directory or via the upgrade module. Have fun and stay safe!
    1 point
  21. @horst Hm, I hadn't considered that, that makes it more difficult indeed. Come to think of it, most of my sites would have this issue as well - for example, I use a non-standard pagination approach with URL segments, those wouldn't be caught by just using the public URL of the base page; only the first page would be reached. I guess webcrawling would be a way around that, though that is a real can of worms ... Maybe a good compromise would be making the process hookable, like you said. Maybe the method can call a hookable method that returns an array of URLs for each page; by default it returns only the normal URLs, and additional URLs with additional parameters, url segments et c. can be added through hooks. I'll give this a go when I have the time!
    1 point
  22. @MoritzLost I think it is "the best way!" to use (guest) HTTP requests to warm up a ProCache. Thats why I really like the use of this crawler tool. It starts at the homepage, determine links to the homepages childpages, fetch and parse them, and so on. I think the real problem is to get all "real public URLs" from within PW, as I have sites that use many many pages that have a public state, but in real they are only single sections of a page. So, maybe thats my private problem, but I'm not sure if there is a way to detect which pages / parent pages are official / public URLs. I think if a warmup function can get passed a optional URL list or a PageArray, that overwrites a default behavior, this would be a great benefit for all out there, that uses MVC and other individual approaches.
    1 point
  23. Tested on another MAMP installation and it works as expected there.
    1 point
  24. @MoritzLost A warmUp cache is definetly on the wishlist of some of us. This came up from time to time in forum posts. But with ProCache and larger sites it definetly is not trivial. For smaller sites I have build some individual (hacky) solutions to drop and rebuild the ProCache pages, but for larger sites I manually use a local program that traverses a given website and collect information about broken links, redirects, etc. I'm not sure how big the effort will / must be. I do know some sites (where I use my local tool) that have large archive content, that never will change. My PC time cache limit there is one year! It also could be infinite.
    1 point
  25. @horst Awesome, thank you very much! I'll merge the branch into master soon then. I just need to update the documentation with all the new methods I added in the previous release, then I'll update the module to the first stable release. I'm still thinking about other useful cache actions. I considered a "warm up" method that will just iterate over all the pages and perform anonymous HTTP requests to warm up the template render cache. Does something like this already exist? Would it be useful to anyone? For smaller sites it would be trivial, but for larger sites the module might need some form of rate limiting, batch processing ... not sure if it's worth the effort?
    1 point
  26. I successfully tested it on one site several times (ca. 10x) with ProCaches between 50 and 700 pages! ? Nice work!
    1 point
  27. I just updated the module to version 0.5.0! I have now installed it on a couple of sites and it's pretty stable by now. But before I tag a stable 1.0.0 release I would really like to get the ProCache integration working. ProCache integration - Testers wanted If somebody has access to the ProCache module and would like to help me, I just need someone to test the ProCache integration! To get started, download the procache branch of the module on Github and install it . There should be a new "ProCache" option in the module configuration. This field should also tell you whether you have ProCache installed. Check this option. Then go to the Process page through Setup -> Cache Control and click the "Clear all" button. The log output should clear the ProCache entirely. I'd like to know if you get any errors during any of those steps. Also, please check if the ProCache has been actually cleared. Thanks! Version 0.5.0 The new version provides some additional helper methods to check if users can access particular actions and improves the status messages displayed on the process page. In particular, there's a new static method to check if the user can access the module. This is important, because instantiating the module ($modules->get('ProcessCacheControl')) will throw an error if the user does not have the required permission. So this can now be checked with the static method ProcessCacheControl::canUseModule($user). The complete Changelog can be found in the CHANGELOG.md in the repository.
    1 point
  28. Hello, I don't want to hijack this topic, but since this topic is about the comments field I just wanted to ask this short question, because a client just asked me about this: Is there an easy way to convert links inside comments to clickable HTML-links? I know that HTML tags aren't allowed in the comments field and for a good reason, because that would be unsafe. But our client has a blog and wants to link to an internal blog post inside a comment. I could use preg_replace with a pattern to find links and add markup to them, but this way I would have to recreate the whole markup of: $comments->render() I would appreciate some help and I can create a new topic if this is not the right place. ? Regards, Andreas
    1 point
  29. @Robin S I voted for that in 2016... Why did that take so long? ? Just kidding ? Thank you for creating this and sharing it with us! ?
    1 point
  30. Everybody please take this pandemic really seriously!! Panic does not help for sure, but ignorance or underestimating this situation will cost the life of thousands of people all over the world! As the following chart shows, the mortality highly depends on the amount of people that are in need of medical care at one time! Taken from link 2, see below. I have underestimated it myself just like almost anybody in europe has, as nobody of us here has ever experienced a situation like this before (in contrast to asia). Here are two links that I encourage everybody to read, even if you live in an area that has not (yet) been affected: 1) https://www.washingtonpost.com/graphics/2020/world/corona-simulator/?fbclid=IwAR0ABgvQGxm005seLywxDkZScKImi53Du9lzAlMwrDH6qsaaefW-Oux-Gao They have great simulations of how such an exponential growth can/will happen and what every single person can do against it! 2) https://medium.com/@holger.heinze_81247/coronacodex-my-commitment-during-the-covid-19-pandemic-76613656dac0 I hope that was not offending the forum rules that don't want political discussion... I work 100% remote now and I encourage everybody to do the same if at all possible. Not because I'm afraid (luckily I'm not at high risk as I'm young and healthy), but to take responsibility for all the people around me and keep the number of people needing medical care as low as possible so that the staff in the hospitals does not have to decide which patient (with severe symptoms) is treated and which is not (and will likely die).
    1 point
  31. Interesting ? Yeah editUrl() is not hookable! Based on Zekas suggestion maybe something like this: $wire->addHook("Page::_editUrl", function(HookEvent $event) { $page = $event->object; switch($page->template) { case "home": $event->return = $this->pages->get(2)->url."my/custom/edit?id=$page"; break; default: $event->return = $page->editUrl(); } });
    1 point
  32. Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip
    1 point
  33. No, it's not in the directory. You should really take a look at @netcarver's awesome: https://pwgeeks.com/ - just type "cache" in there and you'll find some other cache related tools. Thanks for the rundown of differences - that will be really helpful.
    1 point
  34. I chucked up a tutorial here: https://www.pwtuts.com/processwire-tutorials/making-a-custom-admin-theme-using-uikit-3-and-the-included-build-tools/ Hoping this method will become redundant though if I can get my head round building a module to change the colours etc. Something to work on in January (without distracting me from my JS which I should be doing...).
    1 point
×
×
  • Create New...