Leaderboard

There is kind of built in support for this; - Edit the admin template and add a text field with the name "page_icon" - Go to the admin page tree, search for your lister pages to edit: – Add the fontawesome icon name without the fa- part… Voila: Thanks to @ryan for pointing me to this solution in a support request… ?

Lol I have a good job, I am just looking to showcase my skill and I guess inspire people. Yeah it's just for fun and showcasing my thoughts. Hopefully as time goes by, there would be much more content to share.

A couple of hooks that I have found useful in some situations... In the admin menus the icon associated with each page is normally determined by the "icon" item in the Process module config (e.g. as set in the getModuleInfo() method). But sometimes you might want to change that icon. For example, the Lister Pro module uses the "search-plus" icon, but this is not so good when you have multiple Lister Pro instances because it makes each instance less distinct. With the hook below I can use a custom icon for the extra Lister Pro instances I have added: // Add custom icons to Lister Pro menu items $wire->addHookAfter('Page::getUnknown(page_icon)', function(HookEvent $event) { $page = $event->object; if($page->process == 'ProcessPageListerPro') { if($page->title === 'Flora species') { $event->return = 'leaf'; } elseif($page->title === 'Flora images') { $event->return = 'picture-o'; } } }); If you change an icon in the admin menus like this you can do a Modules > Refresh to clear the menu cache and see the updated icon. And for Page List you probably know that you can assign an icon to all pages that use a template in the template's "Advanced" tab. But with the hook below you can assign icons to pages more dynamically based on any properties of the page. So, for example, you could assign a warning icon to a page to alert site editors if some important field was left empty. // Add warning icon to news items without a date $wire->addHookAfter('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->template == 'news_item' && !$page->date_1) { $event->return = 'exclamation-triangle'; } });

Hi guys, so since I moved to Processwire, it has been my default go-to CMF/CMS for my website and client applications, apparently my previous job took a toll on me, and made me have less time, but now finally had the chance to change my website to something I always had in mind. I decided to go with something minimal, as I tend to enjoy writing, so wanted a website to have more text than graphics and I think I whipped up something clean. Currently I still have more to do, but this is my current website, the main purpose to have a content driven website where I will be writing tutorials , articles more and hopefully technical notes. Please let me know your honest opinion. PS: I am more of a coder than a designer but i think this old dog still pulled it off https://okeowoaderemi.com/

Or

