Jump to content

MoritzLost

Members
  • Content Count

    89
  • Joined

  • Last visited

  • Days Won

    4

MoritzLost last won the day on February 19

MoritzLost had the most liked content!

Community Reputation

308 Excellent

About MoritzLost

  • Rank
    Full Member

Contact Methods

  • Website URL
    https://herebedragons.world/

Profile Information

  • Gender
    Male
  • Location
    Cologne, Germany

Recent Profile Visitors

725 profile views
  1. Only Ryan can answer that, but I suppose checking the timestamp every time would have a performance impact (though a tiny one). Another perspective is that checking only the template file might result in unexpected results if you modify an included file, because then the cache wouldn't be cleared. For example, if you're using Twig, the PHP template file isn't modified very often, so it wouldn't work. I actually prefer it this way, that is if the system makes few assumptions. I've only used WireCache because as far as I could tell when I was looking for something similar, it's the newer and better version of MarkupCache. Also, WireCache is already integrated into ProcessWire and ready to go. You can cache any kind of data (array, PageArrays etc) with it, while MarkupCache (as far as I'm aware) can only store strings. I'm using the WireCache to cache render-intensive HTML output and queried data on pages where I can't use template cache for various reasons, and it has a large impact, reducing page generation time on a particularly heavy page from ~2 seconds down to a couple milliseconds. Have a look at the $cache API documentation. Just out of curiosity, what are your tested page generation times for cached / uncached pages? Because in my experience, a simple ProcessWire site will already be so fast out of the box that caching won't do anything, because most of the generation time comes from network overhead and hard drive speed ...
  2. ProcessWire is pretty fast on it's own, so if you only have some PHP templates doing basic output there won't be much of a difference. Though you can probably see the difference by recording page load times in Chrome for requests with and without the cache, respectively. Though you need to do this in a private browser window where you aren't logged in, otherwise ProcessWire won't use the cache, as per your template cache settings. Two things that I have noticed to slow page loads down are "heavy" queries, e.g. if you query dozens of pages for data, especially if you do it in separate database queries. I'm also using Twig for output, which does come with a small time increase, especially while auto reload is active. That is correct, ProcessWire doesn't check timestamps of template files to decide when to serve from the cache. You can manually clear the entire template cache by going to Modules -> Configure -> PageRender and checking the checkbox there. Or use my new Cache Control module, which can clear the template cache alongside a couple of others in one click πŸ™‚
  3. 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!
  4. 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? πŸ™ƒ)
  5. Hi @adrian, I didn't know that module existed, it's not in the directory, is it? Because I looked if something like this already existed and didn't find anything. Might've saved me some trouble πŸ˜… That said, I had a quick look, here's what I found in comparing both modules: ClearCacheAdmin exposes more options through the setup page, so there are available to everyone, whereas ProcessCacheControl has it's options in the module configuration, so they are only available to the developer. ClearCacheAdmin has multiple links (and multiple options) on the process page, giving the user more fine control, whereas ProcessCacheControl goes for a simpler interface and bundles all those actions into one (configurable) action with a single button. ProcessCacheControl can delete $cache entries without an expiry date, which ClearCacheAdmin doesn't as far as I can tell. ProcessCacheControl also lets you configure caches to be deleted by namespace, whereas ClearCacheAdmin offers each cache entry to be deleted individually (I think this has mostly to do with the module being a bit older, I believe $cache didn't have all those options back then). The largest difference is my concept of "cache actions", which ClearCacheAdmin doesn't have. I'm not sure how useful that will actually be yet. I think if I can expand on the actions available by default, it will be pretty handy. With ProcessCacheControl, you can add custom cache actions / profiles through the API, that may be useful depending on the use case. Adding to that, ProcessCacheControl has permission checks on a per-action basis. ProcessCacheControl can be modified and executed through the API. In particular, you can modify the default action and execute any action programmatically.
  6. This is a new module that provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions. The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu: Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides: An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README. Beta release Note that I consider this a Beta release. Since the module is relatively aggressive in deleting some caches, I would advise you to install in on a test environment before using it on a live site. Let me know if you're getting any errors, have trouble using the module or if you have suggestions for improvement! In particular, can someone let me know if this module causes any problems with the ProCache module? I don't own or use it, so I can't check. As far as I can tell, ProCache uses a folder inside the cache directory to cache static pages, so my module should be able to clear the ProCache site cache as well, I'd appreciate it if someone can test that for me. Future plans If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind: Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions! Links https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory
  7. That's actually an interesting question, because it's a flaw with ProcessWire's built-in internationalization function. A general internationalization API will support multiple plural forms, because as in your language, there's more forms than singular or plural. ProcessWire's _n function for translating singular/plural forms simply checks if the item count is exactly one or more than one and return either the singular or the plural version of the translatable string (see the source code). This works fine for English, German and many other languages, but no in languages which have more than two forms for counting items. If you still want to use ProcessWire's translation API, you'll have to handle the different cases yourself, as suggested by @dragan (though I would still use the translation API instead of hardcoding the strings in the switch statement). However, a more "general" solution that would allow you to add different language versions of your site without changing the code would be to utilize the native Gettext implementation in PHP. This will be much more work though; as far as I'm aware there's no module that provides a gettext interface for ProcessWire, so you'll either have to write one yourself or upload translation files manually. BTW I know this is probably overkill for your current situation πŸ˜‰ But this has been bugging me for a while, it would be nice to see native support for different plural forms in the ProcessWire translation API. Might be a good candidate for a new module ... For more reading, here's a good resource for I18N in PHP.
  8. Ok, in that case you can still filter out the unnecessary paragraph with the non-breaking space inside. Your str_replace function probably doesn't work because you are trying to replace the literal string &nbsp;. That won't work because the non-breaking space is (most likely) stored inside the database as a Unicode character, not as the HTML entity. Matching "<p> </p>" won't work either, because that is a regular space, not a non-breaking space. To replace the non-breaking space, you can use a regular expression and match the specific NO-BREAK SPACE Unicode character. This works for me: $string = "<p>&nbsp;</p>"; $string_unicode = html_entity_decode($string); // $string_unicode now contains a non-breaking space unicode character echo preg_replace('/<p>\x{00A0}<\/p>/u', 'Successfully replaced!', $string_unicode); // Successfully replaced! Make sure to include the u flag to treat the string as UTF-8. You could also modify this to match multiple non-breaking spaces or whatever CK Editor throws at you πŸ™‚ You can use that either to remove the superfluous paragraph in your template output, or write a little script to convert the text saved in the database (which is the cleaner way to go, if you ask me).
  9. For CK Editor fields, I always use the option to force pasting text as plain text. This strips any markup and formatting when pasting, it has prevented so many headaches for me ... It does mean that you can't paste formatted text even if you know what you're doing, but this way no weird formatting from Word can make it into the source code. You can activate this option through the Custom Config Options for the CK Editor field: forcePasteAsPlainText: true I'm not sure that will remove the extra non-breaking space (the paragraphs get added by CK Editor, so you only need to get rid of the NBSP), but it's worth a try and it does deal with most problems when pasting from Word.
  10. The machine names of system fields are always in english, so you need to access the description like this: $description = $download->Datei->description(); By the way, there's also a utility method for the file extension: $extension = $download->Datei->ext(); Also, if your Repeater only contains the file field, you could also get rid of the Repeater altogether and just allow multiple files on the "Datei" field. Then you could iterate it directly: foreach ($page->Datei as $file) { $url = $file->url(); $ext = $file->ext(); $description = $file->description(); // output download links here ... } Look up the Pagefile API documentation for a list of all available utility methods.
  11. @LostKobrakai I don't think so, it appears the old name (getModuleConfigData) is simply an alias to the getConfig function now. See the source code of the Modules class. I tested it with the current dev version of ProcessWire, and the problem described above still occurs. Also, the source of getConfig pretty much only fetches the config from the correct database row, without merging in the default config (which I believe it should do as well) ...
  12. I'm digging this thread out because I just came across the same problem in my module. I fixed it for now by merging the default config as suggested by @Robin S: $options = $this->modules->getModuleConfigData($this); $defaults = (new TextformatterPageTitleLinksConfig())->getDefaults(); $options = array_merge($defaults, $options); See the complete source code here. However, I agree that this should be handled by ProcessWire. I expected getModuleConfigData to return the final merged configuration, the method doesn't suggest that it only retrieves the config that has been saved to the database. This way the method creates a temporary dead zone between installing a module and saving the module configuration page, where errors can pop up in the meantime. @horst @kongondo By the way, saving the module config during installation may not be sufficient. In my case, I got an error when I upgraded my module to version 3.0.0 which included a new setting. So even though the module was already installed and the options had been saved before, the new version was missing the new configuration option as it wasn't included in the configuration returned by getModuleConfigData. So with this approach one may also need to hook into the upgrade process to make sure the configuration is saved after every update.
  13. Twig would definitely be number one on my list, I've been using it for every project for a while and it feels waaaay cleaner than native PHP or Blades. See my tutorials (part one - part two) regarding the Twig integration πŸ™ƒ Part two has some examples of connecting Twig to the ProcessWire API, it's a natural fit.
  14. It mostly doesn't matter, you get the same API variables independent of the method. That said, I would suggest the following for readability: $this: Use only inside of classes extending \ProcessWire\Wire. It appears that $this is also available in template files as a reference to the current wire instance, but as you said, this is a somewhat confusing and unconventional usage given that you're not actually inside a class. $wire: Use inside regular PHP template files (or if you want to use a different API variable like $page, $pages, $input, et c. use that one directly). wire(): Use inside functions (not class methods) so you don't have to pass $wire or $this to the closure.
  15. Checkout You Might Not Need jQuery for this, it will tell you some replacements for the most common jQuery operations! Here's a rough draft: function more(url) { window.location = url; } document.querySelectorAll('a').forEach( link => link.addEventListener('click', e => { e.preventDefault(); const href = e.currentTarget.href; document.body.classList.add('fade-out'); setTimeout(() => more(href), 500); }); ); Note that the callback to fadeOut in your code is "open" while the reload function is called "more", is that a mistake? Anyway, I corrected it. Note you have to add a CSS transition for the "fade-out" class yourself, check the link above for an easy example. Also make sure that the timeout (500ms in my example) matches the duration of the CSS transition. Cheers! Sidenote, if all you're doing is delaying the page reload by a couple hundred miliseconds to have the body fadeout, you might as well get rid of that, it only gets in the way of the user without any real benefit. But I don't know anything about your use-case, so I might be way off here!
Γ—
Γ—
  • Create New...