teppo

Thanks @Mike Rockett, looks great so far – will test properly later ? The editor has indeed been having some issues lately. Pete has been digging into this, and we're keeping an eye out in case an update is released that would take care of this.

That's great news right there. Not sure how things have progressed since then, but the last I checked it seemed there were a lot of perceived problems with version 5, and the answer was always "this will be really difficult because we use this new data model". I'm sure that 5 will become a great editor, but whether it will become a great editor for HTML still remains to be seen ? I'm tempted to draw lines from the CKE5 to another work-in-progress content editor that has been in the headlines lately: Gutenberg. In both cases it appears that the team is pushing an idea they wholeheartedly believe in, while a notable percentage of their existing users are telling them that it's a massive mistake. Interesting times ?

That changes things quite a bit. Personally I've never been a part of this kind of team – as strange as it may sound, I've worked in teams where there are backend developers and so-called full-stack developers, but never a "pure" front-end developer ? You've definitely given me something to think about here! Features that are not tied to a specific template have in my use cases usually been partials with very little "logic" behind them, but this would actually be a nice use case for shared (sub)controllers as well, which is something I'll likely dive into soon. Basically the idea is to have a controller that isn't tied to a single template, but rather can be used by multiple templates. Also controllers that inherit other controllers – "base controllers", or whatever they might be called – is another way to achieve shared features. Overall there's a lot you can do with current codebase, but since there are different use cases, it's very much about finding a balance between "not opinionated enough" and "too opinionated" ? As for layouts, I've found the concept really useful, and since I use them in pretty much all projects I work on, this is something I wanted to have built-in and ready-to-use within Wireframe. Placeholders are a key part of this, as they provide an easy way to embed views (of which there may be one or more for each specific template) within commonly shared layouts –aAnd because layouts serve a different purpose from view files (individual views for templates) and partials (smaller pieces of content intended to be embedded within layouts or view files), I've opted to store them separately. This is again one of those cases where it's all about finding the right balance and figuring out what should be available out of the box and what to leave for individual developers to figure out on their own, and I feel that current split between layouts/views/partials is a reasonable one – but because I know there are different opinions, much of this is actually already configurable. Also, since layouts are optional, one can always opt out from using them ?

@Lance O., are you using Markup Sitemap XML, which is the earlier module from Pete, or Markup Sitemap, which is a newer one developed by Mike Rockett? As Dragan said above, you should always post module-specific questions to the existing support thread for that module. Let us know which module you're talking about, and I can merge this thread to the correct module-specific support thread. Thanks!

