Arcturus

Probably a little late to be useful, but I ran into the same issue today, returned to this thread to semi-reverse engineer myself, and came up with the following: Change $value = preg_replace('/<span.*?>/i', '', $value, -1, $qty); to $value = preg_replace('/<span(?!.*?class=").*?>/i', '', $value, -1, $qty);

It would be nice to know if this was done intentionally, as the UI directly supported capital letters until only recently (3.0.200-210). These tags are used mostly as subheadings in the Admin UI, so I don't know why you wouldn't want them to support capitals.

...

Nearly bit off more than I could chew with that related Textformatter, but I have the following in place and working nicely with my CKEditor fields. Fair warning: the following is the franken-result of several hundred Stack Overflow queries. You may wish to shift your server to a explosion-proof container before testing. [the usual textformatter boilerplate leads into...] public function formatValue(Page $page, Field $field, &$value){ $value = preg_replace_callback('/href=\"(.*?)\"/', function($matches) use ($page) { $match = $matches[0]; if (strpos($match, '.pdf') !== false){ // Adjust your conditions accordingly $pieces = explode('/', $match); $match = 'href="/download/'.$page->id.'/'.end($pieces).'"'; } return $match; }, $value); }

Thanks Robin, I was able to confirm that the $config->fileContentTypes addition works, and is obviously an easier solution to implement for the problem I described originally. gebeer, the code I used is unchanged from what you wrote. I expected to have to manually handle the URL correction to use the proper prefix, but the functions related to pagefileSecure were firing after your code while continuing to respect your 'forceDownload' => false parameter. It looks like I won't have a chance to work on that textformatter until sometime next week. It's not necessary when using Robin's solution, but I kind of like the extra level of file location obfuscation that the download template provides.

Yeah, my links are already opening in a new tab. That's not the issue. The issue is that, when using pagefileSecure, files are being delivered to the browser from a ProcessWire process rather than a normal file request directly from the server. That's intended; however, browsers sometimes have issues interpreting files delivered by PHP, and that's often due to the headers used (Chrome might think it's being presented with a file it can't display, so it goes directly to a download dialog). I was hoping to not have to develop a downloader of my own to replace the user side of pagefileSecure, particularly for what should be such a basic use case, but looks like I'll need to attempt that. Thanks for the suggestions gebeer. Update: I figured that I was going to have make a number of additions to gebeer's code above, such as working in the pagefileSecure prefix and various header changes... but it worked right away, pretty much as is! No issues at all in Chrome or Edge. Sweet. I'm still going to have to come up with a textformatter for links that exist within CKEditor fields, and will circle back to this thread once I have that coded and working.

I'm using normal HTML text links to these PDFs. We're just looking to have them open in a browser tab, as is the general web norm, and not as an embed.

Hello, I'm developing a website where all files are only viewable to signed-in members, and I've used the pagefileSecure method to achieve that. The site's similar to a journal library, wherein the end of almost every use case is viewing a PDF file, and sometimes multiple PDF files. The problem I've run into is how various browsers handle PDFs loaded via the pagefileSecure method. Firefox loads the PDF in-browser without fanfare. Edge prompts the user to either view or download the file (neither great nor terrible). However, Chrome will not show the file in-browser at all. It will only download the file, and this presents a significant usability problem, particularly when this is the browser of choice for this site's audience. I suspect that there's a headers issue at work, but can't seem to see where I would even experiment with that hypothesis. My understanding was that pagefileSecure executes a simple redirect based on a user's permissions, but perhaps there's more to it than that? Has anyone found a solution to this? Interestingly, Chrome doesn't have this problem with protected JPEGs. Having to implement an alternative file protection scheme would be quite painful at this point.

Since it seems that all irregular pagination use roads lead to this thread, I just wanted to point out that the following enables pagination for a regular PHP array (all the other examples I saw are for PageFiles or PageImages-type arrays). My context of use here is a search results screen where I needed to dump a PageArray out to process additional ranking criteria, resulting in an array named $listings below. $items_per_page = 10; $start = ($input->pageNum - 1) * $items_per_page; $total = count($listings); $listed = array_slice($listings, $start, $items_per_page); // Key difference $a = new PageArray(); $a->setDuplicateChecking(false); foreach($listed as $listing) $a->add(new Page()); $a->setTotal($total); $a->setLimit($items_per_page); $a->setStart($start); echo $a->renderPager(); If you get a complaint about PageArray, it's likely because you haven't declared the ProcessWire namespace in your template.

I ran into the same errors as Marcel, but on CentOS7 with Plesk, hitting a wall at 128MB despite some very generous PHP settings. I was able to resolve the problem by making the following configuration changes within Plesk: Apache & nginx Settings > Maximum allowed HTTP request body size: 256MB ModSecurity > Custom Directives: Added "SecRequestBodyLimit 268435456" (without the quotes) My uploading test worked as soon as I restarted Apache.

Thanks for the module update, Robin! This is probably a minor issue, but I ran into a parade of errors with v0.1.4 and FormBuilder v.39 when I went to edit an existing field value after updating. In fairness, v.39 is quite old, and the errors disappeared after I updated to v.52. You may need to note a minimum version of FormBuilder in your module's requirements.

Has anyone figured out how to get custom styles working with this module (short of changing the mystyles.js file in /wire/modules/Inputfield/InputfieldCKEditor)? After line 55 InputfieldMarkupCKEditor.module: $cke->attr('baseHref', '/'); // Works $cke->attr('contentsCss', '/site/modules/InputfieldCKEditor/ckeditor.css'); // Works $cke->attr('stylesSet', 'ckstyles:/site/modules/InputfieldCKEditor/ckeditor.js'); // Does nothing :(

I ran into the following errors when switching from PHP version 7.3 to 7.4 with this module and ProcessWire 3.0.184 Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /home/build/public_html/site/modules/Recurme/MarkupRecurme.module on line 1082 (x2) Warning: Cannot modify header information - headers already sent by (output started at /home/build/public_html/site/modules/Recurme/MarkupRecurme.module:1082) in /home/build/public_html/wire/modules/Process/ProcessPageView.module on line 161 While this might be addressing the symptoms rather than the cause, I was able to restore full functionality by changing the first part of line 1082 from: private function i(){$this->v = false;} ... to private function i(){$this->v = true;} ... as suggested on a previous page, AND by also removing all of my license information (email and key) within the admin settings. There may be a more proper fix to the issue, but I wasn't willing to deconstruct that line's 1,691 characters of complexity to seek it out.

Has anyone been able to install any of the 2.x versions of Version Control with PW 3.0.165? I keep running into the following error:

Thanks Ghostrider! Your changes fixed our issues, without seeming to conflict with our own customizations.