BitPoet

It seems that I'll have to rename the module if I really decide to pursue developing it (which I doubt more and more). rtf.js unfortunately can't deal with the different dialects of RTF. I've removed the dependency and hacked together a pretty dirty regular expression that extracts image data from the RTF clipboard contents, then looks for img tags in the HTML contents and replaces the src for every found image with the extracted images in the same order. Whether that is practicable outside of my simple test cases is up for discussion. So far, the images always came in the same order in both formats. I'm currently only extracting PNG and JPG and insert a placeholder for others. I'm beginning to understand why TinyMCE's PowerPaste plugin is commercial.

Update after a little more testing: it seems that rtf.js is unable to parse the image data when I paste from LibreOffice Writer and drops it silently ? Pasting from MS Word works.

Since it came up in this question and I had some time to kill in front of my computer waiting for updates to finish which I had to verify, I got curios whether copy & paste from Word on Windows into a TinyMCE editor field could be made to insert the formatted text and keep the images. Surprisingly, with the help of rtf.js, this went pretty quickly. Ryan already built automatic upload functionality (called ImgUpload) into the TinyMCE field, so I only had to enable the option and select a target field. Even though pasting word processor generated HTML is and always has been a sin, I built a small module for it anyway. I called it (I know, it sounds a bit clunky, but it was the best I could come up with, I'm a backend guy): RtfPasterTinyMce Usage Download the contents of this repository and unpack into a folder in site/modules Open ProcessWre admin and select Modules -> Refresh Click "Install" for "Rtf Paster TinyMCE" Go to "Fields" and select your TinyMCE field where you want to paste office content including images Check "rtfpaster" in "Additional plugins" on the "Input" tab and save your field configuration Edit a page with that field and copy a passage that contains both text and images from MS Word into your TinyMCE field. You should see your images there. Advanced Go into InputfieldTinyMCE's module settings and enable "Image fields for ImgUpload" Edit your TinyMCE field and select an existing image field in the "Image fiels for ImgUpload" select on the Input tab Paste some text / images mixture from your word processor MS Word Tadaa! Your images are magically uploaded into the selected field. Since the RTF doesn't contain any information about the file name of the source image, your uploaded images will be named fieldname.png, fieldname-1.png, fieldname-2.png etc. Keep in mind that this is so far a proof-of-concept module and hasn't been tested with different scenarios and source applications yet. Don't use it in production unless you feel confident to fix any errors yourself! Edit: Only successfully tested with MS Word. Not working with LibreOffice's RTF.

I just played around and enabled the "Image fields for ImgUploads" in InputfieldTinyMCE's module settings. Then I selected an existing image field in the identically named select in my TinyMCE field's Input settings. Pasted from Word to my field and the image got uploaded without any further changes on my part!

Out of curiosity, I've created a small proof-of-concept module/plugin for InputfieldTinyMCE. If activated, it tries to fetch RTF clipboard content, parse that to HTML (with images as data: URLs) and insert the result, overriding TinyMCEs default paste behavior. I only did a small test so far. Maybe you'd like to do a test drive. https://github.com/BitPoet/RtfPasterTinyMce It uses https://github.com/tbluemel/rtf.js for the heavy lifting. Edit: forgot to say: this could of course be expanded to extract the image data, upload that to a dedicated image field through PW's standard upload endpoint and use the URL of the uploaded image in the inserted HTML.

Pasting from office applications is a complicated topic. The Windows clipboard can offer different formats of its contents to applications you paste to, e.g. plain text, HTML or image data, or different other data formats both the application you copy from and the receiving application have registered with the Windows system. In the case of copying from Word, your clipboard will look similar to this: The paste handler in the receiving application needs to be able to parse one of the provided formats. You'd think there's HTML in that list, so TinyMCE could simply paste that and all should be well - well, there's a caveat. Office tries to be nifty and conserve memory, so the HTML in the clipboard contains links to local files, which look like this in the source: <img width=224 height=237 src="file:///C:/Users/Someone/AppData/Local/Temp/msohtmlclip1/01/clip_image002.png" v:shapes="Grafik_x0020_1"> Into the game come security zones and same origin policy, and so no, file:///somewhere isn't going to make it into your inline editor. Safari on MacOS is a different kind of beast. The pasted HTML contains the images inlined as blob URIs, something similar but not completely interchangeable with data URIs. There's a plugin for TinyMCE that promises to be able to paste the full HTML with the images and even call an upload handler with the image data. No idea if that one parses the RTF version of the clipboard instead or does some other magic. But, OTOH, I really wouldn't want my users to paste formatted content from office apps. Been there, seen the disaster, and never want to go back there. It never plays well with surrounding HTML, it tends produce awful glitches when scaling things and in the end, the frustration on the users' side always far outweighs the initial convenience. In case you're curious about the things available in your Windows system's clipboard, you can take a peek with InsideClipboard (that's how I took the screenshot above).

Did you try hooking after ProcessPageView::finished? That's what LazyCron does. You may want to add a check for regular page views like LazyCron does here.

