gebeer

Almost 2 years later and I am trying to tackle the same problem. $config->adminThumbOptions is still being referenced in https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldImage/InputfieldImage.module In https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/config.php#L755 it says width and height are deprecated in favor of gridSize. So it seems we cannot set a default admin thumb size anymore with width and height. BUT something weird is happening in a 3.0.65 install when I add this to config.php $config->adminThumbOptions = array( 'width' => 270, // max width of admin thumbnail or 0 for proportional to height (@deprecated, for legacy use) 'height' => 0 ); I have 2 image fields. One for single. the other for multiple images. After adding above setting, thumbnail creation for the multiple images field results in 270 width images. But only if I do a $myimage->width(270) directly after frontend upload. Even after reloading the page in admin, no extra variation is created. So far so good. BUT the single image field behaves differently. Through a hook I create a variation 270x0. But an additional variation 0x260 is created. This seems to follow the gridSize setting logic. So the behavior is different across 2 fields. Only difference in the field settings being that one is single, the other is multiple images. I would love to see consistent behavior here. And it would be super great to have full control over variations created automatically by PW. Imagine a use case where pages never will be opened in the admin, not even listed with pagelister. This is my scenario. And we will have about 25,000 pages created with 3 images each for that project under heavy server load with up to 3000 visitors at the same time. Of course we would like to keep storage requirements as lean as possible and optimize for performance. Meaning creating as few image variations as possible and only the ones we really need. Guess this is a rather rare use case for the time being. But still it would be awesome to have full control over the admin thumby thing. Especially since more and more devs seem to be using PW as a headless backend.

I was just about to ask for a release date, too :-) Seems I'm not the only one who is keen on getting their hands on this. As I understand it, this will be released as a paid module which is only fair. @flydev ?? mentioned that he wants to get the promoting website up and running before selling the module. Just in case that this is slowing things down, I would even be happy to pay for a pre-release version.

Thank you for this module! It was not working for me until I found out that the HTML created by CKEditor was something like <p style="margin-left:0cm; margin-right:0cm">https://www.youtube.com/watch?v=Lh63JcccM7k</p> So the <p> tag has a style attribute. The regex (line 180 in module php) does not cater for that. $regex = '#<p>\s*(https?://(?:www\.)?youtu(?:.be|be.com)+/(?:watch/?\?v=|v/)?([^\s&<\'"]+))(&[-_,.=&;a-zA-Z0-9]*)?.*?</p>#'; I adjusted it, so that it also works for paragraphs with attributes $regex = '#<p.*>\s*(https?://(?:www\.)?youtu(?:.be|be.com)+/(?:watch/?\?v=|v/)?([^\s&<\'"]+))(&[-_,.=&;a-zA-Z0-9]*)?.*?</p>#'; @Lex Sanchez maybe you want to implement this in your module.

Glad that this is still useful for you. In the meantime there have been quite a few posts about this topic and there is a great module out there that can assist in building REST APIs with ProcessWire: https://processwire.com/modules/rest-api/

Here is one possible way to go about this: add the user role and template name to the ProcessWire.config JS object with https://processwire.com/api/ref/config/js/ in /site/modules/InputfieldCKEditor/config.js retrieve that information and setup different CKEditor configs depending on role/template

You can load all the CKEditor assets in a template by loading the module $modules->get('InputfieldCKEditor'); This will load all assets to $config->scripts and $config->styles Now in your main.php (or template file that renders your <head>) you need to include something like foreach ($config->styles as $file) echo "\n\t<link type='text/css' href='$file' rel='stylesheet' />\n"; foreach ($config->scripts as $file) echo "\n\t<script src='$file'></script>\n"; This approach is only working with the delayed output strategy.

That was me ? @Sevarf2 I pushed a fix. Please download https://github.com/gebeer/FieldtypeImageReference/blob/master/InputfieldImageReference.module Sorry for the inconvenience!

No plans to implement this for now. If there are multiple requests I will consider it.

@Sevarf2 where do your images live, in site/assets/imgs? Then you need to define just 'imgs/' I just pushed a fix for the error you mentioned to github. You only need to download and replace https://github.com/gebeer/FieldtypeImageReference/blob/master/InputfieldImageReference.module Let me know how it goes.

@Sevarf2 please post your settings.json again. Do you have TracyDebugger installed, any Errors?

