Leaderboard

Drupal is built on top of Symfony, nothing bad about that and also Composer (which I use regurally in Processwire too). PHPUnit and Nightwatch: those two obscure strangers to me? I've been always keen to learn new technologies, as long as they had something I feel better from the ones I knew at the time and...let me say, Drupal is not even close to an improvement in any way for my tastes. Just a couple of further toughts after some more time spent on it: 1) You have to clear the cache every time (EVERY TIME) you change something to your twig template files. Added a variable? Flush that cache. Added a new file? Flush that cache. Imported something? No problem, but flush that damn cache. You can do it installing a CLI module (Drush) and type a string to do so but....come on.... 2) There is no concept of a Blank Site Profile (like my loved PW goto profile). Every site has to have a theme, and 99% of the time it has to extend from another one whom has tens of twig files (that MUST follow a strict naming convention based on regions, blocks and whatnot) to copy from. It's not my way to develop, never was. Yes, you are right and it's totally nonsense. I'm working on it. There is one site (a digital report) for a mid/large company I've made some time ago (http://novacoop.info) that has to be updated every year with new content and design. I will push to not change stack and do my best to expose PW potential then. I know, dammit! :)

In case someone feels like contributing by replacing Flourish with imap_open, this code should get you started: $inbox = imap_open('{imap.gmail.com:993/imap/ssl/novalidate-cert}', 'address@domain.com', 'password'); $msgnos = imap_search($inbox, 'UNSEEN'); if($msgnos) { foreach($msgnos as $msgno) { imap_setflag_full($inbox, $msgno, "\\Seen \\Flagged", ST_UID); $header = imap_headerinfo($inbox, $msgno); $bodyText = imap_fetchbody($inbox, $msgno, 1.2); if(!strlen($bodyText) > 0) { $bodyText = imap_fetchbody($inbox, $msgno, 1); } $timestamp = strtotime($header->date); $toObj = $header->to[0]; $fromObj = $header->from[0]; $to = $toObj->mailbox.'@'.$toObj->host; $from = $fromObj->mailbox.'@'.$fromObj->host; } }

Can you not do this? $cl = $languages->get($user->language->name); $blog_title = empty($page->getUnformatted('title')->getLanguageValue[$cl]) ? 'Look Ma No Title' //user’s language title is empty : $page->getLanguageValue($cl, 'title'); //user’s language title is not empty The unformatted value of language fields should be a LanguagesPageFieldValue object that you can ask about language values without fallback: https://github.com/processwire/processwire/blob/dev/wire/modules/LanguageSupport/LanguagesPageFieldValue.php

As for direct statement about financial advantages I cannot provide anything (thought I remember reading something related to it) but I do infer such a thing from this comment, for example: https://processwire.com/talk/topic/2043-drupal-vs-processwire/?do=findComment&comment=19084 Quote: "The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious)." Well, while writing this, I actually remember reading somewhere that he wrote that his previous way of doing business (when still using Drupal perhaps) was more profitable than the current one based on ProcessWire, but that is not just about working with PW vs Drupal but as business as general. Maybe we should ask @ryan itself? Anyway, as an addition to the actual topic: This might also help @3fingers when explaining the benefits: https://processwire.com/talk/topic/4426-pushing-pw-in-web-design-agencies/