That shouldn't be a problem, actually. The WireHook class (someone correct me if I'm wrong) just builds a Selector and stores that in its hooks array. Every time a hookable method is called (through PHP's magic __call method), WireHook::runHooks is executed and checks wheter the any of the stored selectors match the currently called class and method and execute those. So it shouldn't matter when exactly you add the hook as long as PW's core has been loaded. For me, it's just a question of keeping the system startup lean why I perfer to add hooks in ready instead of init unless they have to be executed before ready() is triggered. In theory, it shouldn't matter, but I haven't delved too deeply into the issue.

Have a look at this thread:

Can you try the following ready.php snippet (can't test it myself right now): <?php wire()->addHookAfter('FieldtypeRepeater::wakeupValue', function(HookEvent $event) { $field = $event->arguments('field'); $page = $event->arguments('page'); // The return value of wakeupValue is a RepeaterPageArray or subclass of it $repPageArray = $event->return; if($field->hasContext($page)) { $field = $field->getContext($page); $repPageArray->setField($field); } });

Can you try disabling mutagen? Existing ddev issues point towards mutagen as the culprit.

Did you set the autoload property in your module? I've assembled a snippet for site/ready.php that should add a checkbox to InputfieldSelector to allow system templates since the setting itself is already part of the inputfield code. Untested though since I'm in the middle of a big cleanup of my dev environment. wire()->addHookAfter('InputfieldSelector::getConfigInputfields', function (HookEvent $event) { $fields = $event->return; $inputfield = $event->object; $f = $event->modules->get('InputfieldCheckbox'); $f->attr('id+name', 'allowSystemTemplates'); $f->label = $event->_('Allow system templates'); $f->setAttribute('checked', $inputfield->getSetting('allowSystemTemplates') ? 'checked' : ''); $fields->append($f); $event->return = $fields; });

My personal believe is that ProcessWire would be the perfect platform for what you want to do, but you won't be able to completely circumvent a PHP learning curve. Since I don't know any platform or toolkit on the market that provides all the features you want without some programming (and the trend goes towards dropping pre-built solutions and requiring more programming, even with the "big players" like Sharepoint or Typo3), it's probably just a question of picking your poison. I'll try to answer your points as good as I can, though others with more experience with the specific requirement may have even better ideas. 1. Member login is possible with the free FrontendUser module. 2. Donations could e.g. be achieved with Stripe (Patreon, from what I hear, is cutting down on its APIs and trying to monetarize things to a point of pain). There's a stripe payment processor that's part of the commercial FormBuilder module. 3. Taxonomy is an integral part of PW. Tagging, either with plain text tags or pages (the later even created on demand when you add a tag or relationship item) can easily be achieved out of the box, and there are free modules for things like creating two-way relationships between pages. PW's philosophy that "everything is a page" may sound a bit scary at first if you've worked with CMSes like WP or Drupal, but in the most simple case, a page is just a title field and auto-generated name living somewhere in the page tree. 4. You actively have to implement (yourself or with a module) the blog behavior. If you want it, it's pretty simple with PW's built-in selectors and pagination. 5. Really easy to implement. Add a "featured" checkbox to the templates that are relevant, call $pages->findOne('features=1, sort=-created') to your home template and render the returned page. 6. This is easy too. Yes, it too requires small bits of PHP, but most of it is still CSS and JS. Just a small step up from a static HTML page. 7. Again, FormBuilder might be a good choice here. There are a few more options out there as well, and you'll certainly get good responses here if you inquire with a specific example or use case. 8. Rendering an RSS feed is possible (though I haven't used those in a long time) with free modules, it just needs a tiny bit of (well documented) programming. 9. Just add PW's core Markdown Textformatter or (if you want to mix Markdown and HTML) install and add TextformatterMarkdownInMarkup in the field's configuration, and it will convert the markdown when the contents are shown in the frontend. One thing I'd like to add: you'll certainly not find a CMS with a more friendly and helpful community than PW.

It's assigned to Textarea fields that contain HTML, and it just modifies the output. The img tags stay unchanged in the database, and the images themselves aren't changed at all. If you want to retrive the data URI programmatically, that would have to be implemented with a hook. The code for the conversion itself is pretty straight forward (untested): <?php // This can be accessed as $image->dataURI wire()->addHookProperty('Pageimage::dataURI', function(HookEvent $event) { $pageimage = $event->object; $fullpath = $pageimage->filename; // Check if image is larger than a certain size, in which case we return the regular image url: if(filesize($fullpath) > 16384) { return $pageimage->url; } $mime = mime_content_type($fullpath); $dataUri = "data:$mime;base64," . base64_encode(file_get_contents($fullpath)); return $dataUri; }); If you actually want the data URI stored in the database, you could add a custom field to the image field and fill it in a saveReady hook.

It's not likely to change without the developer consciously doing so, but $config->http404PageID is much more expressive than "27" anyway.

The symptoms all point towards ProcessWireUpgrade. It does have a login hook for checking available updates, after all. I'd first check outgoing HTTP(S) connections and, if those work and are performant, possible DNS lookup hickups on the server. The message about SchedulePages is normal, as it's not listed in the module repository.

It's the page of the hosting company where the (not linked) PW driven site runs. Strato is one of the oldest and biggest European hosters.

Ah, sorry, I missed a hint in your screenshot. The module won't do anything applied to the file descriptions. You need to add the Textformatter to the textarea field that uses the images.

Hi @Leftfield, I'm not sure what the reason could be, so I've added logging to the dev branch of the module. You can download it here. With debug mode on, it logs to "imgdatauri".

Three possible solutions: Add a whitespace after the closing PHP tag Add an empty line after the closing PHP tag Output a real line break. In your example, you're putting a literal \n in the source, outside of PHP. Use <?= "\n" ?> instead.

You need to expand the parent select and navigate to the assigned parent. When you hover on that, you should see the "unselect" button.

You can use https://processwire.com/modules/fieldtype-runtime-markup/ for that.

Can you try the latest release (0.2.0) and let me know if that fixed the issue?

Published to GitHub and pending approval in the module directory.

Here's a small module I wrote a few years ago and was asked to share in the module repo. TextformatterImgDataUri This Textformatter checks all images in the field's markup for images under a certain size and converts those from links to data URLs, i.e. it embeds the image data itself. This can be handy when you cache whole pages and want to cut down on the number of requests. Original post with the module code: