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.

Speaking of strange behaviours... despite not having changed a single thing with our Recurme installation since early January, it's now returning EXCLUDED DATES with both $recurme->find and $recurme->renderCalendar for any month that's shorter than 31 days. I have no idea why. The Recurme debug report shows no anomalies between months. This issue would have been very noticed for us had it been present in February, and the events that are broken now are the ones we used to build and validate the system. Check your sites. It may have triggered following the leap year date and was difficult to notice since March was not affected. My event pages (luckily) bypass the Recurme module to work directly with the page-related JSON-entry in the database, so no issues there. Others may not be so lucky.

During a recent maintenance routine we found that our website's database (1,700+ pages) had thousands of instances of unnecessary, garbage code that had come with copied text from Word. Passages with margins expressed in points, cms and inches, and some that were wrapped in upwards of 7 spans were among the most easily identified crimes. Purging all of this dropped our database size by over 4%. A few of the code examples above nuke all inline styles, which will impact some important out-of-the-box functionality for PW3 and CkEditor (depending on your use); specifically with many of the options with tables and lists, such as setting a column width or changing the bullet styles within a nested list. To work around that, I made some changes to Ryan's code to target specific tags and to eliminate spans (which you can only add via Source view without pasting them in). $wire->addHookAfter('InputfieldCKEditor::processInput', function($event) { $inputfield = $event->object; $value = $inputfield->attr('value'); if ((strpos($value, 'style=') === false) && (strpos($value, '<span>') === false)) return; $count = 0; $qty = 0; // Optional remove spans $value = preg_replace('/<span.*?>/i', '', $value, -1, $qty); $value = preg_replace('/<\/span.*?>/i', '', $value, -1); $count = $count + $qty; // Remove inline styles from specified tags $tags = array('p','h2','h3','h4','li'); foreach ($tags as $tag){ $value = preg_replace('/(<'.$tag.'[^>]*) style=("[^"]+"|\'[^\']+\')([^>]*>)/i', '$1$3', $value, -1, $qty); $count = $count + $qty; } if(!$count) return; $inputfield->attr('value', $value); $inputfield->trackChange('value'); $inputfield->warning("Stripped $count style attribute(s) from field $inputfield->name"); });

...

If you've customized the CSS for the content within your regular CKEditor fields, you can bring that styling over to this module by adding the following to InputfieldMarkupCKEditor.module around line 51. $f->attr('baseHref', '/'); $f->attr('contentsCss', '/site/modules/InputfieldCKEditor/ckeditor.css');

We purchased the module in August and have run into some issues now that we've had a chance to implement it. Code > $event = $recurme->event($page); Result > Notice: Undefined property: stdClass::$timeEndUnix in .../site/modules/Recurme/MarkupRecurme.module on line 856 Robin raised this issue earlier in this thread and, if a solution was found, it wasn't shared or implemented in the downloads. Update 12/13/2019 Replacing $timeEndUnix = $data->timeEndUnix; With if(isset($data->timeEndUnix)){ $timeEndUnix = $data->timeEndUnix; } else { $timeEndUnix = false; } Removes the error, but I suspect that I was trying to use the method in the wrong way/context given a misunderstanding of the documentation. I'm having to use the JSON decode method (example: $times = json_decode($page->event_times)), with a lot of template-level processing, to populate my event detail pages. Is that the best way? [/End Update] itsberni and others have asked about handling time variance for a recurring event, which strikes me as a rather essential feature. Has anyone found a solution or workaround for this? I suspect that adding a second recurme field to an event page will lead to a lot of pain elsewhere (but I could be wrong), and cloning an event's page to support another time would require me to implement measures to connect the clones (doable, but sloppy from both an admin and user standpoint). A couple of items which may help others: The "Repeat Never" switch does nothing for me out of the box (other than hiding the rest of the options) as every single-day event I entered was automatically being assigned a default value of End Never and repeating 2,800 days. I had to hack both the rrule-gui.js and InputfieldRecurme.module files to default to After 1 Time(s) to rectify this issue. Commenting out -- results.find('.inner').scrollTop(0); -- in rrule-gui.js, around line 1153, will save a lot frustration for anyone needing to exclude multiple dates from a results table.

Thankfully I was able to resolve my own issues here. I'm not sure what went wrong with my initial setup on the development server, but I purged the /site/ side and database, and re-started the migration and CKEditor no longer logs me out of the site. With that resolved, I was quickly able to exonerate Jumplinks and Page Protector of any blame for the http links issue. After some more investigating, I began testing parts of my .htaccess file and quickly found the source of the matter. ... RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http%3A%2F%2F [OR] ... RewriteRule ^(.*)$ - [F,L] The condition comes from a set of rules used to block MySQL injections and other forms of query-based attack, and it was unfortunately interfering with how ProcessWire transitions from the CKEditor to its link editing modules. Simply commenting that line out (with a # at the start) fixed the issue on both servers.

On our production site (v3.0.123): We're just about to launch a new website and have had the bizarre issue develop in the past week where editing any existing http-based link (either via the right-click or toolbar within a CKEditor field) is loading a 404 error page within the link editing modal. Meanwhile, editing an https, tel, or mailto protocol link loads the editor without issue. Isolating the 404 frame within the modal shows the URL below. If I manually add an 's' to that address, the editor loads. https://[domain]/edit/page/link/?id=2481&modal=1&href=http%3A%2F%2Fwww.crhc.ca%2F&class=ctalink - 404 https://[domain]/edit/page/link/?id=2481&modal=1&href=https%3A%2F%2Fwww.crhc.ca%2F&class=ctalink - Loads Other than the 404 screen, there's no other error message appearing within the admin or the browser console. The only recent changes we made to the site's configuration were the additions of the Jumplinks and Page Protector modules, although I believe the issue was present prior to their installation. Because I need both of those modules for a fast approaching launch day, I've created a complete 100% copy of the site to explore rolling things back. However,... On our development site (v3.0.123 - same server, same environment settings, separate user account): For whatever reason, accessing any admin page with a CKEditor field on this site immediately logs the user out of ProcessWire. You can view the editor page, and all the content loads (although I can't open repeaters), but any action returns the login screen. Everything else on the backend and frontend of the copy is working as expected. Again, there's no other error message appearing within the admin or the browser console. Any idea on what may be causing either issue, or what I could do to better diagnose them? Debug is set to true on both sites and it's not a browser issue (tested Chrome, Firefox and Opera).

If anyone was wondering, this module seems to work fine with the CroppableImage3 fieldtype.

This may help others. You're going to get labels for this field's output that you probably won't need (no fault of this module). This CSS .InputfieldMarkupCKEditor .InputfieldHeader { display: none; } will hide them visually, while this JavaScript function (function () { var labels = document.querySelectorAll('.InputfieldMarkupCKEditor .InputfieldHeader'); for (var i=0; i < labels.length; i++) { labels[i].setAttribute('aria-hidden', 'true'); } })(); will hide them from screen readers.

Thanks for this module, Robin. Note that the download link on the module page is broken.