Sounds familiar ? SAML is actually a pretty simple concept. I'm not an expert, but to summarise: LDAP is a general purpose protocol for communicating with directory services. When it comes to authentication, typically the way you'd set this up is by providing a local login form (ProcessWire's native one or something else), and when the user has provided credentials, you use the LDAP protocol to pass them to the AD server for validation, and then – depending on the reply – either log the user in (creating user object in the process if necessary), or display an error if provided credentials couldn't be validated. SAML is a SSO standard for authentication. Here the identity provider (often ADFS or Azure AD) takes on more responsibilities: in the case of SAML Auth 1) the user attempts to access the admin or other protected area, 2) the module detects this and redirects the user to the IDP's web based GUI, where 3) (unless there's already an open session) the user has to provide authentication details, after which 4) IDP redirects the user back to the site with a SAML response, and finally 5) the module either logs the user in (creating user object if one didn't exist yet) or displays an error. The reasons I personally prefer SAML is that it's an SSO solution – which means that if the user is already authenticated to the AD server they don't have to authenticate again – and that the IDP actually handles a bigger part of the process, meaning that you don't have to pass credentials to third party services, etc. That being said it doesn't really matter that much which approach you use. If the client has a backend capable of using SAML, I'd recommend that, but if not then LDAP is a decent fallback. To be honest I'm not really familiar with the service layer, but most commonly you'll find some Microsoft product from the other end. If there's ADFS (Active Directory Federation Services), it should support SAML. On the other hand if the client is using Azure AD, there's actually no LDAP support at all (unless they also use Azure AD DS), so in this case SAML might be your only option.

Just checking: where / at what point of the installation process is this error coming up, and what does it say exactly? I'm currently testing this on a 3.x site and so far it seems to work. Note that if you're installing the module from the Modules section in the Admin, it will complain that the module hasn't been marked as compatible with 3.x. This alone doesn't mean that it won't work with 3.x, though it is good to be worried when you see a message like that ?

I get your point, and agree – to a point. When I first came across the idea of render functions (with that specific name it was some bit of code from Ryan I believe), this was exactly what I thought ? Since then I've used render-functions in numerous projects, and while in some cases it still feels a bit "dirty", in real world it can be a tremendously helpful strategy and hasn't really caused me any notable headaches so far – quite the opposite. These days I don't have a major issue with code that generates markup as long as it's clearly separated into its own container, i.e. "siloed" properly. While I don't encourage mixing business logic with presentation, this is one of those cases where the line is a bit blurry. Also, as a minor note I don't think that we should separate logic and presentation based on the language alone. PHP can be used to create "presentational" content, so overall it's more about what you do than how you do it. Something like Twig is supposed to be "purely presentational", but you wouldn't believe the complexity of some of the logic I've seen implemented in/with it. (But this is a topic for another discussion – templating languages vs. using PHP as a templating language, and so on and so forth.) Awesome! As far as I can tell this is actually really close to this rough idea I mentioned earlier – or, more precisely, it would be one possible use case for (or variation of) it: > Another idea I've been toying with would be subcontrollers (or child controllers, or partial controllers, or whatever terminology makes most sense) I'm not entirely sure if it actually needs to be a separate concept ("chunks", or whatever that would be called), but that's not necessarily a bad idea, if it makes the concept easier to grasp. Technically it should already be possible to instantiate a new Controller, provide it with a View file, and then render the output within, say, another Controller. That's what Wireframe itself does for the page, though it all happens automatically. Another thing that might not be obvious yet (I'll have to check the docs relating to this) is that there are two use cases for views: They provide alternative ways to render a Page. For an example the default view might render markup (HTML) for the entire page, and another might render an RSS feed for a list of news items. They can be used to populate View Placeholders: if you request <?= $placeholders->aside ?> in a layout file used for the "home" template and add a view file at views/home/aside.php, Wireframe will automatically populate the "aside" placeholder with the content of current page rendered with that view file. Anyway, I'll definitely dig into this topic a bit more and come back with some sort of solution, hopefully – thanks for linking to the TemplateEngineFactory example ? Thanks – this list was quite helpful. For the record, here's how I've handled these examples in my past projects: For menus I've used MarkupSimpleNavigation, and later MarkupMenu. In the boilerplate profile I do have partials for these, but they just call the render function of a markup module. Breadcrumbs is in my case usually a simple list of parents, thus I've used a "dumb" partial file with a foreach loop. Here's an example. Sidebar, again, tends to be either a single RTE field (something like sidebar, aside, or perhaps right_column or left_column), or sometimes a predefined list of multiple fields. Again a valid use case for so-called dumb partial files, but this is actually exactly the use case for which I originally added the ability to use View files as View Placeholders. Repeating elements covers a wide area of different content, but in my projects these have usually meant one of two things: A news list or something similar, with predefined header, list of items, and often some sort of "footer" area as well. These use cases I've usually solved with render functions. Repeater, RepeaterMatrix, or some other repeatable fieldtype. "Dumb" partials with some foreach rules, or native field rendering (particularly useful for RepeaterMatrix). Note that I'm not saying that your use cases are invalid, or that the list above would be the "correct" way to handle these. It's just that I can see why this hasn't been a notable issue for me – but this also helps me understand the kind of use cases you've run into, and thus figure out how to continue from here on ?

