dynweb

You can put a FieldsetPage inside a FieldsetTab, this should work.

Pageimages::add() should do what you are looking for.

I agree that the Sendy interface is a bit cluttered, but the application itself works very reliably. I'm using it in production for some time now. It is regularly updated and updates are easy to deploy. It is cheap (pay once, no subscription) and has no restrictions concerning the number of clients, subscribers, lists, emails, sender domains... Sending through Amazon is not only cheap (no subscription needed), but also very reliable. No more complaints about newsletters in the spam folder (unlike Mailgun, Sendgrid...). It has a basic API -- it is easy to to integrate with PW. You can let your users build their newsletter with ProcessWire and then send the HTML code via API to Sendy, creating a new campaign. In Sendy, you can handle the selection of mailing lists and all campaign related settings. The most important data from Amazon is directly available in Sendy: number of mails sent, opened, bounced. Hard-bounced Emails are automatically blocked in Sendy, that helps a lot maintaining a good reputation with Amazon. Your users will never have to login to the confusing Amazon SES interface to understand what happens. Except for a few obfuscated files (license check, etc.), the Sendy source is accessible and can be modified, if necessary.

Yes, it seems that font-family declarations do not work here. To style the headings menu entry, TinyMCE takes the corresponding font-family from your content_css (in this case: whatever you defined for h1) and applies it inline. But webfonts are not displayed, only the font fallbacks (Arial, sans-serif...).

This can be done in the "Custom style formats CSS" field. Something like this to change a <h1>: #Headings h1 { font-size: 1.8rem; line-height: 1.1; text-transform: uppercase} /* My headline 1 */

You can use our own stylesheet for the TinyMCE editor. In the TinyMCE settings, field "Default setting overrides JSON text", you can add something like this: { "replace_content_css": "/site/css/tiny.css" }

In my experience: Just show them all, on first sight, without need to tap, even if it is ugly ? If not, you will inevitably have to deal with one or more logo partners deeply dissatisfied for lacking visibility. "No one will tap 10 times until they arrive at our logo..." Just my 2cents...

If the file vendor/autoload.php exists, it will be called automatically by ProcessWire's index.php. No need to call it manually.

Did you try this? $p->save(['noHooks' => true]);

Have you checked that there are no files prepended/appended when rendering the template? Maybe disable Tracy debugger?

Hi Robin, With the module installed, when I want to edit an image (e.g. crop) in admin, I get the following exception on clicking the "Apply" button: The exception also occurs if I have previously generated all delayed images with the option "Generate queued variations". The error does NOT occur after uninstalling the module. Any ideas? Thanks ?

Hi, I'm using your module for the first time, looks really promising ? It seems that password fields *always* show a password toggle, even if the showPasswordToggle() method is not called in user code. In InputPassword.php, line 105, it unconditionally appends the checkbox: $this->append($this->showPasswordToggle()->___render()); My solution was the following, but not sure if that won't break other things: // InputPassword.php // Line 26 // protected InputCheckbox $showPasswordToggle; // The password toggle checkbox object protected bool $showPasswordToggle = false; // Line 85 // $this->showPasswordToggle = $toggle; $this->showPasswordToggle = true; // Line 105 // $this->append($this->showPasswordToggle()->___render()); if($this->showPasswordToggle) { $this->append($this->showPasswordToggle()->___render()); }

You could add a multi page reference field to the "Project" template to store the associated persons. And synchronize the two reference fields with the excellent "Connect Page Fields" module by Robin S. https://github.com/Toutouwai/ConnectPageFields

This should help:

I would add a new field with your requirements and migrate the contents from the "old" to the "new" field. Here is how I did it for a migration from a single image ("image") to a multiple images ("images") field: $gearPages = $pages->find("template=products-view-gear, include=all"); foreach($gearPages as $p) { if($p->image) { $p->of(false); $p->images->add($p->image); $p->save(); } }

When editing a template like this: As long as a template does not define its own access rights, the option "Yes always, regardless of page status or access control" has no effect: it "sticks" in the admin interface, but the folder /site/access/files/XXX is not prefixed with a "-" and access control is not enforced. The file is delivered by Apache. If the template defines its own access right, it works as expected (by me). The file is delivered by PHP. It this expected behavior? Is there some good reason why a template must define its own access rights to enforce access control to files? Thank you for your insights. Edit: Tested on latest PW stable, pristine install.

You can choose on your implementation if you want to charge the user's card immediately ("capture") or only reserve the funds for later capturing (via Stripe admin or API). The only problem is that it doesn't make much of a difference to the user (Stripe event advises that many users won't see a difference on their CC statement between "reserved" and "captured" amounts). Even if an amount is "only" reserved, the client can no longer dispose of these funds.

I would definitely be interested... if some client would ask for a (PW integrated) forum. Must be at least 10 years now that I haven't had such a requirement. So I am not sure that there still exists a sizable market for (new) forum softwares...

if(class_exists('\Tracy\Debugger', false) && Debugger::isEnabled()) return; Works for me. We just tell PHP to skip autoloading, so it will never know about the composer version.

Not really ? At this point, Debugger is probably not enabled, so no output at all. if(class_exists('\Tracy\Debugger')) { \Tracy\Debugger::enable(); return; }; This one works, but the Tracy bar has none of the ProcessWire specific info (as the init() method returns early). if(class_exists('\Tracy\Debugger')) { $this->wire('session')->error('Cannot activate TracyDebugger because another version is already installed, maybe via composer?'); return; }; This kind of error message, however, would be really helpful for people like me who don't remember the stuff they have in their vendor directory...

Seems as if Debugger::isEnabled() returns false after a fresh composer install so it can't prevent double loading. I just have to be careful not to require tracy/tracy via composer (or nette/nette that adds *all* packages), so this shouldn't be a major problem ?

OK, problem solved ? Tracy is working with a pristine PW install. All my "customized" installs have a vendor directory where I (previously) did a composer require nette/nette which also installs tracy in the vendor dir. And this version is loaded first, resulting in the "Cannot declare..." error. Thank you for your help, @adrian !

Thank you, @adrian I can reproduce the error on my local dev server and on the live server(s). I already tried to to refresh modules and to clean the file compiler cache, to no avail. I still have to test it with a pristine processwire install, I will let you know...

Starting with version 4.3.26, I get a compile error after installing/upgrading Tracy: Compile Error: Cannot declare interface Tracy\ILogger, because the name is already in use (line 16 of site/modules/TracyDebugger/tracy-2.9.x/src/Tracy/Logger/ILogger.php) It seems that this commit https://github.com/adrianbj/TracyDebugger/commit/10e1d3a28a2719d120325eaf4559505c3ebd98a9 is source of the error. When removing the line if(class_exists('\Tracy\Debugger') && Debugger::isEnabled()) return; everything is working again. Tested on PW 3.0.184 and 3.0.200. Any input will be appreciated -- I have no idea where to start ?

Download works for me, too. Just in case: Have you checked that you have the correct time on your localhost? That might prevent the cert to validate.