Jump to content

teppo

PW-Moderators
  • Content Count

    2,349
  • Joined

  • Last visited

  • Days Won

    57

Everything posted by teppo

  1. 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/ πŸ™‚
  2. teppo

    SeoMaestro

    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.
  3. 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.)
  4. 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 πŸ™‚
  5. 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!
  6. 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.
  7. Make sure that the translated versions have the %d placeholder as well – from your description it seems likely that they don't.
  8. 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 πŸ™‚
  9. 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).
  10. 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.
  11. 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 πŸ™‚
  12. @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 πŸ™‚
  13. For regular users there are usually cheaper (and quite likely easier) options than AWS. For an example I'd like to host my sites on AWS – the tech is fun, and it'd be useful experience overall from a professional point of view – but the pricing is really high compared to regular VPS solutions. Not to mention that in most cases I really do just need a VPS, so I wouldn't benefit much from the full AWS stack πŸ™‚ I'm currently hosting my sites on Linode as well ($20/month), but also experimenting with Contabo. So far so good, and the pricing is a quarter of what I've been paying for Linode – in fact even less, considering that my test server has more horsepower than the one at Linode.
  14. I think trasferring it to me would be best, whatever this means in practice πŸ˜… I'd rather keep the current name if it's an option. No need to confuse folks by new forks.
  15. That'd be fine with me. To be honest I've been meaning to fork it (under a new name) and take the concept a bit further – mostly visual / UI stuff, really πŸ™‚ If you edit the modules directory entry you can change URLs and the "forum name of the author". Might be enough in the short term? Anything other than that probably requires help from Ryan. I haven't been using this module much on my own projects either. For client sites I've been in the habit of always setting it up, though the modal / dropdown editing thingy is usually disabled. Basically it's just a simple way to provide necessary edit/add/profile/logout links (which should be there in the front-end anyway). Sure, I could add those links to some template file, but why bother when there's already a module for that πŸ˜‰
  16. One last update for the day: master branch of the module is now at 0.5.0. This includes both the rendering features mentioned above, and a slightly more polished theming feature, where each theme can declare custom markup, styles, scripts, strings, etc. More details in the README file.
  17. Just for a test copied this to /site/init.php, removed bd() calls (don't have Tracy installed), and it worked like a charm. 404 page gave me "test". So... another module, another hook, Tracy (?), or something else interfering? You mentioned site/ready.php and init() of an autoload module, but in my test I used site/init.php. That probably shouldn't matter in this case – though not 100% sure πŸ™‚
  18. It's true that this is a bit tedious – to say the least πŸ™‚ The indexer doesn't currently have stemming support or anything like that built-in, which means that it can only find exact matches. I'd love to include something more elegant, but I'd first need to find a solution that works reliably across multiple languages – at least German, Swedish, Finnish, and English, since those are the ones I personally need most, and that would probably cover a large part of the audience here. If such a feature does get added, it might also make sense to distribute it as a separate module (which wouldn't be particularly hard, really). By default the module uses "%=" selector, which I've personally preferred over "*=".This is partly because I actually want partial matches, but also because back in the days the "*=" selector didn't seem to work too well with Finnish content. This way I'm not constantly worrying about MySQL quirks, full-text stopwords, etc. Anyhow – I just experimented by changing the selector operator to "*=", and now the only hit is the "Why use Wireframe?" page, which has the word "battle-tested" on it. Default selector is configurable via site config, or you can pass custom selector in if you query results yourself, and that might actually be enough to resolve some issues already. Currently there are a lot of options that are only configurable via site config (code), but I'll probably add these (selectively) to the admin as well. It's just a lot easier to add them in code first 😁 (Edit: on a second thought I'm probably going to switch the default selector to "*=". Seems like it will be better for most users, and those who don't like it can always change it.) Finally, the description text shown on the search results page is pretty "dumb", currently defaulting to the value of the summary field. Obviously that won't do for sites that don't have this field, but it's there for most default profiles, so that seemed like a reasonable starting point. In my own projects I'd probably make that "meta_description|summary", since those fields will always be there, and they are pretty much exactly what a view like this needs. I'd love to create the summary from the index so that it can always (or nearly always at least) show a piece of text that matched (kind of like Google does), but since the index is essentially a whole lot of mismatched text stuck together, that would often look pretty awful. Google does these "custom excerpts" well – obviously – but even Relevanssi (which is the de facto search plugin for WP) struggles with this part and in many projects produces unreadable mess when the custom excerpt option is enabled. (Mainly because such a feature is a nightmare from a logical sense.) Awesome! πŸ™‚
  19. Another quick update: rendered search feature is now visible at https://wireframe-framework.com/search/. Entire content area (between main menu and the footer) is rendered by the SearchEngine module. The rendered version (if bundled styles are used, which is optional) should look more or less like that on most sites – obviously site styles come into play, so it may be a bit off and require tweaking, but that's to be expected πŸ™‚ Pager is now included as well, but on this site you'd have to search for something silly like "co" to see it in action. The default limit is set to 20 results, and the site doesn't have that many pages to begin with. The styles are organised into "themes", which currently means any number of custom CSS and/or JS files, but I'll probably expand these to include custom config files as well sometime soon. This way it should be easy to create multiple built-in themes to select from (for different frameworks or whatever). The render feature is currently only available via the dev branch of the module. I'll test it a bit more before merging to master – probably tomorrow πŸ™†β€β™‚οΈ
  20. The way markup generation is currently implemented can be seen in the dev branch at the GitHub repository – it's pretty easy to grasp by taking a look at the render settings in the SearchEngine.module.php file: https://github.com/teppokoivula/SearchEngine/blob/dev/SearchEngine.module.php#L70:L124. Instead of defining big chunks of markup in one go, I've tried to make the rendering "atomic" enough to allow for pretty much any kind of modification. Technically a framework-specific version could mean just alternative 'classes' and 'templates' arrays, and of course whatever custom styles might be needed. Not sure if I got your point right, though, so please let me know if this seems very different to what you were thinking πŸ™‚
  21. Quick update on this module: got a bunch of rendering features almost ready to ship. Still need to add paging support and may add a "fast mode" that always returns default markup (not sure how important that would really be, it's just an idea I've been tinkering with), but that's just about it. I'll probably bundle the (optional) styles – and later scripts – with the module, just to provide a decent-looking default state right out of the box (for actual use or testing). Also, I'm thinking of adding a "load more" alternative to paging, but that'll probably be a later addition. Somewhat off-topic, but I've been going back and forth with BEM: sometimes I love it, but often it just complicates things and makes both CSS and markup hard to maintain. Nevertheless, in a project like this it's just brilliant! By declaring search form, results list, and a single result as separate components, I can quite easily style them individually, not worry too much about messing with site markup in general, and it's also really easy to override just s specific part of the default styles in site-specific styles. Anyway, currently the ("full", i.e. a form and a results list) rendered state looks like this:
  22. Each indexed field should be declared (named) in the config setting mentioned above, or via the "Indexed fields" AsmSelect field in module config. If you have a lot of fields to add, this may of course take a while, but generally unless you have a whole lot of fields it shouldn't be a major issue. Also, SearchEngine doesn't (currently) distinguish between Repeater/PageTable/RepeaterMatrix content: if they contain indexable fields, the values from those fields are indexed as part of the parent page's search index. Though now that I've said that last point out loud, I think that content from repeatable fields should only ever be included in the (parent page's) index if those fields are set to be indexable as well. I'm going to make this change in the next release πŸ˜… Edit: done now (0.3.2). Repeatable fields need to be included in the indexed_fields array before their values can be stored in the index. This is really how it should've been from the start. -- Note that if you use the config setting instead of module settings for "indexable_fields", it's possible to generate that list of fields programmatically. I.e. you can define some hard-coded field names, and then merge that array with another one you generate with code. I'm not sure how efficient that would be, but it's doable at least. Additionally there are various hookable methods in the Indexer class included with SearchEngine, so if you need something more specific, you can always hook into those and change what gets indexed.
  23. Both the list on the Modules page and the fieldtype select on field edit screen expect fieldtype module names to start with "Fieldtype". BaseFieldtypeRuntime starts with "Base", so it's grouped under "Base" on the Modules page, and also not included in the fieldtypes (wire)array managed by the core (see /wire/core/Fieldtypes.php).
  24. Was afraid someone would ask that πŸ˜‰ No, not really a good example. I've been testing the module at wireframe-framework.com and just now added a couple of lines of code to get a very crude results list up: https://wireframe-framework.com/?q=composer. The thing is that I don't have a clean implementation for a results list (or a search form etc.) built into the module yet – that's something I'm going to add next. I've got some sites on the way that all need this feature πŸ™‚
Γ—
Γ—
  • Create New...