Leaderboard

For the most part I've been working to wrap up a client project this week, running in ProcessWire of course. At this point I'm using markup regions exclusively on new projects, as they really add an element of fun while also simplifying development, at least in my case. Admittedly, when we first introduced markup regions, I thought they'd be a good alternative for new users (who might otherwise use direct output), and didn't think I'd be using them myself. I was wrong. After I started using them, quite awhile ago, I've found that I rarely want to use anything else. I enjoy using them, whether developing something new, or going back and modifying an existing site that's using markup regions. I'm curious if other people have also taking a liking to them? There have been some commits to the core this week, as well as some other not-yet-committed updates on the dev branch, but not enough to warrant a version bump today. So we'll save the 3.0.99 version for next week. I have been getting lots of good reports on the current PW master version, very few issue reports, and feel we've got a really good solid and stable version on our master branch right now. Just in case there's anyone that's not yet using it, I recommend the upgrade. Thanks for reading, hope you all have a great weekend.

Update: LoolEditor now uses its own simple modal without a title bar since the editor's close button also closes the modal. Things feel a lot smoother now. I think PW is currently the only CMS that integrates LibreOffice for free

Ok, I ended up looking into it and from what I can tell the only way is to use the "regular arrays" option, rather than the associative approach. This seems to work: foreach($input->get->amenities as $amenity) { $selector[] = ['amenities.title', $amenity]; } It gets converted to: and the final selector ends up having this, which is what I need. amenities.title=Kitchen, amenities.title=Laundry Maybe this is the only way, but if anyone else has another solution, let me know. Otherwise, hope this helps someone else down the road,

This is a lightweight alternative to other newsletter & newsletter-subscription modules. You can find the Module in the Modules directory and on Github It can subscribe, update, unsubscribe & delete a user in a list in Mailchimp with MailChimp API 3.0. It does not provide any forms or validation, so you can feel free to use your own. To protect your users, it does not save any user data in logs or sends them to an admin. This module fits your needs if you... ...use Mailchimp as your newsletter / email-automation tool ...want to let users subscribe to your newsletter on your website ...want to use your own form, validation and messages (with or without the wire forms) ...don't want any personal user data saved in any way in your ProcessWire environment (cf. EU data regulation terms) ...like to subscribe, update, unsubscribe or delete users to/from different lists ...like the Mailchimp UI for creating / sending / reviewing email campaigns *I have only tested it with PHP 7.x so far, so use on owners risk EDIT: Since 0.0.4, instructions and changelog can be found in the README only. You can find it here ? If you have questions or like to contribute, just post a reply or create an issue or pr on github, thanks!

Quick update and version bump to 0.1.0 I updated the module to use the standard ProcessWire variation suffixes. Instead of image.0x200.optim.jpg, optimized images will now be named image.0x200-optim.jpg. Deleting images in the admin or via the API will delete any optimized variations as before, but the process is a lot more straightforward now. I also added a public method $image->removeOptimizedVariations() that does exactly what it says it does.

An Images field allows you to: Rename images by clicking the filename in the edit panel or in list view. Replace images, keeping metadata and filename (when possible) by dropping a new image on the thumbnail in the edit panel. Introduced here. But neither of these things is possible in File fields, which prompted this module. The way that files are renamed or replaced in this module is not as slick as in the Images field but it gets the job done. The most time-consuming part was dealing with the UI differences of the core admin themes. @tpr, gives me even more respect for the work that must go into AdminOnSteroids. Most of the code to support the rename/replace features is already present in InputfieldFile - there is just no UI for it currently. So hopefully that means these features will be offered in the core soon and this module can become obsolete. Files Rename Replace Allows files to be renamed or replaced in Page Edit. Usage Install the Files Rename Replace module. If you want to limit the module to certain roles only, select the roles in the module config. If no roles are selected then any role may rename/replace files. In Page Edit, click "Rename/Replace" for a file... Rename Use the text input to edit the existing name (excluding file extension). Replace Use the "Replace with" select to choose a replacement file from the same field. On page save the file will be replaced with the file you selected. Metadata (description, tags) will be retained, and the filename also if the file extensions are the same. Tip: newly uploaded files will appear in the "Replace with" select after the page has been saved. https://github.com/Toutouwai/FilesRenameReplace http://modules.processwire.com/modules/files-rename-replace/

Each year we cycle 1000km with our company to fight against cancer. To participate with 4 teams we have to collect 20.000 euros. Our graphic designers made some goodies en we also organise a spaghetti fundraiser. To help the sales we decided to make a webshop with our webteam. And of course we used our favourite CMS for the job! ? https://shop.typografics.be/ At this moment we raised more than 20.000 euros, so all our teams can participate. This is a very special project for us, unfortunately one of our colleagues has been diagnosed with cancer and currently is fighting against this terrible disease. Premium PW modules used in this project: PadLoper FormBuilder ProFields Variations With a few hooks here and there we managed to make it work. To handle the payments we made use of Mollie, we created our own payment module and will opensource this soon. You can read more about this project in our blog (in dutch) Unfortunately we're currently only shipping to Belgium We’re already brainstorming to make a 2.0 version of this webshop, so all your feedback is more than welcome.

I've been searching for a CSS-only solution for a while to reveal a scroll-to-top link only after scrolling down the page, but no luck. Today I figured out that it's possible with position: sticky. The beauty of this is that you don't need to check the scroll position in a scroll event (+ in document ready, window resize), which makes it really lightweight. Update: added "html { scroll-behavior: smooth; }" and now there's animated scroll (Firefox 58+, Chrome 63+). It seems that Js is not required anymore to this feature. CodePen demo

That's what I'm thinking too. I'd like to add a few neat things though before I actively go for more spotlight on it on the web. Auto save is a neat feature but probably not wanted in all scenarios, so I want to make it optional, and another feature I definitely want to get "wired" in is lool's revision history. Currently, it's far too easy to overwrite a perfectly fine document with no way back.

Whether it's currently the only one or not, that would deserve an online article and be good advertising for ProcessWire. As ProcessWire forum topics/posts play well with Google, modifying the topic's title would perhaps be enough or a good start.

so one of the first things i did was change the global to g_settings https://github.com/outflux3/ProcessGeneralSettings/blob/master/GeneralSettings.module#L31 besides that i added support for placeholders, collapsed states, markup, import/export of settings.. +1, i'm super paranoid about global vars now, since i lost all of the listers on one site... not sure if this problem still exists, i may have posted an issue report on the LP thread and Ryan may have changed it, haven't checked though...\ did you encounter any problems with LP? i usually use more verbose globals for that, but on the other hand i have a new module that uses a $meta global, and another one with $theme; sometimes it's nice for the globals to be concise

Personally, I also don't think I would ever use PW regions. I just don't like to mix up backend and frontend code. HTML/CSS IDs and classes shouldn't be related to anything else than HTML/CSS/JS.

I will not be too popular with this but looking at the example above I won't be happy if I would inherit a project with such code. I have dealt with some unusual template syntax recently and from a team and maintainability POV the best is to stick with tools that most developers know, or is understandable at first sight. Of course it's only my thought but I always felt markup regions is a dead end. There are already lot of tools/languages to learn, why add another one to the stack that you can't use anywhere else? (and when there are many alternatives)

Great advices...

Why isn’t there any documentation on Markup Regions within the official docs? The only thing I could find was various blog posts. This would surely help beginners.

@gmclelland, thanks for taking a look at the CSS. I've made some tweaks in v0.1.4 which will hopefully solve the cutoff text you were seeing. Let me know if not.