@Sevarf2 you need to specify the folderpath correctly. When the files are located in /site/templates/images/icons/, the value is 'images/icons/ ' When the files are located in /site/assets/icons/, the value is 'icons/' Hope that helps

This module is an SMTP extension for the WireMail class. It can only handle SMTP transport which is for outgoing mail. There is no module that I know of which can handle incoming mail (IMAP, POP3). If you want to handle incoming mail, you could use a service for transactional emails like mailgun (and the WireMailgun module) and use webhooks. But this still involves quite a lot of programming.

If you are using v1 of this module and you want to auto-remove entries from the 404 monitor when you create a jumplink from an entry there, you can use this simple hook in site/templates/admin.php $this->addHookBefore('ProcessJumplinks::executeCommit', function(Hookevent $event){ $input = $this->input->post; $sourcePath = $input->sourcePath; if($sourcePath) { $statement = "DELETE FROM process_jumplinks_nf WHERE request_uri = :sourcePath"; try { $this->database->prepare($statement)->execute([ 'sourcePath' => $sourcePath ]); $this->message("Eintrag '$sourcePath' wurde aus 404 Monitor Liste entfernt"); } catch (\Throwable $th) { $this->error("Fehler beim Entfernen des Eintrags '$sourcePath' aus der 404- Monitor Liste: " . $th->getMessage()); } } }); and adapt the messages to your liking :-)

@iNoize you are talking about SeoMaestro. But this is the thread for MarkupSeo module ?

Thanks for clarifying. Which hook would you use to trigger deletion of logger entries, ___executeEntity or ___executeCommit?

Actually, I set this up once for multiple projects. Now every time I add a new project it takes me 5 minutes which is ok for me ?

Let me throw https://laradock.io/ into the mix. I've been using it for the last 3 years or so. Absolutely great.

@Mike Rockett has this been addressed yet? I have a customer complaining about this. Would be really nice if those 404 entries got removed. Any plans on implementing this? And thousand thanks for this great module!

I tried both but it didn't help. Also I uninstalled and removed the module, deleted all cookies, local storage and session storage and then reinstalled. Problem persists. Can't see what the invalid escape sequence could possibly be. On my local dev install of the website, I don't have that problem. I'll try to find the cause for this behaviour and will let you know here. Thanks again.

Thanks for that hint. I already had deleted cookies and local storage. Didn't help. Problem persists across browsers, also in private mode. So it doesn't seem to be related to local storage.

Hello, on one of my installs the editor window in the Console in the backend doesn't show up and I get this error in the JS debug console: Uncaught SyntaxError: invalid escape sequence evalScripts .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:514 forEach .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:665 evalScripts .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:508 init .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:35 displayTimeout .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:302 setTimeout handler*initTabs/</< .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:297 initTabs .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:291 forEach .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:665 initTabs .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:264 init .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:254 init .../admin/module/edit?name=TracyDebugger&collapse_info=1&_tracy_bar=js&v=2.5.9&XDEBUG_SESSION_STOP=1:388 <anonymous> .../admin/module/edit?name=TracyDebugger&collapse_info=1:284 edit:1:155320 This has been going on for some time. Also persists after upgrade to v4.21.20. Refreshed modules, cleared all cookies and local storage related to TD to no avail. Console looks like this and div#tracyConsoleEditor is empty: Any help on how I can back the console editor would be much appreciated.

HAving similar PHP warnings here PHP Warning: exif_read_data(1-transf-kosk4-min.gif): File not supported in /home/m1698/Sites/processwire/site/modules/FileValidatorImage/FileValidatorImage.module:398 On this install I'm running images attached to a frontend form upload through the FileValidatorImage module which I installed first. This module uses PHP's exif_read_data function. And that doesn't seem to support gif. Couldn't find a list of supported file types in the PHP docs, though. I don't really worry too much about the warning itself. Only the mails I get from Tracydebugger get annoying after a while ;-) Just posting for reference.

The wire folder is already in my workspace. Or do you mean I have to add it in VSCode in the workspace settings? After adding namespace ProcessWire to my template files, I got rid of these errors.

VSCode with intelephense, in the Problems tab I always get this error for __() language string function Anyone knows how to get rid of this? Just found out that it was a namespace problem. When namespace ProcessWire is not declared, intelephense will throw this error.

If I understand this correctly, then your default language should be German. What was the reasoning behind switching languages in your case? If you want to write a PHP script, maybe my old script can give you some pointers. I wrote that years ago when I wasn't very experienced in working with the PW API. So there sure is much room for improvement.