Great to hear that it works now. The problem with automating this is that I don't want to assume which templates should become searchable. That being said, I could add an install-time setting to pick templates to add this field to, or alternatively a module config setting that fetches this info real-time from templates. I think that'd be a pretty nice solution overall, so I've added that to my to-do list. There was – it just wasn't working quite as expected ? I hadn't tested this properly: translatable strings were defined and cached too early during the module's bootup sequence, with the result that the language of the user wasn't actually set yet, and thus you always ended up with the default (english) versions. This should be fixed in the latest release, 0.6.2. There's a basic demo here with most public-facing search-related terms translated: https://wireframe-framework.com/haku/. Sorry for the inconvenience, and thanks for digging out these issues!

Yeah, or do that (after updating the version in the module file) if you're in a hurry ?

In your .module file you've specified version 100 (1.0.0), so that probably overrides the value at modules.processwire.com. You should update your module file (in GitHub) instead, and the modules directory entry will auto-update after a while.

I'd first look into setting up SAML integration. Overall I think that a SAML powered SSO solution is always easier and more user-friendly approach. SAML Auth handles this quite nicely, though it may take a bit of configuring to get everything right, and it also looks like the module hasn't been updated in a couple of years – so I'd first make sure that there are no issues with the bundled OneLogin's SAML PHP Toolkit. ... and if there are, perhaps you could try updating it and submitting a pull request? ? There are some LDAP modules as well, and I actually have one just sitting on my local machine that I'd really like to share. It's a module I built in my last job for a client project, and I know it's powering at least one production site already, but I just haven't had the time to add the last finishing touches on it yet. Also, I don't really have a need for LDAP stuff in my personal projects, so there's that ? Anyway, I can't give a specific timeframe but I'll make a note to get the module finished and published.

Hey @VeiJari, thanks for your report ? Those warnings were fixed in version 0.5.1 – I keep forgetting that core classes don't use strong typing for non-object parameter values. Lesson learned: always develop with debug mode on (or use something else to display all warnings). "Indexed 0 pages in 0 seconds" isn't related to the warnings. This just means that the module couldn't find pages with your configured search index field. I've added a warning message for this situation, explaining what happened and what to check first (that your index field is actually added to at least one template with existing pages), but other than that I'd have to know a bit more about your specific setup to answer why this is happening. Additionally (with latest release 0.6.0) I've changed the defaults so that any non-trashed page with the index field is now automatically included. Previously the default selector for this feature only included public pages, which meant that hidden and/or unpublished pages were not indexed (via the "Index pages now?" feature, that is – saving the page itself indexed it as expected). -- If you're still getting a message that indexable pages couldn't be found, please let me know how you've configured the module, and which version of ProcessWire you're using. Also please make sure that you actually have indexable pages to begin with – unless you've specified a selector string for the "Index pages now?" feature, this is the selector that finds those pages for you ?

If you're interested in ironing this quirk out as well, here's one possible solution: https://www.media-division.com/correct-name-capitalization-in-php/ ?

Glad to hear that the error has disappeared ? The problem might've had something to do with your environment, but the resulting error is an interesting one. In this case something attempted to change current working directory into one that wasn't allowed, so PHP threw an exception – and since throwing exceptions from __toString() is not allowed, that resulted in fatal error instead. This seems like an unexpected result, so it might be worth investigating if it can be avoided, though I'm not sure if there's any sensible way around this. As long as __toString() does anything even remotely complicated, there's a risk of running into this issue.

Thanks for sharing this, EyeDentify – nice and simple ? Just a little note before folks go implementing IP logging: IP addresses are considered personal data, and as such you should keep GDPR (and similar legislations) in mind. Here's SE question that covers the details related to logging IP addresses: https://law.stackexchange.com/questions/28603/how-to-satisfy-gdprs-consent-requirement-for-ip-logging. (The general consensus seems to be that you don't need to ask for permission before logging IP addresses, but there are other requirements you do need to keep in mind.)