Phew... This was quite hard but finally I made progress. Please see the dev branch if you want to play around @flydev : https://gitlab.com/baumrock/RockSqlFinder/tree/dev#notes (other parts of the readme are outdated meanwhile, It's just some notes for myself and old examples..., sorry no more time today). This is an example query with a join. This is necessary for pagefields when you want to get not only the page id's but also the related page's fields information like "title": Next step is to make CONCAT operations possible so that the join will return a concatenated string of ids and titles (miau, cat ..., mimimimi). This should also make aggregations like sum() possible (see here: https://gitlab.com/baumrock/RockSqlFinder/tree/dev#notes -> not much change needed for the resulting sql). The new version of the module is completely recursive, so I hope (haha...) that support for image fields with description (in this case it's not a related table but on the same table like the imagefield) easy. We will see... PS: Actually I just realized that defining the field "cats" is stupid when we define a join named 'cats'. Because I'm removing this field later anyhow... need to change this. You see there will be some more changes in the future, sorry...

My module (Settings Factory) has no relation to this module (General Settings), it doesn't share or inherit any code. Settings Factory does not set a global var for the settings (that is left to the user and how they interact with the SF api), therefore it does not suffer from the same issue which is that this module by default/upon installation sets a global $wire var for $settings, which is already being used by LP. I don't personally endorse or promote, or recommend this module – i advise that it NOT be used until the $settings problem is fixed; as i stated in earlier posts, i used it on a couple of sites, forked it and fixed all the issues, but for the last 10 months i only use Settings Factory and i don't use this module at all. It is fine with me if this module is deprecated.

Objectively, this module provides a clever interface for adding fields to your settings. My fork of it supported more fields, and other improvements. The warning here, as is mentioned earlier in this thread is that you do not want to install this module if you use Lister Pro, there is a serious incompatibility that causes your Lister Pro listers to lose their settings. Besides that, Settings Factory allows multiple settings pages (unlimited) that you can link to in your admin menus; this module would be a single settings screen only. Further, you must use the fork if you want to have the settings be accessible to non-Superusers.

I'm just glad that one has a choice with ProcessWire. We are not mandated to use a particular way of website building. It's always good to read about the distinctly different uses of the platform.

Strangely, I tried updating the module with the ProcessWireUpgrade module, but it gave me an error "Session: Invalid download URL specified." It might have been because I originally downloaded the module from github. The text looks good now, it's no longer cut off. Thanks Robin!

Looks cool, but I'm sort of addicted to the WireRender Pattern now... https://github.com/NinjasCL-processwire/wire-render-pattern https://medium.com/@clsource/the-wire-render-pattern-806bf6d6097a

Thanks @ryan I have downloaded the uikit admin template from the dev branche, but unfortunately the problem is still there. Now it is not in the last column but in the second one. Afterward I will try to show you what happens. These are the column widths in my template settings for the 4 fields. Remember the last 2 fields changes depending on the option selected in the second field. So the field named "repeatuntilmonthtype" is a select option field. Depending on its settings the field "repeatuntilmonthnumber" or "repeatuntilmonthdate" will be displayed. Both field have a length of 34% to fit 100% at all. On the first view everything looks ok: Here are the corresponding CSS-classes for each column (from first to last) which were added to the li-tag: First row: Inputfield InputfieldInteger Inputfield_repeatmonthsnumber InputfieldStateRequired InputfieldStateRequiredIf InputfieldColumnWidth InputfieldColumnWidthFirst uk-first-column uk-width-1-3@m InputfieldRowFirst Second row: Inputfield InputfieldSelect Inputfield_repeatuntilmonthtype InputfieldStateRequired InputfieldColumnWidth InputfieldStateChanged uk-width-1-3@m InputfieldRowFirst Third row: Inputfield InputfieldInteger Inputfield_repeatuntilmonthnumber InputfieldStateShowIf InputfieldStateRequiredIf InputfieldColumnWidth uk-width-1-3@m InputfieldColumnWidthLast InputfieldStateRequired InputfieldRowFirst After changing the option in the select field (field in column 2) it looks like this: So this looks like the same problem like in my post before: Here are the CSS-classes: First row: Inputfield InputfieldInteger Inputfield_repeatmonthsnumber InputfieldStateRequired InputfieldStateRequiredIf InputfieldColumnWidth InputfieldColumnWidthFirst uk-first-column uk-width-1-3@m InputfieldRowFirst Second row: Inputfield InputfieldSelect Inputfield_repeatuntilmonthtype InputfieldStateRequired InputfieldColumnWidth uk-width-2-3@m InputfieldStateChanged InputfieldRowFirst Third row: Inputfield InputfieldDatetime Inputfield_repeatuntilmonthdate InputfieldStateShowIf InputfieldStateRequiredIf InputfieldColumnWidth InputfieldColumnWidthFirst uk-first-column InputfieldNoFocus InputfieldColumnWidthLast uk-width-expand InputfieldStateRequired uk-grid-margin Please notice the CSS-class of the second field has changed to "uk-width-2-3@m" which should be "uk-width-1-3@m". The CSS class of the last column is now correct with "uk-width-expand", but "uk-width-1-3@m" should be better. So the main problem is now in the CSS class of the second column. Previously the problem was located in the third (last) column. Only to mention: All these fields will only be displayed if a checkbox is set to true (another dependency). I dont know if this is important to know or not. Best regards Jürgen