Thx ? Yeah that's the usual way of doing migrations. I started like this at the very beginning, always creating a file with an upgrade() and a downgrade() method. But the declarative syntax is just so much better! It's easier and a lot faster to write (develop) and it's easier to read (understand) and it's also a lot easier when looking at git diffs: You instantly see what I did here: Renamed the field constant from field_persons to field_personimages and added the field_personmatrix below the field_footermenu. And you can simply go back and forth in time by using your IDE: You could do that. The easiest way is to put everything into migrate.php; It's the same as with hooks. Where do you place your hooks? All in ready.php? Maybe you started like this. But likely you'll not do so any more and have most of them in dedicated modules where you bundle things that belong together. As you said that has the huge benefit of making things reusable. Since I've adopted that approach I'm developing faster than ever before. But to get started just go ahead with migrate.php ? Regarding your question about one file for fields and one for templates. You can do so. It's maybe a matter of preference. But I prefer to put everything in modules or pageclasses. Let's say we create a blog. We need a "blogitem" pageclass and that pageclass uses fields "title", "date", "content": <?php namespace ProcessWire; use RockMigrations\MagicPage; class BlogItemPage extends Page { use MagicPage; public function migrate() { $rm = $this->rockmigrations(); $rm->migrate([ // field migrations 'fields' => [ 'date' => [...], 'content' => [...], ], // template migrations 'templates' => [ 'blog-item' => [ 'icon' => '...', 'fields' => [ 'title' => ['columnWidth' => 70], 'date' => ['columnWidth' => 30], 'content', ], ], ], ]); } } Do you understand what it is doing? At first sight? Or would it have been easier if the migrations lived in fields.php and templates.php ? Also a thing to keep in mind is that sometimes the order of execution matters. And that's easier to handle if you place your migrations in places that belong logically together. That situation often arises when I'm writing migrations for parent/child template relations. The concept is as follows: Have a master module (I recommend having a Site.module.php for every project and the default migrations profile does that for you ? ) Load pageclasses from the master module (eg BlogItems and BlogItem) Trigger migrations in every pageclass (RM has helpers for that, see https://github.com/baumrock/RockMigrations/wiki/Ship-your-Module-with-Custom-Page-Classes ) That takes care of creating all fields for the template and adding fields to the template (like the example above) THEN set parent/child relationship (both templates need to exist before we can set this relation!) This makes the backend now that if you create a new page under "BlogItems" you are only allowed to add a single "BlogItem" Does that make sense so far? RockMigrations runs on every single request. Then it checks all the files that have been added to the watchlist (migrate.php is added by default, others can be added via $rm->watch(...)) and it will run the migrations for every file in the watchlist that has been changed since the last run of migrations. So if you had 30 files watched and you change one (let's say "BlogItem.php"), then only migrations of this file will be migrated. All others will be skipped. You can inspect that easily via the tracy logs panel where you see what is going on and in which order: Now if you combine that with RockFrontend, then you get instant reloads of the backend and therefore instant migrations while you code. So great, you have to try it! If you run migrations from the cli or you do a modules::refresh then all migrations are run (just in case the watcher does not catch up a file or something goes wrong): If you still have any questions let me know ? Also I'm happy to do consulting via online meeting if you have questions specific to a project (or want to support me and the development of my modules).

Relying on the frontend cache all the time is the telltale sign of the system's request process being very slow most of the time. Usually it is the result of over-engineering and "enterprise developers" are soo keen on that. In my coding vocabulary: $enterprise === $overEngineering // > true Also tell them that Ryan developed ProcessWire because working with Drupal took so much extra time that even developing his own system was a lot better choice, therefore more profitable. Probably Nette's Tester can do the trick when they complain, see:

Github: https://github.com/thetuningspoon/AdminPreSaveValidation This module prevents admin editors from saving changes to a page that has one or more invalid fields. It uses an ajax call to check for errors and javascript to populate the page edit form with any error messages that were returned. This way the user can correct the issues and resubmit the form without invalid data getting saved to the database or the editor losing changes. I've wanted a way to implement this common workflow in ProcessWire for some time now and this relatively simple ajax-based approach makes it possible without getting too much in the way of how ProcessWire normally works. For example, all of the post-save actions (Save + Exit, Save + View, etc.) still work as usual. The only downside is that a successful save will take a bit longer as it involves two sequential http requests (the initial ajax request that checks for errors and the normal page submit after no errors are returned). This module has also been tested successfully with repeaters and other nested inputs. By hooking after Inputfield::processInput, you can add your own custom validations to inputfields and this module will pick up on and display them as well. /* * Example of hook that adds an error to an inputfield. This will add an error to every input. */ $this->wire()->addHookAfter("Inputfield::processInput", function(HookEvent $event) { $event->object->error('Invalid input!'); }); I hope others will find this module useful!

@tires - the Flourish library is no longer maintained, so this module really needs to be rebuilt so that it doesn't rely on it. It's quite easy with imap_open https://www.php.net/manual/en/function.imap-open.php but I'm afraid I really can't contribute more time to this module - I've never actually used it myself and I don't think it has a huge user base, but I am sure Pete would accept a PR if you'd be willing to implement imap_open.

Found the issue, I hadn't realised that Hostgator's control panel ammended my .htaccess When I uploaded the local version I didn't have the lines below: # php -- BEGIN cPanel-generated handler, do not edit # Set the “ea-php81” package as the default “PHP” programming language. <IfModule mime_module> AddHandler application/x-httpd-ea-php81___lsphp .php .php8 .phtml </IfModule> # php -- END cPanel-generated handler, do not edit G

I created a Pull Request with two fixes. Fixed a bug that formatted Hexcodes starting with 0E to 000000 (Issue #12) Added CSS to distinguish fields with no value (red strike through)

@androbey - I've just committed a new version which adds Slack support. It's not super well tested, but so far it's working here nicely. You will need to edit the config settings to set the name of the slack channel and the Slack App Oauth Token of your Slack App that has permission to post to the specified channel. Not sure if you have ever set up a Slack app (bot) before, but this should get you going: https://api.slack.com/bot-users Let me know if you have any suggestions or find any bugs.

yes, you are so right. My client is reluctant to use a service like that though. Thanks anyway for the suggestion.

Not sure I fully follow the issue - but wouldn't it be easier to just use an email MSP like Mailgun to route all your emails. You can send 10's of thousands of emails at low cost this way and not have to worry about hitting limits? Plus the WireMailgun module works a treat ?

This is really weird - I was just about to start typing a message into the forum about this. I'm working on a module where I cannot get the upgrade method to fire. I'll post separately rather than hijack this thread but glad to see it's not just me with this problem!

@pwired Now change "Drupal" with "Wordpress" and it's still remaining a valid sentence. :)

You can use the new getPageListLabel() method of custom page classes to mimic a table-like list: <?php namespace ProcessWire; // placed in /site/classes/BasicPagePage.php class BasicPagePage extends Page { public function getPageListLabel() { return "<span style='display:inline-block;width:200px;outline:1px solid black;'>{$this->id}</span><span style='display:inline-block;width:300px;outline:1px solid black;'>{$this->path}</span>"; } } Brilliant new feature ?

My first thought was that Ryan is building his own rich text editor, maybe using a toolkit like ProseMirror. Let's keep guessing and maintain the hype ?

I guess we're going back to TinyMCE)))

Loving it ? You can't do that ? What is it? https://github.com/quilljs/quill ? https://github.com/summernote/summernote/ ? Also, some insights on that part would be especially interesting ? Fingers crossed for a smooth transition! Thx for all your great work!!

I use Firefox when debugging srcset as unlike Chrome it doesn't do this!

Did this ever happen? I can't find any PageTable documentation for all my searching! It seems odd, the docs are so great, generally. (I'm specifically looking for how to create a page with several pagetable field values programmatically).

This was the problem! It now works as expected. So each file (.module.php, .info.php and .config.php) need to be namespaced. Thanks all for your help!

When using setUp and tearDown methods it's good to keep in mind that Tester runs tests in parallel threads. That is, if you except that a Page you create in the setUp method will be deleted in tearDown before the next test method begins, you may be wrong. For example I've created and saved a new Page with the same title in setUp and deleted it in tearDown. I randomly got a ProcessWire error saying it could not generate a unique name for the page, and that was because the other tests have been started before the page could be deleted in the tearDown method. The actual thread number can be retrieved, so appending it to the title solved the issue (or by adding a random suffix): $p->title = 'Test ' . getenv(\Tester\Environment::THREAD); Alternatively you can reduce the number of threads to 1 with the "-j 1" switch (runtime will increase a lot).

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

I respect Drupal, but strongly dislike using and developing in it. This comes from a couple years of developing sites in it. The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious). People may use Drupal at large scale, but I don't believe the product itself was ever truly designed for it. Like with WordPress, being used at the large scale is something that happend to Drupal rather than something it made happen. Drupal is a pig that people have affixed wings to because there wasn't any other way to do it at the time. You see similar things happen with the other big platforms (WordPress, Joomla). As far as pigs go, Drupal is a good one. There are some things to respect (though not necessarily agree with) about Drupal's roots and the original thinking behind it. There's no doubt that it is far better than Joomla, for anyone that cares about this stuff. Beyond that, where it excels is in all the 3rd party stuff written for it, to do just about anything. It's a diesel-powered cuisinart in that respect… whatever you need to blend, it will blend… but it'll be messy. Working at large scale, 3rd parties have built all kinds of caching, CDN and load shifting things to throw on top the pile (and likewise with WordPress). Even a pig can fly if you strap wings on to it. And Drupal has a lot of folks thoroughly invested in it to the point where they are making that pig fly. Drupal is also such a household name that it represents a low-risk position for decision makers (low risk of job loss from choosing Drupal). None of this makes it a good product, just a safe one for people that don't know any better. But for people that do know the difference, we want a panther, not a pig.

The Processwire Paradigm has already decided for CKEditor 5 No need to question it.