Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/20/2022 in all areas

  1. @bernhard I use redis alongside PW on some client sites (using php-resque for background jobs like email composition and send) - though I do not use this particular module in production yet. I think bitpoet is aiming for an API-compatible drop-in for wirecache that leverages the lower latency of redis' in-memory accesses.
    3 points
  2. Hi @Ivan Gretsky, I will at one point for sure, but that will be late in the year. I‘m currently hiking across the U.S. and won‘t get my hands on a computer until October.
    3 points
  3. Hi Inxentas, You need to get InputfieldCKEditor instead of InputfieldTextarea. $field = wire('modules')->get('InputfieldCKEditor'); $field->columnWidth = 100; $field->attr("id+name", "source_text"); $field->label = "Source Text"; $field->icon = "fa-align-left"; $field->value = "<h1>Yeah HTML!</h1>";
    2 points
  4. https://www.autohaus-bendel.at/ Highlights/Features: New Logo and matching Backend using module AdminStyleRock Very good google- and performance-ratings thx to UIkit and ProCache Flexible content pages (using private module RockMatrix) Cars are fetched automatically from an austrian cardealer API and converted into ProcessWire pages with a custom filter page: https://www.autohaus-bendel.at/fahrzeuge/ Forms with honeypots and live validation (using private module RockForms based on nette forms) Web-Coach The client gets automated reminders if he does not add new content to the website. Thx @wbmnfktr Bendel Web Coach The last news entry was created 21 days ago. There must be something new that will interest your clients ;) > To the website > Create news entry Animated page transitions using barba.js Migrations and deployment using RockMigrations. Debugging using TracyDebugger. ?
    1 point
  5. I've got a scenario where I use ProcessWire as a CRM for a client and they have several companies using this now, so it's important to be able to update things easily across all installations. A tricky one recently was working out how to manage translations via API to avoid going into several installations, enabling language support and translating the file manually (in this case they wanted to tweak a message in LRP's confirmation routine). On your master installation, do your translation as normal Export to CSV Upload the CSV file somewhere where your updater code can reference it - I created a folder in site/assets called "uploads" for some CRM-specific stuff, so I added another folder under there for ' Use code similar to the below in your updater script on other installations to first create the JSON file to be translated (it may not already exist) and then import your CSV file and tidy up afterwards - something like the below: <?php $this->modules->refresh(); // I've found this helps first, mostly for modules that have just been pushed to the Git repo but doesn't hurt to do it every time $this->modules->install('LanguageSupport'); // This wasn't yet installed $languages = $this->wire()->languages; $default = $languages->get('default'); // We only use the default language as it's only for the UK market $default->of(false); // It will complain without outputformatting switched off under some scenarios $translator = new LanguageTranslator($default); $translator->addFileToTranslate('site/modules/LoginRegisterPro/LoginRegisterProConfirm.php'); // This generates the JSON file that you would see in PW on the translations page $languages->importTranslationsFile($default, $this->config->paths->assets . 'uploads/imports/default-site.csv'); // This imports the CSV we exported from our master installation unlink($this->config->paths->assets . 'uploads/imports/default-site.csv'); // And we don't need the file afterwards I appreciate it's not a particularly in-depth tutorial, but may help someone out there with a similar need. Our CRM installations are all on an Amazon EC2 instance under separate subdomains, so separate databases too and there's a shell script I use to iterate all the installation folders, get the latest updates from the Github repo and then run an updater script that will do more complex updates like the above code or perhaps alter tables etc. This may get trickier in future if we shift to using something like Docker, or that may make life easier, but at the moment this is all nicely manageable the way it is.
    1 point
  6. This week I've been busy developing a site. It's the same one as the last few weeks, which is an established site moving out of WordPress and into ProcessWire. Next week the whole thing is getting uploaded to its final server for collaboration and for client preview. I've been pretty focused on getting that ready and don't have any core updates to report this week, though should next week. One thing about the prior version of this site (and perhaps many WordPress sites) is that there wasn't much structure to the pages used in the site, and hundreds of unrelated pages in the site confusingly live off the root, such as /some-product/ and /some-press-release/ and /some-other-thing/. There's no apparent structure or order to it. And those pages that do have some loose structure in the wp-admin have URLs that don't represent that structure on the front-end. There's very little relation between the structure one sees in the wp-admin and the structure that one sees in the URLs, or in the front-end navigation. They all seem to be completely unrelated. That's one thing that I've tried to fix, so that there is some logic and structure rather than having a bunch of unrelated pages all in the same bucket (is this common in WordPress?) But there's one big caveat. We didn't want to change anything about the actual URLs that are used on the site. This is a site with a long history, a lot of incoming links, and a lot of search traffic. The current URLs have been in place a long time and we didn't want to introduce more redirects into the site (there are already a ton of 301 redirects accumulated over time). So we wanted to make sure the existing URLs in the new ProcessWire-powered site are identical to what they were in the WordPress site. That might seem difficult to do, going from an unstructured WordPress site into a highly structured ProcessWire site... but actually it's very simple. Here's how: Making ProcessWire render pages from WordPress URLs We created a new URL field named "href" and added it to most of the site's templates. For established pages that came in from the old WP site, this "href" field contains the WordPress URL for the page. Depending on the page, it contains values like /some-product/ or /some-press-release/, /some-country/some-town/, etc. In most cases this is different from the actual ProcessWire URL, since the page structure is now much more orderly in the back-end. And for newly added pages, we'll be using the more logical ProcessWire URL. But for all the old WordPress pages, we'll make them render from their original URL. This is certainly preferable from an SEO standpoint but also helps to limit the redirects in the site. In order to make $page->url return the old/original WordPress URL (value in $page->href), a hook was added to the /site/init.php file: /** * Update page paths and URLs to use the 'href' field value on pages that have it * */ $wire->addHookBefore('Page::path', function(HookEvent $event) { $page = $event->object; /** @var Page $page */ $href = $page->get('href'); if(!$href) return; // skip if page has no 'href' value $event->return = $href; $event->replace = true; }); Now we've got $page->url calls returning the URLs we want, but how do we get ProcessWire to accept those URLs for rendering pages? The first thing we'll need to do is enable URL segments for the homepage template. We do this by going to: Setup > Templates > home > URLs > and check the box to enable URL segments. Save. Then we need to edit our /site/templates/home.php to identify when URL segments are present and render the appropriate page, rather than the homepage: $href = $input->urlSegmentStr; if($href) { $href = '/' . trim($href, '/') . '/'; $page = $pages->get("href=$href"); if(!$page->id || !$page->viewable()) wire404(); $wire->wire('page', $page); // set new $page API var include($page->template->filename); // include page's template file } else { // render homepage output } As you can see from the above, when URL segments are present, we find a page that has an "href" field value matching those URL segments ($input->urlSegmentStr). If we don't find one, we stop with a 404. But if we do find one, then we set the $page API variable to it and then include its template file, making that page render rather than the homepage. If there is no $input->urlSegmentStr present then of course we just render the homepage. That's it! By using these little bits of code snippets to replace ProcessWire's URL routing, now all the URLs of the old WordPress site are handled by ProcessWire. Like most things in ProcessWire, there's more than one way to accomplish this… We could have used URL/path hooks, or we could have hooked before Page::render to take over homepage requests with URL segments, before the homepage even got involved. Or perhaps we could have hooked in even earlier, to something in the ProcessPageView module or PagesRequest class. Or we could have used an existing module. Any of these might be equally good (or even better) solutions, but I just went with what seemed like the simplest route, one that I could easily see and adjust. Plus, it'll work in any version of ProcessWire. The actual solution I used is a little more than what's presented here, as it has a few fallbacks for finding pages and scanning redirect lists, plus passes along remaining pagination/URL segments to rendered pages. I'm guessing most don't need that stuff, and it adds a decent chunk of code, so I left that out. But there are a couple of optional additions that I would recommend adding in a lot of cases: Forcing pages to only render from their "href" URL and not their ProcessWire URL (optional) Our existing hooks ensure that any URLs output for pages having "href" values are always based on that "href" value. But what if someone accesses a given page at its ProcessWire path/url? The page would render normally. We might want to prevent that from happening, ensuring that it only ever renders at its defined "href" URL instead. If the page is requested at its ProcessWire URL, then we redirect to its "href" URL. We can do that by adding the following code to our /site/templates/_init.php file: if($page->id > 1) { // ensure that we are rendering from the 'href' URL // rather than native PW url, when href is populated $href = $page->get('href'); $requestUrl = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : ''; if($href && $requestUrl && strpos($requestUrl, $href) === false) { // href value is not present in request URL, so redirect to it $session->redirect($config->urls->root . ltrim($href, '/')); } } Enforcing uniqueness and slashes in "href" values (optional) It's worthwhile to enforce our "href" values being consistent in having both a leading and trailing slash, as well as making sure they are always unique, so no two pages can have the same "href" value. To do that, I added this hook to my /site/ready.php file (/site/init.php would also work): /** * Ensure that any saved 'href' values are unique and have leading/trailing slashes * */ $wire->addHookAfter('Pages::savePageOrFieldReady', function(HookEvent $event) { $page = $event->arguments(0); /** @var Page $page */ $fieldName = $event->arguments(1); /** @var string $fieldName */ if($fieldName === 'href' || in_array('href', $page->getChanges())) { // the href field is being saved $href = $page->get('href'); if(!strlen($href)) return; // make sure value has leading and trailing slashes if(strpos($href, '/') === 0 && substr($href, -1) === '/') { // already has slashes } else { $href = '/' . trim($href, '/') . '/'; $page->set('href', $href); } // make sure that the 'href' value is unique $pages = $event->object; /** @var Pages $pages */ $p = $pages->get("id!=$page->id, href=$href"); if($p->id && !$p->isTrash()) { $page->set('href', ''); $page->error( "Path of '$href' is already in use by page $p->id “{$p->title}” - " . "Please enter a different “href” path and save again" ); } } }); That's all for this week. Thanks for reading, have a great weekend!
    1 point
  7. Here's a small new module that started as a spinoff of a memcache proof-of-concept. Cache your strings and partials in-memory using Redis as a backend. CacheRedis All you need is a running Redis database. The module supports connection through regular TCP, over TLS and via unix domain sockets. Host and port are configurable, and authentication is supported too. Here's a screenshot of the module configuration options: I'll not go into too many details about the usage, you can see everything explained in the README on GitHub, and just highlight the most important points. When the module is active, you'll have a wired $redis variable, which means you can reach the module as $redis, wire("redis") or within Wire classes / modules as $this->redis. CacheRedis is strongly influenced by WireCache, and its usage is (hopefully) straight forward. // Store an entry in the cache under the given key name with the given value: $redis->store("cached_value_number_one", $expire, $value); // Retrieve a value from the cache $value = $redis->fetch($key); // Delete a cache entry $redis->delete("my_other_cached_value"); // Clear the whole cache $redis->flush(); // Retrieve a value from the cache, and if not found, create it through the given function // and store it with a lifetime of 5 minutes (300 seconds) $value = $redis->fetch($key, 300, function() use($page) { return "Page last changed on " . strftime('%m/%d/%Y %H:%M', $page->modified | $page->created); }); // Render a file using wireRenderFile and store it in the cache. // We'll pass a selector as the expiry value so this cache gets // emptied every time a page matching the selector is saved. $news = $redis->renderFile("partials/news.php", 'template=blog-post', ["page" => $page]); The module is still very crude work in progress, but I hope some of you feel daring, try it out and let me know in case anything breaks. Have fun!
    1 point
  8. That's the ticket! It's rapido on setting 0! Love it. Great work with the htmx updates! I feel warm and fuzzy.
    1 point
  9. As I've never used redis I had to do some research what it is and what it does... Here's a good video that gives you a quick overview: Would be interesting to hear why/where/when one could use this module and what benefit one would get vs. using WireCache ?
    1 point
  10. What do you mean? Is this how it should be? Or is this what you think has to be? If you want it to have a dummy title, @Studio Lambelet has shown the solution. If you think it must be like this: No, you can leave the title empty and the user has to fill the field on the first edit. You can even do this with my technique. Simply add those fields to the redirect url: $event->session->redirect($p->editUrl()."?fields=title,your_upload_field"); <?php $wire->addHookAfter("/createpage/{parentID}", function($event) use($parent) { // access control $parent = $event->pages->get((int)$event->arguments('parentID')); if(!$parent->editable()) return; // create new page $p = new Page(); $p->parent = $parent; $p->template = 'your-child-template'; if($parent->template == 'your-parent-a') $p->title = 'Dummy text for parent A'; elseif($parent->template == 'your-parent-b') $p->title = 'Dummy text for parent B'; $p->save(); // redirect to page editor $event->session->redirect($p->editUrl()."?fields=title,your_upload_field"); });
    1 point
  11. Any reason why you installed the latest version on top of the older version instead of overwriting the files in the original install?
    1 point
  12. Regarding the dummy title, I did not test this code, but based on @bernhard reply, I think this should work: // ... Rest of the code before $p = new Page(); $p->parent = $parent; $p->template = 'your-child-template'; $p->title = 'your dummy title'; $p->save(); $event->session->redirect($p->editUrl()); // ... Rest of the code after As for the parent page, in the admin Processwire use a GET input to pass the page id ("?parent_id=X). // Hook is in /site/ready.php (or /site/templates/admin.php) $this->addHookAfter('ProcessPageAdd::buildForm', function ($event) { // Retrieve GET input "parent_id" $parentIdInput = $this->wire('input')->get['parent_id']; // Sanitize GET input $parentId = $this->wire('sanitizer')->int($parentIdInput); // Get page $parentPage = $this->wire('pages')->get($parentId); if ($parentPage->id) { // Retrieve the form $form = $event->return; // Create an inputfield markup to display some html. $field = $this->wire()->modules->get('InputfieldMarkup'); $field->name = 'messageToUser'; $field->value = "<p>The parent page title is {$parentPage->title}.</p>"; // Use "$form->add()" if you want your message at the end of the form (after button) $form->prepend($field); // Populate back argument $event->return = $form; } });
    1 point
  13. This is a game changer already. Thank you for your hard work as always!!! Going to check this out. It's like Christmas in summer!
    1 point
  14. @kongondo awesome news!! Apologies for the slow reply!! Excited to test this out ?
    1 point
  15. There are already good guides on the internet on how to update ProcessWire! Look here: How to upgrade ProcessWire to the latest version or here ProcessWire Upgrade (ProcessWireUpgrade) - ProcessWire Module
    1 point
  16. Hey and thanks for the interest. I am head of community at CrowdSec and I had never heard about ProcessWire before this, so thanks for pointing me to it. I haven't heard of anyone working on a bouncer (or parsers or scenarios) for ProcessWire. I won't rule out that anyone is, but I doubt it. Could I ask what motivates you to specifically ask for a bouncer? I would say that it probably also would make sense to have a parser that's able to parse PW logs and a scenario able to detect attacks such at bruteforce access to the PW backend (assuming that there is one) for instance. Both the Wordpress and Magento bouncer is really a specialized version of the generic PHP bouncer. Here's an article on how to use it with Drupal but in reality it works with anything PHP. If more people are interested in PW support it would be a great idea to join our Discord and talk about it there. I hope this was to any help. If I can do more please let me know.
    1 point
  17. 1 point
×
×
  • Create New...