I really like them and uses them since the first minute. Mostly in the functions style. That's how my _init.php looks like <?php namespace ProcessWire; $homepage = $pages->get('id=1'); $kontakt = $pages->get("template=cfg")->kontaktdaten; // der Seiteninhalt: region('header+', ''); // fixed header region('nav+', ''); // ist im header region('hero+', ''); // heroimage region('main+', ''); // bodycontent region('footer+', ''); // footer // alle JS codes die innerhalb document.ready am body ende ausgeführt werden sollen, // nachdem jQuery u. main.js schon geladen sind: region('JSdocReady+', ""); // DebugAusgaben am Ende der Seite region('debug+', ''); If you wonder why I initially define the regions with a + (plus sign), it's because sometimes one may end up with a site that do multiple calls of template render functions on one page, what results in multiple includes of _init.php in the chain. This is to avoid an override of previous values. Of course one of the rare use cases, but not impossible.

Yes i'm pretty sure, clean install 3.0.62 , 3.0.96 and 3.0.98 Start from 3.0.96 i can't use : RewriteRule ^(.*)$ /subdirectory/$1 [L] Below code work but not hiding subdirectory in URL RewriteRule ^(.*)$ /subdirectory [L] Yes i have tried all method i found in this forum and stackoverflow, none work yet. Thanks for this, yes it is there.

@gmclelland, thanks for the feedback. I don't want to reinvent the wheel for functionality that's already in the core. I'd actually prefer this module to be more like the Images field behaviour rather than the other way around. I would have done the file renaming the same way as the Images field but the filename is used as a link in the Files field. I will probably work on refining this module to be closer to the renaming/replacing behaviour of the Images field when I have time. I also think Ryan does intend to bring renaming and replacing to the Files field, as the underlying code is in InputfieldFile and labelled with "currently only used by InputfieldImage". We've talked previously about how to limit image renaming by a permission: I don't think there's an easy way to prevent image replacement, but it doesn't really make sense to anyway because if a user has access to an Images inputfield then they can already upload and delete images which is no less destructive than replacing them. I can't see that here so hard for me to fix - it might be OS dependent. When you have a chance, could you have a play around with the CSS and see if you can find a solution? Hopefully without changing the position of the elements. Maybe take a look at line-height, overflow or z-index? Thanks. Yes, it is awaiting approval for the directory.

I wouldn't use any other method now markup regions exist. Love them.

It is at the top of: /wire/core/ProcessWire.php Are you sure? Maybe you overlooked something? As far as I know, nothing has changed in PW which should make it fail if it worked previously. In the forums, there are various discussions on serving PW from a subdirectory, maybe this one is a good starting point: https://processwire.com/talk/topic/15520-processwire-install-on-a-sub-directory/

