Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by teppo

  1. On 2/25/2019 at 2:49 PM, gottberg said:

    Hi, thanks for the great module! Will be default in all my next PW-sites!

    I wonder if there is anyway to setup a mail trigger if a page gets unpublished/published?

    On 2/25/2019 at 2:54 PM, adrian said:

    I realise it's been a while since this was posted (again: sorry!) but while some sort of email trigger might be an interesting future addition, at the moment what Adrian suggested is probably the fastest and easiest way to achieve this. That, or perhaps Field Change Notifier in case you prefer a GUI solution 🙂

  2. On 2/4/2019 at 11:55 PM, ceberlin said:

    If there would be a setting not to log system actions (or log them differently, maybe shorter) it would be easier to know what's going on with with the editors because their changes can be stored longer (not so many entries normally)?

    Latest version adds support for ignoring specific users and/or roles, so that may help a bit. There's no clean way to figure out what is a system action, so I think ignoring the guest user (or some other user/role you use to perform these automated actions) is the best solution we have at the moment.

    Shorter duration for log rows matching some rule (such as a specific role/user) could be a potential future addition as well, in case there's demand for that sort of thing 🙂

    On 2/25/2019 at 12:20 PM, szabesz said:

    Hi Teppo, 

    I do not remember correctly, but maybe after switching a site from 7.0.x to PHP 7.1.x I started to get a lot of these:

    PHP Notice: Undefined index: Previous page URL in .../ProcessChangelog/ProcessChangelog.module:810

    Could it be possible to get rid of these?

    It's been a while (sorry!) so hopefully this has been resolved already. If not, let me know (preferably via GitHub issues, these are much easier for me to keep track of).

    On 8/26/2019 at 7:45 PM, Peter Knight said:

    Can anyone confirm this is working with PW 3+ and how I access the ChangeLog with the V3 UI?

    I have ChangeLog installed but see nothing listed under the Setup tab where my other Modules are listed.

    According to the instructions...

    I think this applies to PW UI pre UI Kit as the latest version only has a navigation structure of

    • Pages
    • Setup
    • Modules
    • Access


    If this is still occurring, please open a GitHub issue (if possible). I've just tested the module with both Reno and (old) default admin theme's, and was unable to reproduce this. I'm not entirely sure of the specifics, but it seems that adding any published (and non-hidden) page under /processwire/setup/ brings it up in the menu, so not really sure where to start, except that perhaps make sure that you're not using any hooks / modules that might somehow alter menu behaviour.

    It would be best if you could try this on a blank install: if the issue occurs there, it should be much easier for me to reproduce as well. If not, it's probably something specific to your current setup, which means that we'd have to start by figuring out what exactly is going on there 🙂

    On 10/9/2019 at 4:41 AM, Guy Verville said:

    Thank you very much for your great work! I wonder if it would be possible to prevent a user to be logged. Let me explain, one of our sites has a synchronisation process which use a user 'synchro'. This automated process does not need to be logged, since there are a lot of changes made by this process. We only want to log 'regular administrative' users.

    Latest version (1.7.1) has two new configuration options (ProcessChangelogHooks config settings): ignored roles and ignored users. I think one of these should help with this 🙂

    • Like 1
    • Thanks 1

  3. 19 hours ago, franciccio-ITALIANO said:

    I wanted to know something about how to insert tags in processwire pages, because in the html version of a static site, it is very very easy to insert them. Indexed or not by google, in doubt they are put! I'm sorry I can't put them in processwire. If not google, the author needs to try to summarize the topic of the page. Anyway, thanks for the answers! 😉

    Hey franciccio!

    I may have misunderstood your post (in which case: sorry in advance) but if by "I can't put them in processwire" you mean that you can't add keywords with ProcessWire, then please re-read the posts in this topic. As Bernhard and psy both pointed out, it's actually quite easy to do – the only thing you need to do is add a custom field for your keywords.

    There's no native keyword field out of the box because, let's face it, very few users need that. That being said, if you want to have a field for storing and outputting keywords, all you need to do is add it yourself. Just like you would with any other custom data you require 🙂

  4. 2 hours ago, pwired said:

    Can you back that up ? Did Google, Yahoo, or Bing mention anything about that ?

    Speaking from my own experience, keywords won't help ranking up in Google, but leaving keywords out will rank you down.

    Latest official statement is from '09, but nothing I've heard since has convinced me otherwise. Experts in the subject seem to concur. There have even been some suggestions that it may be harmful – though of this I also have no experience myself, or perhaps I was always using it in a "non-spammy" way 🙂


    Bing has stated in the past that it uses the keyword meta tag as a spam signal when stuffed with keywords not relevant to the page. 

    Latest advise from Moz states the following, classifying the keywords meta tag as "indifferent":


    While no good SEO is going to recommend spending any time on this tag, there's some very small possibility it could help you somewhere. Please leave it out if you're building a site, but if it's automated, there's no reason to remove it.

    The folks at Yoast even went through the trouble of removing the support for meta keywords from the Yoast SEO plugin, though I believe their reasoning was mostly just that people were spending time thinking of good keywords to put there, while in reality it was all wasted effort.

    • Like 2

  5. 1 hour ago, bernhard said:

    In this case you might want to use a page reference field where the user can select multiple pages (tags) and then just foreach + echo them on the frontend.

    Just to iterate on this answer: there's no built-in tag concept for pages in ProcessWire.

    If you want to add tags to your pages, you can a) use a Page Reference field for your tags (in case you want to define a collection of tags and reuse them), or b) use a text field (if you only need to use them for this one use case). The code @psy posted above depends on you first adding a Page Reference field called "tags" for your page, but note that you actually want to provide it with two params: $page->tags->implode(', ', 'title') (or name instead of title, or whatever field/property of your "tag pages" you want to display).

    On a loosely related note, the keywords meta tag you've mentioned is pretty much pointless these days. Search engines don't use it (at least as a ranking factor, although they may still include keywords contents in their index), and that was always pretty much the only reason to use it. Other than that tags can of course have valid use cases for categorising / grouping content 🙂

    • Like 2

  6. Thanks Bernhard! I might've indeed read your post somewhat wrong. Now that I've re-read it along with your comments (and watched the video), I think I have a better idea of what RockThemes is all about. I can even see some similarities with wireframe, although I'd still argue that they are few, and they seem to mostly apply to the view layer – or a part of it 🙂

    The word "theme" might've thrown me a bit off, yet now that I'm reading your post for the third time or so, I'm still not sure what else to call it. Correct me if I'm wrong, but technically you're talking about having the template files (/site/templates/*.php) populate a content variable, and the theme pretty much defines what "wraps" that site-specific content? Still not entirely sure I got this right, so I may be completely on the wrong tracks 😅

    By the way: as a bit of a disclaimer please don't take anything I say here as disencouragement. That is not my intention. I think your idea has plenty of merit, and it's thrilling to see projects like RockThemes that, in some ways, challenge the status quo.

    6 hours ago, bernhard said:

    Site profiles are so rigid and one-way. What if I developed a new project, started with my great profile and implemented a new feature (like new SEO markup that was not supported yet. I'd have to implement that feature on my site, then I'd have to update my site profile if I wanted to use this feature for future projects. And then? What happens to the 10 sites that I've built using this site profile during the last year? I'd have to update all of them one by one.

    What I want is to implement a feature once and then just do a git pull to update all instances. Maybe I'm overengineering, though...

    Trust me, I've been there. Your concern is perfectly valid and familiar. Site profiles are intended as starting points, and they don't scale beyond that 🙂

    One solution to your problem from my point of view: if you have a feature that you want to use on multiple sites either as-is (or perhaps with some modifiable settings), bundle it into a module. Menu generation, metadata output, favicon generation... this sounds like three separate modules to me. Or one module that does it all if that makes more sense, but at least in my experience separate modules tend to make more sense as they provide more flexibility.

    If it's all bundled into one package, you tend to run into problems if you want to modify your metadata generation method – but the modification only applies to, say, five out of those ten sites. Not to mention the two that require an entirely different solution, etc. The point is that in my experience it's better not to bundle too many assumptions into one package.

    "One module, one concern" 🙂

    (A bit off-topic, but the "small modules" approach can sometimes result in a more work when it comes to updates. That, in turn, can be resolved by using a module manager, or – my personal preference – Composer. Or, alternatively, Git submodules.)

    6 hours ago, bernhard said:

    I think our approaches are quite close. I might have only been missing the site-profile part when I played around with WireFrame. So I ended up with a blank site and thought: "Ok, that's not too much of help or not really what I wanted."

    Even after re-reading your post, I still think that the purposes are somewhat different. Let me elaborate on that a bit... 😅

    For me one key point about wireframe is the separation of the business logic ("code", which is implemented as the methods of the Controller classes) from the presentation layer (the "dumb" views, partials, and layouts). The amount of markup generation features in wireframe is also exactly zero: it provides structure and "connects the dots" between different components, but the rest of the implementation is entirely up to the site in question.

    One example (I'm trying hard not to go too deep into my own "vision" here) are the sites I've built with the predecessor of wireframe that didn't have a "human-readable" UI. API first (or "headless") sites, that is. I've also built sites that didn't even have an API – only code that was triggered behind the scenes by scheduled scripts – though admittedly that's a rare use case.

    In wireframe controllers and various view components are all optional, which means that there may be sites that use them all, as well as sites with just a backend or just a front-end – not to mention that a site with a front-end may still use just a part of the view layer: all templates could use a single layout file for rendering, but they might as well not use a layout file at all and instead rely on template-specific view files for all their rendering needs 🙂

    6 hours ago, bernhard said:

    The idea of RockThemes is to provide a framework on the one hand (with a helper class just like ryan has the uikit helper functions file), but in addition to that themes could also provide basic page blocks that one needs over and over again. In contrast to WordPress Themes this could be files that are completely decoupled from the site's field setup. An uikit slider for example could look like this:


    // defaults
    if(!isset($images)) $images = $page->images;
    <div class="uk-position-relative uk-visible-toggle uk-light" tabindex="-1" uk-slider>
        <ul class="uk-slider-items uk-child-width-1-2 uk-child-width-1-3@s uk-child-width-1-4@m">
            <?php foreach($images as $image): ?>
                <img src="<?= $image->url ?>" alt="">
                <div class="uk-position-center uk-panel"><h1>Foo</h1></div>
            <?php endforeach; ?>
        <a class="uk-position-center-left uk-position-small uk-hidden-hover" href="#" uk-slidenav-previous uk-slider-item="previous"></a>
        <a class="uk-position-center-right uk-position-small uk-hidden-hover" href="#" uk-slidenav-next uk-slider-item="next"></a>

    This block (that can be shared across different projects and simply updated via git push/pull) could then be rendered in the theme like this:


    <region id="main-slider">
      <?= $theme->parent->render("blocks/slider.php", [
        'images' => $page->your_image_field,
      ]); ?>

    This means that it would not be a problem at all if pages had different field names.

    Right – this makes sense, I think. I don't think I've yet seen in your examples how one would extend a theme, but I'm assuming that the general concept is that you've got one theme that you copy from project to project, and then for each project that differs from the base theme in any way you create another, site-specific theme that you customise?

    If that's correct, this reminds me of WordPress' themes and child themes. In that context the idea is that you can update the parent theme and your site will stay intact because all the modifications are in the child theme. (This, of course, doesn't always work because the child theme may override something that changes / breaks when the parent theme is updated, new version of the parent theme may add or change a feature that the site relies on / doesn't need, etc.)

    On the other hand RockThemes itself is more like a "theme frameworks" in that it provides the base implementation for themes to build on, and possibly a number of general purpose helper features, components / blocks (?), etc. Hard to say what those would actually be without seeing the module, so I could be on the wrong tracks again, of course.

    I'll have to give this a few more moments to really sink in, after which I might have more questions / suggestions. Anyway, If I'm following you correctly, I like what you're doing here but wouldn't personally go this way – partly because I'm already invested in wireframe (obviously), but also because this doesn't seem to solve the issues I mostly struggle with (such as the part about separation of concerns). The issues with updating stuff, on the other hand, I've managed to resolve via other means, so for me that's mostly a non-issue 🙂

    • Like 3

  7. Hey Bernhard!

    A few initial observations and notes – I will have to dig into your post deeper and check the video when I'm back home. On a trip at Spain at the moment, and the network connection here is... limited 🙂

    First of all I still find the idea of themes intriguing, but it's also a complex matter, and there are different aspects to consider. For an example WordPress has (as most here probably know) made great effort to support themes – yet in reality you cannot just switch between themes as you want (which is, in my opinion, a key point in the themes vs. starting profiles discussion) if you have something "out of the ordinary" going on: custom fields, custom views, plugins generating markup, etc.

    Wireframe doesn't actually try to solve the theming part. In fact it's quite the opposite: it's a framework that provides sensible structure for sites built with ProcessWire – one that separates the implementation into different files/classes ("business logic" vs. views vs. layouts and so on) in a meaningful way, allows for reusability, and continues to make sense even if/when the site scales. While it can be easy to make visual changes to a site built with wireframe – as long as it's used in its entirety, in which case making changes to a single layout file is often all you need – that's really the extent of it.

    The kind of things you've mentioned, like getting the framework and setting things up, are in that context resolved with site profiles: if you find yourself repeating these tasks over and over, you should build a site profile where you've got the defaults nailed down – or, if you find you often just swap the logo etc. then add a settings area and a custom field for it. The "official" Wireframe boilerplate is one of those, and here at Avoine we've got our own "boilerplate" specifically tailored for the type of sites we work with (and what you've listed are (some of the) things we've covered in it).

    Long story short: I think we're solving different problems, and as such I wouldn't draw too many lines between those two solutions 🙂

    I do agree that you're onto something here, though, and see a need for that. The way you've described RockThemes sounds pretty close to how WordPress works, although I've not had the chance to dig into all the details yet. For an example I don't have a good idea about how much you're planning to let a specific theme override vs. how much you plan to keep things "set in stone". That, I think, is actually one of the most important factors here: figuring out how much you can/should standardise stuff, and if one can "break loose" of the theme by overriding it in a way that changes it radically.

    ... and that, of course, depends on how far you want to go in terms of "themeability": if one wants to switch a theme and it should always "just work", you might go as far as define basic views and features (such list and archive views etc.) so that theme authors know what to provide markup/logic and styles for. On the other hand if it's enough that the layout is interchangeable and all content types (templates) that don't follow some specific convention (title and body fields, or something like that) will need per-site markup, then a much simpler approach is going to be quite enough.

    My "a few initial observations" got a bit out of hand, but I'll definitely check the video etc. later. And sorry if I've missed any important points here 🙂

    • Like 7

  8. On 9/30/2019 at 11:01 AM, ceberlin said:

    Hi Teppo, is there a way to make the search language aware? - I mean getting the right context from mutilanguage fields per active language? Probably this would mean an indexing per language?

    Sorry for the late reply. This is definitely something I'll have to figure out, one way or another, just haven't had the time (or need for that matter) yet.

    I'll have to do some testing first and get back to this later 🙂

    • Like 1

  9. Couple of updates during the past week, 0.11.0 and 0.11.1. I'll attach the changelog below, but here's a summary of changes:

    • Saving just a single field (via API or perhaps some async feature) should now correctly regenerate the search index.
    • Page Reference fields are supported: the title and name values of referenced pages are stored in the index. Page names can also be search with the field name; if, say, you have a Page Reference field called "tags", you can find specific matches by searching for "tags:[tag-name]" ("tags:tailwind" etc.)
    • One relatively big change behind the scenes is that now the search index is generated after page has been saved, by hooking into Pages::savedPageOrField and triggering a new save for just the index field, quietly and with hooks disabled.

    Originally the module hooked into Pages::saveReady and generated the index so that it got saved along with any user-provided changes, but it turns out that this could result in some rather obscure bugs due to output formatting being enabled on the fly (which is intentional, and required for the most representative search index) which in turn was triggering interesting side effects under some specific conditions. So far the new method hasn't resulted in any unexpected side effects as far as I can tell, but it's worth pointing out this is a pretty big update.

    ## [0.11.1] - 2019-09-26
    ### Changed
    - Index value gets saved in Pages::savedPageOrField instead of Pages::saved.
    ## [0.11.0] - 2019-09-26
    ### Added
    - Support for indexing Page Reference fields.
    - Support for indexing non-field Page properties (id, name).
    - New hookable method Indexer::___getPageReferenceIndexValue().
    ### Changed
    - Index value gets saved in Pages::saved instead of Pages::saveReady so that we can avoid messing with the regular save process.
    ### Fixed
    - Fixed the "save" behaviour of the Indexer::indexPage() method.


  10. On 9/24/2019 at 11:02 PM, planmacher said:

    I have a special need for the side, I'm working on right now:  Is there a possibility not to show the "result_summary_field" in the rendered results, but the 'near' content of the search-match in the search field itself - with the match highlited?

    Assuming that I correctly understood your need, this would require dynamically generating the descriptions. Technically it should be doable by hooking into Renderer::RenderResultDesc(), but you'd have to provide the entire description generation and highlighting logic yourself, so it might be a bit difficult to achieve in practice.

    This is actually something that I've got planned, but I'm not really sure when I'll get to it. Anyway, it's good to know that there's demand for it.

  11. AdminBar 2.4.0 is out and adds support for the "data-adminbar-adjust" attribute. The idea here is to automatically modify (or adjust) certain CSS properties whenever the height of the Admin Bar is recalculated. Note: AdminBar already automatically adds "padding-top: [Admin Bar height in px]" to the <html> element, so this feature mainly applies to elements with "position: fixed".

    Assuming that Admin Bar is displayed and is 100px tall at the moment, the following markup...

    <div data-adminbar-adjust="top max-height"></div>

    ... would result in this:

    <div style="top: 100px; max-height: calc(100% - 100px);" data-adminbar-adjust="top max-height"></div>

    Thanks to @Fokke for the idea 🙂

    • Like 4

  12. 57 minutes ago, Mike Rockett said:

    @teppo - in regards to Jumplinks 2 and composer support: the module utilises several composer packages, which at present are kept in the vendor directory of the module, part of source control. Just to be 100% sure, if I were to drop this from source control, this would force users to install via composer? If so, I'd need to leave it in there, unless you know of another way 🙂

    45 minutes ago, Mike Rockett said:

    @wbmnfktr - Hence why I'm needing some more info – not sure if any additional composer support has been added. Would be great if I could trigger an install during module install from the UI. 🙂

    Sorry, I've got nothing for this. At this point my suggestion would be to keep those packages in the repository. It's the only way that works seamlessly with the module installer in Admin, and I believe it makes more sense for your module than any of the alternatives I can think of. Anything else would reduce your potential user base significantly.

    I've gone the other way with some of my projects, but those have mainly been site profiles, so the context is quite different. While I agree that a native Composer installation integration could be nice, we're not quite there yet — at this point requiring Composer may make sense for hard-core developer-oriented projects, not much else.

    57 minutes ago, Mike Rockett said:

    On the topic of dependencies, I'm feeling inclined to push the minimum PHP version to the one that still has active security support, which at this point is PHP 7.1.

    Go for it! I've been putting out PHP 7.1+ content for a while now, and so far no complaints.

    It's perhaps worth noting that PHP 7.1 is well on its way to being obsolete as well: it's already past the active support phase, and in just over two months it will stop receiving security updates. While certain organisations may backport security fixes for 7.1 for a while after that, officially its really close to the end of its lifespan. Folks should be already using (or at the very least actively updating to) 7.2 – or preferably 7.3 🙂

    56 minutes ago, Mike Rockett said:

    I'd also like to drop support for ProcessWire 2.8. Any objections?

    Again: go for it 🙂

    I don't think that this will affect a particularly large portion of users (last time I polled this was in 2017, but even back then ~55% of those responding were already on 3.0), 2.8 itself hasn't been updated for almost three years now, and users of legacy versions can always keep using one of the solutions that work for said legacy setups.

  13. 13 hours ago, wbmnfktr said:

    BUT... not all screenreaders support that feature... all I found was kind of a mixed result.


    So true. It's a nice idea, but CSS content is indeed problematic.

    Sometimes you want to add otherwise meaningless (visual) content (like icons) with CSS content and it turns out that some screen readers read them out loud, which can be quite confusing. There's no aria-hidden for CSS content, so reliably hiding said content from screen readers can be a real hassle. On the other hand there are times when you actually want to provide content for screen readers with this technique – yet it turns out that some of them will happily disregard it.

    In my experience it's almost never a good idea to add content with CSS 😅

    • Like 2

  14. I may have missed some of the points made here (sorry in advance), but regarding links opening in new tab/window: please keep in mind that this is a problem from accessibility point of view.

    For typical desktop users with decent eye sight etc. this is usually not a problem – and in fact it may be nice in some cases that a link automatically opens in a new tab – but for most screen readers (apps, that is – and thus their users as well) it's a real problem. From what I've heard/read, it can entirely mess up their understanding of the context.

    WCAG advises that if you're about to open a link in a new window, you should provide a clear signal that this is going to happen. This can, for an example, be a note at the end of the link text: "(opens in a new window)".


    Opening new windows automatically when a link is activated can be disorienting for people who have difficulty perceiving visual content, and for some people with cognitive disabilities, if they are not warned in advance. Providing a warning allows the user to decide it they want to leave the current window, and the warning will help them find their way back, if they do decide they would like to go to the new window. It will help them understand that the "back" button will not work and that they have to return to the last window they had open, in order to find their previous location.

    If you care about accessibility, think twice before you use target="_blank". And for those cases where the client requests this, be sure to inform them that it will likely cause issues for some users. If the client still wants to go with it then by all means do it, but I've found this argument to resonate quite well with most sensible people 🙂

    • Like 5

  15. Hey folks!

    I've been a bit quiet here about Wireframe, but the thing is that I've finally got a couple of "real sites" (as in not my own projects) to implement it on, and that has brought up some new requirements and a few issues. I haven't had the time to dig into a whole lot of really new stuff (components and such), but I have made a lot of other updates to the framework. As such, Wireframe 0.6 was released late yesterday.

    (A release on Friday the 13th, consisting of a total of 13 commits – not being superstitious here.)

    I've been updating the docs at wireframe-framework.com as well, but some parts remain a bit outdated. A lot of what happened in this version doesn't really affect the use of Wireframe, but some things do – and one change may even break some existing implementations:

    • It used to be possible to set the view file or layout from Controller with $this->view->layout = "some-layout" or $this->view->view = "json". This has been deprecated and removed in favour of a setter/getter API: $this->view->setLayout("some-layout") and $this->view->setView("json"), and getLayout() / getView() for reading the value. In addition to some obvious benefits from type hinting etc. this also makes it harder to accidentally change something when you thought you were just passing a variable to the View 🙂
    • There are now three ways to perform actions and pass data from a Controller to the View: Controller::init() (triggered as soon as the Controller class is loaded), public methods (which are made accessible in the View as $this->method_name), and a new addition Controller::render() (called right before the page is rendered). In most cases where one might've used the init() method before, render() is a better choice, as there's less chance that code will get executed "unnecessarily".
    • In addition to existing Page::layout() and Page::view() methods there are now specific setters/getters: Page::setLayout("layout-name"), Page::getLayout(), etc. Original "unified setter+getter" methods may actually get removed at some point, as they're often ambiguous and make code arguably less readable.

    Quite a few other changes as well, some of which improve performance and others that make the API more polished. Some bug fixes too, though those mostly apply to what I'd consider "border cases" 🙂

    Here's the full changelog for Wireframe 0.6.0:

    ### Added
    - New Page methods Page::getLayout(), Page::setLayout(), Page::getView(), and Page::setView().
    - New Controller::render() method, executed right before a page is actually rendered.
    - New ViewData class for storing (internal) data required by the View class.
    - New getter/setter methods for ViewData properties for the View class.
    - New method Wireframe::getConfig() for getting current config settings.
    - New method ViewPlaceholders::has() for checking if a placeholder has already been populated.
    ### Changed
    - Various View-related features moved from Wireframe module and ViewPlaceholders class to the View class.
    - Removed access to local get* and set* methods via the PHP's magic setter method __set() and getter method __get() in the View class.
    - Redirect feature no longer fails if provided with a WireArray data type; in these cases the first item is used as the redirect target.
    - Improvements to PHPDoc comments.
    ### Fixed
    - An issue with Config class where the "all directories exist" message was sometimes displayed unintentionally.
    - An issue where View Placeholder values might've been overwritten because existence of earlier value was checked inproperly.
    - An issue where empty / null view file would be automatically replaced with value "default".

    On a related note, for this version I decided to give sonarcloud a try. For those who don't know it, it's a sort of a code quality inspector, and it's free for public projects. It didn't have a whole lot to complain about at this point, but it's good to have some sort of validation in place just in case. I will also be digging deeper into reported "code smells", as some of them definitely make sense to me 🙂


    • Like 8

  16. 15 hours ago, apeisa said:

    Thanks Mike!

    unfortunately we jut found another issue like this:

    Data too long for column 'request_uri' at row 1

    So there is similar issue at least with request_uri also (not sure about other fields). Any possibility to get this fixed as well?

    One more: I'm also seeing this error for the 'user_agent' column.

  17. Hi @Mike Rockett – I'm back with the endless requests 🙂

    How do you feel about supporting WireCache in MarkupSitemap, possibly as an alternative to (if not instead) MarkupCache? The thing is that due to hosting-related reasons caching in the database would be easier for me, while current MarkupCache implementation is slightly problematic.

    I could send you a PR (or merge request, as you're using GitLab) in case you're interested.

    • Like 1

  18. 2 hours ago, ryan said:

    @teppo I'm not sure why that is. Maybe it needs me to add a version tag to it to jog things loose? Anything else you can think of I should test or try from here?

    One idea would be visiting the Packagist GUI and using the "update" feature from there, and apparently there have been cases where simply logging in can help.

    I'd also make sure that the webhooks are still in place and functioning properly (I guess this depends on how you've set things up between Packagist and GitHub) 🙂

  19. On 9/5/2019 at 7:39 PM, netcarver said:

    What about, in principle, having an install-time option of making all non-standard files inaccessable unless whitelisted in the .htaccess file? If chosen, the installer could use a version of .htaccess file with rules that  whitelist .css, .js, .htm(l) and perhaps .json extensions by default, along with the usual image file extensions.

    A quick note on this one: while at first it sounded a bit over the top, I'm kind of warming up to the idea.

    Sure, there are problems and may not work in all situations, but it might make sense as an optional setting in the .htaccess file. There are already a number of optional sections in there, ones you can enable manually if they make sense in your context. This could be one of those: instead of blacklisting specific files, you could choose to disallow everything except for those you know your site to require.

    Just saying.

    • Like 2

  20. 2 hours ago, bernhard said:

    Is it worth the effort of refactoring my module to using .ready.php and .hooks.php extensions?

    I wrote a longer reply to the issue mentioned above, but long story short: yes. Currently the contents of these files can be (and by default will be) world-readable, which – depending on the use case, i.e. the code stored in the files – can be considered anything from "probably unexpected but mostly harmless" to "a major issue".

    As a quick fix you can include a .htaccess file in your module directory preventing access to files with .ready or .hooks extensions, but in the longer term I would definitely recommend refactoring the module to use standard .php extensions instead 🙂

    • Like 4
  • Create New...