Hey Bernhard! Just a heads-up that I've moved this older RockMarkup thread to the Module/Plugin Development area. Please let me know if you'd rather prefer to have it merged with the module thread – though if we merge it, posts here will probably show up before the initial post in that thread, so it may look a bit weird ?

You may need to be a bit more specific than that: what exactly do you mean when you say that the URL doesn't work? Is the screenshot from your actual site, and if so, could you add a link to that? Or is this an example that you're trying to achieve? Note that I've merged your question to the Markup Simple Navigation support thread. When you have a question related to a specific module, post it to the existing support thread for that module – thanks!

This is included with the default .htaccess file, but disabled by default. See section "4. Protect from XSS with Apache headers". It seems to me that this should probably be enabled by default, but I'm guessing that it was left disabled for a reason – @ryan would be the best person to say if those reasons still apply.

Make sure that the translated versions have the %d placeholder as well – from your description it seems likely that they don't.

Absolutely agree with this – use case for the data matters a lot! In my experience MySQL queries (with decent indexes) tend to be pretty fast until you reach the scale of millions of rows, but if this is going to be a public-facing service that gets a lot of hits and needs to generate all sorts of reports real-time then definitely consider alternatives right from the get-go. Might be a good idea to look into them anyway, but if it's a one-off project and you're likely to stay in 200-300k record range, you're probably not going to get a major benefit out of them. That being said, if you already know what your data is going to look like, you can take some guesswork out of the equation by starting from a simple proof of concept: create a database table for your data, add a script that generates some 200-300k rows of random mock data based on your actual expected data format, and build a proof of concept graph to display said data. If the database concept doesn't pan out, i.e. it's too slow or something like that, you can just swap that to something more performant while keeping other parts of the application. Either way it's often a good idea to build your product in layers, so that if a specific layer – graph library, database, or something in-between – needs to be swapped for something else, other layers remain more or less the same ?

Technically yes. I'd still check early on that ProcessWire won't at some point try to load all those rows to memory at once, or worse yet try to render them all as inputs on page (in admin). I have a vague memory of Ryan adding something to handle exactly this to one of his modules or the core (or both).

Not sure how familiar everyone here is with the inner workings of ProcessWire, so just to expand on this a little bit: FieldtypeComments is a ProcessWire Fieldtype module, and Fieldtype modules can define their own database schema. The FieldtypeEvents module was built as an example for custom Fieldtype modules, and if you take a closer look at FieldtypeEvents::getDatabaseSchema() (and other methods in that class), you should get a pretty good idea of how this stuff works. On the other hand if you want to store loads of data and don't really need/want said data to be stored in an actual field (accessible via the API and editable in the Admin), you can also define a custom database table, just as Edison pointed out above. You can find some examples of working with custom database tables from the ProcessChangelog module. Of course you don't have to wrap the table creation etc. into a module – not unless you expect to set this thing up on multiple occasions ? One last point on naming custom tables: if you create a truly custom database table, you'll want to steer away from any native table names. This includes field_*, since that prefix is reserved for field data.

Linode (Linode 4GB): Contabo (VPS S SSD): By the way, updated my previous message. Didn't remember that I took the tiniest SSD package, not the medium one – so the price is not half but actually around a quarter of the Linode VPS. Admittedly this may be a bit small for some needs, but it should run all my sites just fine ?

The Linode VPS or the new Contabo one? ?

@apeisa @Soma Just noticed that the modules directory entry for this module still points to the old repository, and also doesn't list Multisite as being PW3.x compatible. Would it make sense to update the entry to point to Soma's repository? We just did a similar shift for AdminBar, and Adrian made the necessary changes in the modules repo. Also, I'm currently not entirely sure which branch I should use – last I checked it seemed that "dev" was the one to use, but since then that has apparently been removed (or renamed) and now there are two branches left: master and dev2. Master is the one with most recent updates, so is that preferred over dev2, or vice versa? Sorry for all the silly questions ?