I get that, but if everyone is using their own helper libraries and different frameworks, you lose the great jQuery ecosystem and all the plugins and libraries built on top of it. You could end up having to include a bunch of code from different libraries that are doing the same thing in order to use the existing solutions you want. That feels like a step backward to me. I don't see why jQuery can't just be retooled so that it's using newer, faster technology under the hood, with the same compact, standardized api on the front end. Maybe have a legacy jQuery and a new, slimmer jQuery for those that don't need old browser support. Regarding jQuery and more advanced JS applications, I don't think jQuery should be thought of as competing against vue or react. It's at a lower level in the stack. It doesn't impose structure on your application, but that doesn't mean it prevents you from creating your own structure. Disclaimer: These are just my feelings as a developer who is still trying to build my applications largely server-side, where my ajax calls usually return blocks of html encoded within JSON instead of pure data structures. This keeps all rendering and business logic server side in order to keep the application code simple and DRY. Not sure if I really know enough about what I'm talking about when it comes to the new client-side development paradigm. I feel like both are reasonable approaches to development (depending on the application's requirements). It's when you don't choose one or the other that things really get messy and WET.

I have only recently started to work on something similar, only streamlined for frontend editing, so kudos for tackling that topic I'm likely going to peek inside the code and steal a few pieces. The only nitpick I have is that the behavior of the replacement option might not be clear to end users. The field should probably be a little more verbose and tell the user that description and/or tags are replaced by those of the selected file, or they might assume it's the other way round. Perhaps a "Replace with" option would be even more intuitive (use the selected file and keep the rest as is). It's how I'd write it as a user story - "I have a file entry on the page with a description and tags and just want to replace the old file with a new one in that entry". Just playing devil's advocate here, as I'm thinking of my 50+ intranet editors who only update their pages a few times every year.

Have you tried to do $page->of(false) before you add the image? $page->of(false); $page->filepreviews->add($img); $success = $page->save(); EDIT: this would explain why the first did not get added but the follwing did. Because of() was only set to false after adding the first image

Worth watching entirely. Don't miss the fallback solution (5 steps). Firefox/Firefox Developer Edition has a grid inspector. https://www.mozilla.org/en-US/developer/css-grid/ https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Grid_Layout https://gridbyexample.com/ https://rachelandrew.co.uk/css/cheatsheets/grid-fallbacks https://cssgrid.io/ (there is also https://flexbox.io/ by the same author) https://cssgridgarden.com/ (already mentioned in the topic) And so on.

Thanks @szabesz and @tpr, same feeling here. I just thought there might be a processwireish-3-lines-of-code-no-dependencies-at-all solution Also thanks @jmartsch, but the last thing i want is to include any dependencies for such a small priority Thanks for your feedback.

Dear @horst, thanks for the valuable feedback. Indeed you mentioned a very good point. I suspect I had a slightly different than usual understanding of how to remove image variations created by modules. The current implementation uses a glob (/{page folder}/{original file basename}.*) to delete variations. I'll update the module to use the standard naming scheme — this will have its benefits especially in edge cases, e.g. images will then still get removed if the module is uninstalled or deactivated. Also good idea about having a public method removeOptimizedVariations(). That will be very easy to implement with the previous issue.

Hi @d'Hinnisdaël, many thanks for this well crafted module. I (only) have read the modules code and checked some, (maybe critical) points for image modules . Everything seems to be well done! Only one thing I spotted, needs a bit clarification from you, as I may not see the whole picture yet. You added a new hook delete to Pageimage. I cannot see how this integrates with PW's methods for deleting variations. How gets it invoked when I a) delete an image via UI and b) when I call removeVariations() via the API? Or what is it for, exactly? Besides the integration with unlink & removeVariations, it may be very useful to have a function that only removes the variations from ImageOptim! TL;DR