Leaderboard
Popular Content
Showing content with the highest reputation on 02/22/2020 in all areas
-
Plenty of posts on the forum relating to Content Security Policy (CSP) and how to integrate it with Processwire. It's not too hard to implement a decent htaccess CSP that will get you a solid B+ at Mozilla Observatory. If you're after A+ it's a little harder because of all the back-end stuff... until you realize it's surprisingly easy. After a lot of testing, the easiest way I found was to specify only what is needed in the htaccess and then add your required CSP as a meta in your page template. Plenty of people have suggested similar. Works very easily for back-end vs front-end, but gets complicated if you want front page editing. Luckily, a little php will preserve back-end and front page editing capabilities while allowing you to lock down the site for anyone not logged in. None of this is rocket science, but CSPs are a bit of a pain the rear, so the easier the better, I reckon ? The only CSP I'd suggest you include in your site htaccess is: Header set Content-Security-Policy "frame-ancestors 'self'" The reason for this is you can't set "frame-ancestors" via meta tags. In addition, you can only make your CSP more restrictive using meta tags, not less, so leaving the back-end free is a solid plan to avoid frustration. Then in your public front-facing page template/s, add your desired Content Security Policy as a meta tag. Please note: your CSP should be the first meta tag after your <head>. For example: <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no"> If you haven't got Front Page Editing enabled, this works fine by itself. Just one extra step is needed to make sure you don't have to worry either way. The easiest way I found to allow both CSP and front page editing capabilities is the addition of a little php, according to whatever your needs are. Basically, if the user is a guest, throw in your CSP, if they're not do nothing. It's so simple I could have kicked myself when it finally dawned on me. I wish it had clicked for me earlier in my testing, but it didn't so I'm here to try to save some other person a little time. Example: <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <?php endif; ?> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no"> If you want it a bit more involved then you can add additional tests and be as specific as you like about what pages should get which CSP. For example, the following is what I use to expand the scope of the CSP only for my "map" page: <?php $loadMap = $page->name === "map"; ?> <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; base-uri 'self'; manifest-src 'self'; form-action 'self'; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; img-src 'self' data:<?php echo ($loadMap) ? " https://maps.googleapis.com https://maps.gstatic.com" : ""; ?> https://www.google-analytics.com; script-src 'self' <?php echo ($loadMap) ? "https://maps.googleapis.com " : ""; ?>https://www.google-analytics.com https://www.googletagmanager.com; style-src 'self' <?php echo ($loadMap) ? "'unsafe-inline' https://fonts.googleapis.com" : ""; ?>"> <?php endif; ?> Hope this saves someone a little time testing. https://observatory.mozilla.org/analyze/bene.net.au12 points
-
This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/8 points
-
Python has one big advantage over PHP, which people might or might not care about: It‘s widely used for devops tooling because it‘s preinstalled on so many systems and it‘s growing super fast in the space of ML/AI/Science based computing because of it‘s bindings to fast low level C code while still writing python on top. If you care about those things or you want to do them as well, but not introduce a mix of technology, then sure python is a great solution. If not I don‘t see any reason to switch from whatever one is using right now.4 points
-
I've kept hearing that one for the last twenty years, yet here we are. I think that's enough said ?4 points
-
While I agree that securing the superuser account with 2FA — and, preferably, not creating multiple of such accounts — is a very good idea, you can still make sure that even if a superuser account is compromised, it won't provide anyone with any more than the necessary capabilities on the host system. Don't allow PHP to write into directories where executable code is stored; most importantly index/config/htaccess files, /site/modules/, /site/templates/, and /wire/. This means that a) module installs via ProcessWire GUI are out of the question, and b) at least in production you can't use modules that allow authoring or executing code via a GUI. Technically File Compiler also writes executable code, but it's a bit different (and can usually be disabled as well). I wouldn't worry about it too much. While ProcessWire used to allow storing custom code in Page reference field settings, that's no longer the case (hooks are used instead). As such, at the moment I can't think of any core feature that would allow superusers to access the underlying system once aforementioned precautions are taken — so after this it's essentially about only installing modules you know and trust ? Finally — and this is not a ProcessWire thing per se — make sure that the system itself is secure, and that whatever user Apache is running as doesn't have access to anything it doesn't need access to. Also: try not to store anything that doesn't need to be public under a publicly (web)accessible directory, whether or not there's .htaccess protection in place. I won't go into server side security here, but there's a truckload of stuff you can do there both to avoid user accounts being compromised, and to limit the impact of compromised accounts. For an example you can make it so that even if someone does gain shell access through the site, they won't have access to the whole server (this is always the case in shared hosting, at least if the host has any idea whatsoever of what they're doing). Often it all boils down to how hardcore you want to get with this stuff, really ?4 points
-
I usually supplied "translation keys" instead of the default translation to translation functions, and translated them in all languages, eg. __('btn_submit') instead of __('Submit'). This way they rarely needed to be changed, only when the translation changed to something completely different.4 points
-
Exactly what BitPoet said. Over the years I've heard over and over again how PHP is a dead/dying language, and how the future is all about [insert any imaginable language here]. If anything, I've learned not to care: PHP has been around for a long time, and to date it's still a lively project with a massive ecosystem. When I started with PHP 4 (or 3 — can't remember for sure) back in the days, it was a whole different language, really. 5.x made it a viable object-oriented language, 7.x brought in massive improvements in terms of features and performance, and 8 looks like it's going to be a blast as well. So yeah, I don't see any reason to jump the ship at this point; if anything, I'm pretty sure that PHP will have a lot more to offer in the future ?3 points
-
In an ongoing effort to provide a sort of case study, and more info about this, I'll post random screens and info about the various features of this site. (1) Custom Dashboards The site uses a custom module that supports multiple dashboards. Any given dashboard is configurable and access controlled also. This is the main dashboard: (2) The admin editor pages take advantage of some great modules, namely RuntimeMarkup @kongondo, PageFieldInfo @Robin S, Field Descriptions Extended and more, There is also a new module not released yet called Admin Comments, which for this project got a lot of use. When dealing with a large and complex data collection as was the case with this project, the editors benefited from the ability to have the data auto-analyzed on each work so the "auto flags" field helped with that. The comments also allowed editors to post information, ideas and comments right into the page editor. The AdminComments module also provides the option for any posted comment to be emailed to the other team members (selectable), and the notification email (which is customizable) allows the recipient to click directly to the editor for that page. This saved incalculable hours of work, and enhanced communication during the project, across this large data set.
3 points -
This is an update about how it's been running blog sites using ProcessWire. I hope it's OK for me to post in this category even though I've already showcased my sites awhile back. I thought it would be helpful for people to get a feel for what it's like to use ProcessWire on an ongoing basis for blogging. Often people talk about the development of a site, but it's not quite as often that we hear about the ongoing running of a PW site and how the PW API influences that, which is what I'll cover here. As background, we at The GrayFly Group own and run the blogs goodkidsclothes.com and flipfall.com. The development of these PW sites has been covered in a showcase thread for GoodKidsClothes and another for FlipFall. Here are some of the unique experiences I've had running these two sites. "Running" covers everything from coding and making modifications to the templates, to writing our articles, to interacting with ad partners or with others seeking us out for something related to one of those sites. So this is a different experience from agencies who develop for others; we develop for ourselves. As background, the main traffic to the websites comes from organic search results. Income from sites is from affiliate marketing and advertisements. GoodKidsClothes PW experience: "to think it is to do it." For GoodKidsClothes.com, one of the things we noticed was that if we could think it, we could do it, thanks to the easy-to-use PW API. The need for a change Here is a concrete example of what I mean: we noticed that many people would enter the site on an older article (e.g. via a search result). However, we continually put out a lot of time-sensitive information, e.g. a style guide, a piece of news relating to a change in a children's clothing company, etc. I didn't want people to miss out on this, yet many were, because after reading their entry page, they'd leave. They had no idea (unless they clicked on the link to home page) that there was another article that could be of value to them. All too often, by the time people learned about that new article via search results, they'd be too late for the news to be relevant - in fact, it wouldn't even be the newest article anymore by that point. The solution So, using the PW API, we modified the article template so that if someone was reading any article that was not the most recent article, then at the end of what they're reading, they'd see a small section highlighting the most recent article. Here is a screenshot: As you can see above, our newest article is highlighted immediately below the article they're reading, unless of course they are already reading the newest article. In the case shown above, the newest article (recipe-related) did not happen to be time-sensitive, but in most cases that article would be time-sensitive, so that's why we made this change. To make the change we simply used the PW API to query what the latest article was and store its identity in a variable - those sorts of queries we set up in _init.php. Then we modified the article template such that if the current page was not the latest article, to include the featured box that you see above. Another need for a change You'll also notice links in boxes above and below where the featured article box is. These are ads (they blend OK right?!) These ads brought another problem to our attention: we'd put the ads blocks on all articles equally. However, in the case of the most recent article, often the most recent article would usually have a time-sensitive offer or some other call to action e.g. signing up for our newsletter (well, not in the case of the recipe article above, but in most cases the latest article would have something we prefer the reader to do). We didn't then want our readers to get distracted by the ads and either leave the site, or click on an ad and click away from the site, instead of doing whatever the call to action is. The solution Again using the ProcessWire API, we modified the "article" template so that there was conditional logic on the ads: if the current page is not the latest article, include the ad code (otherwise no ads). This mean no ads were seen on the most recent article, allowing for less distractions to the reader on time-sensitive articles and more likelihood of them following through on the call to action. Conclusion for GoodKidsClothes We were able to make all these changes within minutes of thinking of them! In-house, without a ton of knowledge of programming, thanks to the awesome ProcessWire API. We actually made all those changes live, i.e. going in there and making changes to the code of the site as its running live. Yes, we had backups of the entire site and we always first save a copy of the template file under a different name (usually prefixing it with OLD_ ) before modifying the live version. This is how helpful ProcessWire is. We can make changes that benefit our site and make them in-house as we think of them. If this was done under some other CMS, we would be unable to make those changes without either a) hiring a developer or b) training up in whatever the other CMS is to make the changes in-house. Either way, it would take considerably more time to do anything. So, despite not having a formal programming background, we now have a very "nimble" site that we can adapt as needed to changes that we desire, within minutes of thinking of the change we need, with only needing to know a little PHP, html, and CSS, just the very basics, and looking up the PW API. FlipFall PW experience: "the answer is yes." In the case of FlipFall, there have been times when a potential ad partner asks a question like "can you put different ads on different categories?" or other things. Sometimes they are questions I ask myself of the website "Can we do A/B testing of different ads; i.e. show a certain ad block 50% of the time totally randomly and another ad block the other 50% of the time?" "How about ads from this company some of the time and a different company other times?" The answer is always "yes." Coming from other CMS's (that I used but did not program with) I used to brace myself a bit if I saw an email that asked "Can you....?" but now thanks to ProcessWire I don't have that bracing reaction any more. So long as I can think of a way to do it (and so far I always have, thanks to the PW API), I can say "Yes we can." More to the point, I can actually say "Yes, we can make those changes in-house within [whatever brief timeframe I think it will be]" instead of having to be vague about timeframes because of needing a developer. So I no longer worry about "Can you ...?" questions because the answer is yes. Overall conclusions ProcessWire is a superb CMS for those who own and run a site. The PW API makes it easy to make changes to the look and functionality of the site as needed. Such modifications wouldn't easily be possible on alternative CMS's that are heavily "theme-based".
2 points
-
I had to do several page imports via Tracy Console today, so I had the challenge of populating the Daterange field easily via the API... I added support for basic daterange parsing from a given string: RockDaterange("22.02.2020") hasTime => false hasEnd => false fromH => "22.02.2020 00:00" (16) toH => "22.02.2020 23:59" (16) RockDaterange("22.02.2020 17:00 - 19:00") hasTime => true hasEnd => true fromH => "22.02.2020 17:00" (16) toH => "22.02.2020 19:00" (16) RockDaterange("22.02.2020 17:00 - 20-3-1 19:00") hasTime => true hasEnd => true fromH => "22.02.2020 17:00" (16) toH => "01.03.2020 19:00" (16) And it get's even better! This makes it possible to use $page->setAndSave() easily using string dateranges: $page->setAndSave('range', "2020-02-22"); // single full-day event $page->setAndSave('range', "2020-02-22 18:00"); // single day event with time $page->setAndSave('range', "2020-02-22 18:00 - 22:00"); // single day event with time range $page->setAndSave('range', "2020-02-22 - 2020-02-24"); // 3-day event (full-day) $page->setAndSave('range', "2020-02-22 06:00 - 2020-02-24 23:00"); // 3-day event with times You wonder how complicated that was to implement?! Once the parsing part was done it was nothing more than adding this one line to the sleepValue method of the fieldtype. How genius is ProcessWire?? ? public function sleepValue($page, $field, $value) { if(is_string($value)) $value = new RockDaterange($value); ... --- This is how I did the recurring events so far ? Got an excel from the client with page id of the master event and date + time of the recurring events. Using VSCode and multicursor I transferred this into a script to create pages: The save() call at the end of each line would not be necessary but triggers a hook that renames the page and adds the daterange to the URL. This prevents ugly urls like this /event-x /event-x-1 /event-x-1-1 /event-x-1-1-1 And creates URLs like this instead: /event-x-01.01.2020 /event-x-01.02.2020 /event-x-01.03.2020 /event-x-01.04.2020 There's a lot one has to think of when dealing with events ? I wonder if a "add daterange to URL" feature would make sense if a daterange field is present on a template... Would have to be optional of course.2 points
-
Just a heads up, I hope this might save someone some time in the future. TL:DR> It's taken me hours to work out that Apache version 2.4 <If> statements are broken when trying to do regular expression matches against the %REQUEST_URI variable. Try matching against the variable called %THE_REQUEST instead - but be careful with your regex. Background: I've been trying to add more relaxed CSP headers for the admin portion of one of my PW sites because my default, strict, CSP headers stop some admin features from working properly. After diving in to Apache2 regexs and conditionals, I thought I had the answer with this... <If "%{REQUEST_URI} !~ m#^/admin/?#i"> # CSP headers for external visitors. Header set Content-Security-Policy "<strict policy for public site>" </If> <Else> # CSP headers for admin visitors. Header set Content-Security-Policy "<lax policy for admin>" </Else> ...but I couldn't make it work. After experimenting for several hours I found that the regex shown above does work if you limit it to a single-character match; which is essentially useless for determining if we are in the admin interface. However, you can achieve a useful match with the following... <If "%{THE_REQUEST} !~ m# /admin/?#i"> ... </If> <Else> ... </Else> ...which checks verses the entire HTTP request line made to the server. This block can go in your vhosts file or in the site's .htaccess file. Here's the Apache documentation: https://httpd.apache.org/docs/current/expr.html and it seems I'm not alone in having this issue: https://serverfault.com/questions/940953/apache-if-statement-not-working?noredirect=1&lq=1 although neither of these links had workable solutions for me.2 points
-
@MarkE - The events just have a page field multiple where you select the works being performed. Some events come in through Boosey and those have a reference ID we store so those are auto assigned. Works pages just have a section that searches for upcoming events and outputs them. But there are a ton of other ways that works are connected to each other, using versions, members and custom taxonomies that focus the relationships that are specified...1 point
-
Maybe a directory traversal attack (to install backdoors or whatnot). I would immediately contact the hosting company, and also check for suspicious files. Lock down your forms, or any other potential areas that allow user-input.1 point
-
I used this code on my site as well and added uppy meta information for setting the page id where the files will be uploaded. Here is the code if you are also looking how to do this: <script src="https://transloadit.edgly.net/releases/uppy/v1.9.2/uppy.min.js"></script> <script> const uppy = Uppy.Core({debug: true, autoProceed: false, meta: { pageid: 1488 } }) .use(Uppy.Dashboard, {target: '#uppy-box', inline: true}) .use(Uppy.Tus, {endpoint: 'MYURL/uppy/', limit:10}); </script> $td = $files->tempDir('uppy'); // CMS $td_path = (string) $td; // Create TusPhp server $server = new \TusPhp\Tus\Server(); // Set path to endpoint - no trailing slash here $server->setApiPath('/uppy'); // Set upload directory $server->setUploadDir($td_path); // Listener function for when an upload is completed $server->event()->addListener('tus-server.upload.complete', function(\TusPhp\Events\TusEvent $event) { $file_path = $event->getFile()->getFilePath(); p = wire('pages')->get(intval($event->getFile()->details()['metadata']['pageid'])); // extract page id from uppy metadata $p->of(false); // CMS related $p->files->add($file_path); //CMS related $p->save('files'); //CMS related }); // Send response $response = $server->serve(); $response->send(); exit(0);1 point
-
Let's say some bad guy steals my ProcessWire admin account password (by reading it off the post-it note I so conveniently have on my screen). Obviously, they have full control of my site now and can do whatever they please. That can not be prevented in this scenario. But on many ProcessWire installations, I think the attacker could also gain control of the server, e.g. by installing a PHP shell. That could probably be prevented somehow. My goal is to lock down things so that an admin user can not insert any PHP to the site. What would I need to do to achive that? I can think of a few things: Disable module install/upload/download. I guess the hanna code module must be uninstalled? Anything more? Any other modules or settings to look out for? I understand that features like one click module install are very useful, so this is not a critique against ProcessWire - it's the best CMS I have ever used. I am just interested how I can be a bit extra cautious. Also, I understand that it is best to just never lose your admin password, but I think defence in depth is a good thing.1 point
-
It depends on your usecase, but a very simple solution could be to prevent login of superusers for the live system: // site/ready.php $wire->addHookAfter('Session::allowLogin', function(HookEvent $event) { $liveHost = "my.live.site"; if($this->config->httpHost != $liveHost) return; if($event->arguments(1)->isSuperuser()) $event->return = false; });1 point
-
You are right; whilst it is possible to get a vhost/.htaccess-based A+ on security headers while keeping the admin interface fully operational, it is a pain and leaves the apache config files in a bit of a mess. Getting the admin interface sorted in the vhosts file prompted this post over in dev-talk that might also help someone out if they go down that route. What you've posted seems to be a fairly nice approach to the issue - thanks!1 point
-
Sorry, didn't fully read your post (re: SVG) - pls ignore this post.1 point
-
Personally I‘d first look into using an existing solution for gathering the data (I‘ve had good experience with https://feed2go.com/de/) and just create a way to bring back data into existing systems later. Webapps have the problem that their storage while available at times is not ensured to stick around. If e.g. the device disk space runs low it might be cleared out. Also you‘re already in the realms of a fully client side app, so you could just embrace it.1 point
-
Another update - RockPdf now supports FontAwesome 5 in mPDF library ?? This works using webfonts (after I've unsuccessfully tried with SVG) and it supports resizing and coloring icons via CSS or LESS (wich didn't work when using SVG). I've updated the readme: Using FontAwesome 5 with mPDF Download a copy of fontawesome (https://fontawesome.com/download, eg Free for Web) Copy the TTF file into your /site/assets/RockPdf/fonts/ folder Add your font to your settings and start using icons in your PDFs // tracy console $pdf = $modules->get('RockPdf'); $pdf->settings([ 'fontdata' => (new \Mpdf\Config\FontVariables())->getDefaults()['fontdata'] + [ "far" => [ 'R' => "fa-regular-400.ttf", 'I' => "fa-regular-400.ttf", ], ], ]); $icon = "<i style='font-family: far;'></i> "; $pdf->write($icon.'Hello World ' . date('H:i:s')); d($pdf->save()); You'll notice that we used the unicode representation of the icon. You can find all the codes on the cheatsheet (https://fontawesome.com/cheatsheet) or on the details page of the icon: https://fontawesome.com/icons/smile?style=regular Be careful to use the correct style (regular, solid, etc) and unicode! Special thx to jamesfairhurst Using metadata to get the unicode Too complicated? RockPdf comes with a helper so that you do not need to take care of all this and just use the regular fontawesome classes that you might already be familiar with! To make that work, just copy the icons.json file that is shipped with fontawesome in the metadata folder into the RockPdf assets folder /site/assets/RockPdf/fonts. // tracy console $pdf = $modules->get('RockPdf'); $pdf->settings([ 'fontdata' => (new \Mpdf\Config\FontVariables())->getDefaults()['fontdata'] + [ "far" => [ 'R' => "fa-regular-400.ttf", 'I' => "fa-regular-400.ttf", ], ], ]); $pdf->write("<style>.far { font-family: far; color: blue; }</style>"); $icon = $pdf->icon('far fa-smile'); $pdf->write($icon.'Hello World ' . date('H:i:s')); d($pdf->html()); // print content to console $pdf->save(); // save file to file system Using this technique you can easily style your icons using CSS or even LESS (when using RockLESS). Another example Unfortunately duotone icons do not work (if you know how to make them work please drop me a line!). Also styling the icons is sometimes a bit tricky - some CSS selectors work while others don't. Using classes directly on the icon worked best for me: $icons = $pdf->icon('fas fa-guitar red-2x') .$pdf->icon('far fa-guitar red-2x') .$pdf->icon('fal fa-guitar red-2x') .$pdf->icon('fad fa-guitar red-2x'); .fab { font-family: fab; } .fad { font-family: fad; } .fal { font-family: fal; } .far { font-family: far; } .fas { font-family: fas; } .red-2x { font-size: 10mm; color: red; } v2.0.11 point
-
I've dabbled a bit and adapted my cache module to work with Redis (working mostly on Windows, this was a bit of an adventure, but Windows Subsystem For Linux saved the day). CacheRedis - a simple Redis cache interface for ProcessWire There should be enough documentation to get started in the README. In short, it has the following methods: $redis->fetch($key[, $expire, $func]) $redis->store($key, $expire, $value) $redis->delete($key) $redis->flush() $redis->renderFile($file[, $expire[, $options]])1 point
-
In production mode, I have no need for functionality that lets admin modify PHP code. From a security perspective it is usually good to disable things you don't need. However, in this case there doesn't seem to be a trivial off button, so perhaps it is not worth the hassle.1 point
-
If someone has your superuser password, it hardly matters whether they have Tracy installed or not - they can just go install it, because they have superuser permissions ? Sure, you could lock down /site/modules/ permissions so that PW can't install modules (meaning you would need to install them all via FTP / Git / etc rather than via the web interface. But I have to ask - surely if you're worried about someone getting access to your superuser account, aren't you just as worried about them getting your FTP access details? You could lock down FTP via SSH security keys which would take care of that. Regarding locking down superuser access, you could always install PW's 2FA system - that's probably the safest approach to protect things.1 point
-
Just updated all the dependencies of this module to the newest versions: Package operations: 0 installs, 4 updates, 0 removals - Updating myclabs/deep-copy (1.7.0 => 1.9.5): Downloading (100%) - Updating paragonie/random_compat (v2.0.12 => v9.99.99): Downloading (100%) - Updating psr/log (1.0.2 => 1.1.2): Downloading (100%) - Updating mpdf/mpdf (v7.1.0 => v7.1.9): Downloading (100%) v1.0.21 point
-
What I know has been pieced together from official docs and discovered through trial and error, so I can't provide a good link there. However, I've pushed a few pieces into a small module based on Memache that can be a (partial) stand in for WireCache as an example. You can find it on github as PwMemcache. It has just a few methods to set/get/delete cache entries and doesn't allow saving and restoring of full pages like WireCache does, but it does have a renderFile method similar to WireCache. Maybe that could be a starting point. Most of the magic in using memory caches is using well thought out cache keys to avoid conflicting names (you're likely to use them more intensively than database caching) using reasonable expiry values (same as with database caches) preventing outdated data (e.g. by deleting entries when pages are changed, there's little 'automatic magic' there) taking care of special considerations when data is serialized and later unserialized, since behavior differs between solutions How exactly that best goes depends on the features of the caching solution. Unlike WireCache, many in-memory solutions have no wildcard deletion operators, so you sometimes have to build workarounds. My module for example does this when you pass PwMemcache::expireSave to the renderFile method. The cache contains an extra array where all the entries are stored that have to be cleared when a page is saved. In a Pages::saved hook, this entry is read, all cache entries listed in the array are deleted and the entry is emptied.1 point
-
Hi guys, I was very excited for this module, but my life took a huge direction change and I no longer have the time to invest in module development. I am gonna leave the files here. You guys can take it and run. Maybe there might be something useful here. Maybe not. I still think it's a good idea to do drag and drop modal building in PW. So hopefully one day something like that can come to light. I love this community and I love ProcessWire. Live long and prosper. - Joshua Designme 2.zip1 point
-
Hey Kei, Have you tried the skyscrapers profile by @dadish that can be found here. With a clean install of processwire, you can drop the profile in and proceed like you are setting up a new instance with the profile selected.1 point
-
Good thing I marked this as a beta release, because I'm still finding a lot of bugs ? I just pushed version 0.4.0. The module is now no longer autoloaded, because it's not really required anymore. This release splits the module into two seperate Modules: ProcessCacheControl and CacheControlTools. They are still installed alongside each other, and ProcessCacheControl will install CacheControlTools during install. For existing installs, you might have to reinstall the module, or install CacheControlTools manually after the upgrade. Also, the asset version management is now part of CacheControlTools, so the code has to be adjusted: // version 0.3.0 and below $CacheControlTools = $modules->get('ProcessCacheControl')->getTools(); // version 0.4.0 $CacheControlTools = $modules->get('CacheControlTools'); A bit of background for the split: I learned something new about the permission system. If a Process module defines a permission, the current user needs that permission not only to access the Process page in the admin, but also for the module to even be instantiated at all. Because of this, the asset management system didn't work for guest users. By splitting the repository into two modules, I can still have strict access control for the Process part of the module, while allowing the tools module to be instantiated even during requests from guest users. Anyway, the module is now, let's say, nearing stability. I'd like to publish a stable release soon, so let me know if you find any more bugs!1 point
-
Thanks everyone for the feedback! I just pushed a new version that resolves a bug that prevented installs on PHP versions <7.4. PHP 7.1, 7.2 and 7.3 should work now! Thanks @Mikie for your help! I have also found some documentation in the ProCache store page. I've added an option to clear the ProCache now as well, though I haven't included it in the new version because I can't test it out. Would you mind giving it a go? The ProCache integration is in the procache branch on Github (download link). If it's working as intended, it should add a new option to clear the ProCache in the module configuration, including a note saying whether ProCache is installed. If selected, the 'Clear all' action should use $procache->clearAll and log the result. It would also be good to know if non-superusers can use this, or if it's limited to the superuser. Thanks! The module also appears to have been approved to the module directory, so it can now be downloaded directly through the backend using the module name ProcessCacheControl. Thanks @adrian (or is Ryan in charge of the module directory? ?)1 point
-
Right now only the default values can be overwritten via language translation files. But good hint - I'll add multi-language support for the config fields as well.1 point
-
Definitely! Started playing with it around 1998 and learnt by busting installs over and over. I have a couple of Windows VMs for work but only fire them up when I really have to. Other than that I am in Linux all the time. Currently running Manjaro on my laptop, with an Arch VM for testing and a Debian VPS for my web stuff. Started off with Redhat, Mandrake/Mandriva, Debian, Gentoo (its first release... STAGE 1 INSTALLS BACK THEN TOOK A LONG TIME) before falling back in love with Debian. Then I used Ubuntu from its first release (2004(?)) up until last year when I needed to reformat my laptop and figured I'd give the Arch style thing a go but didn't have enough time to play around with an Arch install from scratch.1 point
-
@szabesz had already mentioned it in this thread. But I think it is worth picking up again. I recently switched to https://vscodium.com/ and it is working absolutely great. It removes Microsofts branding and, more importantly usage telemetry. It is available for all platforms. Only drawback I could see is not having automated one-click updates. I'm all for open source and privacy. Microsoft's VS Code is based on the same codebase as VSCodium only MS adds their branding and collects lots of data because, well, that is just what they love to do. Being a Linux user for more than 15 years now, I really appreciate MS releasing this phantastic editor to the community. At least they are giving back a fraction of what they earned over the last decades with their half baked software which they make their beta testers pay a lot of money for. Ingenious concept, though...1 point
-
You can mimic a basic authentication in the file "site/templates/admin.php" Therefor you have to handle a set of valid usernames and passwords in that file too, like in the following example: <?php namespace ProcessWire; $validUsers = [ 'user1' => 'pass1', 'user2' => 'pass2', 'user3' => 'pass3' ]; $validAdminUser = false; if(isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) { if(isset($validUsers[$_SERVER['PHP_AUTH_USER']])) { if($validUsers[$_SERVER['PHP_AUTH_USER']] == $_SERVER['PHP_AUTH_PW']) { $validAdminUser = true; } } } if(!$validAdminUser) { header('WWW-Authenticate: Basic realm="Adminsection"'); header('HTTP/1.0 401 Unauthorized'); echo '401 Unauthorized! Accessing this page needs a valid useraccount!'; exit(); } require($config->paths->adminTemplates . 'controller.php');1 point
-
You can use a hook to ProcessPageEdit::execute to redirect users with those roles to the frontend page. Make a new file /site/ready.php and put this code inside: wire()->addHookBefore('ProcessPageEdit::execute', function (Hookevent $event) { $restrictedRoles = array('admin', 'frontendeditor'); // list your roles here foreach ($this->user->roles as $role) { if ($role->name !== 'guest' && in_array($role->name, $restrictedRoles)) { $this->session->redirect($this->config->urls->root); } } }); This will redirect users with given roles to the homepage of your site. Note that this will restrict them only from accessing page edit screen in the admin panel. If you like to restrict access to the whole admin area for those roles, you would need to hook into Page::render or Page::viewable and than check if the Page has template admin.1 point
-
I just learned about this: https://github.com/DivineOmega/password_exposed This PHP package provides a password_exposed helper function, that uses the haveibeenpwned.com API to check if a password has been exposed in a data breach.1 point
-
@teppo AAH! I can't believe I wasted so much time looking into namespaces and scope context yesterday!!! How embarrassing. Thank you.1 point