In case your template already has an icon assigned per default, you might want to try this instead: $wire->addHookBefore('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->template == 'event' && !$page->datetimeend) { $page->template->icon = 'exclamation-triangle'; } }); Otherwise the already defined icon shows up as text in your page listing.

?? At first I thought my version was better readable. But I quite like this one: $this->addHookAfter('ProcessPageList::find', function (HookEvent $event) { $event->return->find([ "template!=" => ['admin', 'basic-page'], // keep them ])->each(function($p) use ($event) { if(!$p->editable() AND !$p->addable()) $event->return->remove($p); }); });

Hi @psy The module does a pre-check if the folder of the sitemap is writeable (https://github.com/wanze/SeoMaestro/blob/master/SeoMaestro.module.php#L174-L181). If not, it should not attempt to create the sitemap at all. So I think that we can rule this error out. Thanks @teppo for the investigation and the hint regarding the misleading error message. I fixed it with the following commit: https://github.com/wanze/SeoMaestro/commit/3fc2835b4ea1956006a82b9f8363cb6f89b4f1f4. The module now throws an exception if the sitemap folder is not writeable. This allows to distinguish this error from other errors that could happen during the sitemap generation process. @psy If you update to the latest version on master, you should not see the misleading error message anymore. Did you check the ProcessWire logs if they contain any errors? Also possibly check the PHP error logs on your webserver. My guess is that somehow an error happens during the sitemap generation process. Because this process is executed after the response has been sent back to the client, error messages are not that obvious. If you do not find any error messages, I'd suggest to downgrade ProcessWire to the latest version where things worked as expected. Do you have any SeoMaestro related hooks in place that could cause errors? .htaccess changes should not have any effects on this module. If you can, try to debug what happens during the request, for example with xdebug (like Teppo suggested earlier). Cheers

I refactored your refactored code ? One could also remove the pages that should be excluded beforehand… $this->addHookAfter('ProcessPageList::find', function (HookEvent $event) { $excludePagesByTemplate = ['admin', 'basic-page']; $event->return->find(["template!=" => $excludePagesByTemplate])->each(function ($p) use ($event) { if (!$p->editable() && !$p->addable()) { $event->return->remove($p); } }); });

Well, this likely rules out the first issue I was thinking of. There are still two possible explanations: either sitemap generation fails, or writing the sitemap file to the disk fails. I'm not particularly familiar with this module, so all I can suggest at this point would be dumping some debug data out of SitemapManager::generate() function; basically checking if the !count() statement is returning false (in which case there are no items, which in turn would warrant further investigation into why that would happen), or if it's the write operation that is failing. You should also double-check that the path on disk (the root of your site, essentially) is writable for the user running Apache (often www-data, but could be something else, depending on your setup). Edit: I installed SeoMaestro on a new site running the latest dev version, and everything worked as expected. I know this won't help much in this case, but at least I can confirm that the module should work, which means that the issue is likely somehow related to your environment, or the specifics of your site ?

Do you have a SEO field (FieldtypeSeoMaestro) added to at least one of your templates? I can't remember if this was always a requirement, but without that the module won't generate a sitemap, and thus it will output that specific error message. This error is a bit misleading: it recommends checking that the folder on disk is writable, but you'll get the same error even if you simply didn't have any items to add to the sitemap. What's happening here is basically that the module attempts to generate a sitemap with SitemapManager::generate(), which returns false if it fails to write the file, but also if there are no items to be found. Ping @Wanze – might be a good idea to add additional check for this ? If you do have the SEO field and the write permissions are fine, I'd probably try debugging the sitemap generation code in the SitemapManager class, just to see if it's working as expected.

Worth noting: https://processwire.com/talk/topic/19912-future-of-padloper-new-project-lead-announcement/ TL;DR: https://processwire.com/talk/topic/19912-future-of-padloper-new-project-lead-announcement/?do=findComment&comment=187487

Check Padloper

This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!

@teppo I didn't do anything from this side, so not sure why Packagist decided to update then. I'm guessing they just do it automatically at certain intervals, kind of like the modules directory. Good idea—I'll login to it and see if I can get it to update manually. Thanks.

What does $languages->getLanguage(); return? I have instances where this gives me the correct Language. I also had flacky results with setLanguage and unsetLanguage… Overall, it feels like quite a bit a mess here ? I think, ProcessWire would do very good with some (unit)test… Also for the selector engine…

Lol yes I am not sure what I was thinking when I did the navigation, I guess I got too carried away after looking at awwwards and dribbble. I will work on that Hmmmm this is a very interesting point, So what I aim to achieve is to have a website, where I can share my works, concepts and any crazy idea that comes to mind. I still have so much content to populate the site with, I tend to research and write things down, so I want to use my site as an avenue to share my works. Because I have been told by colleagues that I need to showcase my works and ideas more and also participate in community projects too. That's my goal. I won't mind any advice. Thanks and good to be back.

No solution, but I guess there is definitely something broken. I'm getting error messages like the following on multiple servers of mine: Fatal error: Method SeoMaestro\PageFieldValue::__toString() must not throw an exception, caught ErrorException: chdir(): open_basedir restriction in effect. File(/var/www/php-fcgi-scripts/web366) is not within the allowed path(s) Somebody mentioned that earlier in this thread, but no solution was proposed (the error went away automagically in that case).

I think it's great! I've already incorporated it into my current project, and it has a sizable performance impact on Chrome without any real work on my part. I always thought removing the src attribute and setting it with JavaScript was an antipattern, as anyone with JavaScript disabled wouldn't see any images at all, so it's good to see native support for lazy loading. It's progressive enhancement, so you don't need to have support from all browsers. Support doesn't look half bad though, even though only Chrome supports it at the moment (see caniuse), that's already a sizable chunk of the population. Also, caniuse currently lists Chrome on Android, which is huge (36 %) as not supporting it, I'm not sure that's correct. According to the Chrome Platform Status page, native lazyload is already supported in Chrome on Android. That would get the feature to >50 % browser support already. On current Android versions, all WebViews are provided by Chrome, so it will work in all in-app browsers on Android as well. Also, you can very easily polyfill the native lazyload with JavaScript (see article above), so everyone will profit from this without much of a downside!