teppo

@bernhard, out of curiosity (and since I'm currently also testing out SSE): did you figure out why exactly this was needed? Found a Stack Overflow post that pointed to nginx docs, as in that particular case it appeared that proxy buffering was the culprit. It has by default 4K or 8K buffer size, so it would seem to make sense that sending 8K+ spaces before real value solves the issue by effectively overriding the buffer. What I'm wondering is if that was also your problem, or if there are other potential causes for this as well? Seems kind of hacky having to send (relatively speaking vast amounts of) extra data with each response 😄

Hey Ryan! First of all, this all sounds very promising. In my humble opinion you are vastly underplaying your own skill in terms of design, but that's also why we can trust that you'll recognize amazing design once you see it. Looking forward to seeing what the team working on the design has cooked up 😉 Now, please forgive me for jumping directly into asking for stuff, but... I know this is small thing, but it would be quite nice if the new admin made use of CSS variables wherever it makes sense; colors, font sizing, etc. (Or provided them as an alternative for non-core tools to use, in case it is not feasible to use them for actual admin styling.) The reason I'm saying this is that I've built various admin tools that I wanted to look like the admin theme, and since there is (to my knowledge) currently no simple way to access existing colors etc. in CSS, any non-Uikit elements I've had to "hard-code" to use current styles. This includes the default green/cyan/blue color theme, current spacing and font size practices, etc. As a result said custom elements may look out of place once the theme is updated 🙂 (Just for the record: SCSS/LESS might be an option, but that feels like a lot of unnecessary overhead and complexity where vanilla CSS would easily suffice. I'd really like to avoid that if possible, and to me it seems like CSS variables are an easy and well supported alternative.) Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

Thanks, I’ll look into this soon. I’m using MariaDB almost exclusively, and it seems that this is not an issue there. There seems to be one potential gotcha with the suggested solution: https://stackoverflow.com/questions/45494/mysql-error-1093-cant-specify-target-table-for-update-in-from-clause. Might be better to do two queries instead.

At this point it's a bit hard to put myself in the shoes of someone just getting here, but some highlights from the top of my head: The community is awesome 🙂 The ability to define and modify data structures in the admin using an easy-to-use GUI is still a huge deal. One can quite literally create a full-blown application just by clicking around the admin, especially when combining it with something like ListerPro (though that's a commercial tool, so may be a bit off scope here). Even for those with zero programming know-how, getting a simple ProcessWire powered site (or app) up and running is a (relatively) easy task. Selector engine makes querying data extremely easy, and selectors also scale exceptionally well for complex needs. Most beginners are unlikely to need to know how sub-selectors or OR groups or more complex operator types work, but there is a lot of flexibility hidden underneath. For those that have worked (or fought) with WP_Query, our selector engine is a major selling point. Right out of the box there's a lot of stuff there that even some of the most advanced content management systems don't have — custom content types, amazing language support, numerous field types and inputfields, etc. Honestly, the language support alone is more advanced than anything I've seen in other systems so far, with or without plugins. While it's impossible to compete in numbers with WP, there are actually a lot of high quality modules for ProcessWire. One probably won't be able to carve out a custom application just by slapping modules on top of modules, but there's a whole lot of stuff that they can do. Once you're familiar with the system, extending it with modules and/or hooks is easy. Did I mention the community? Also, ProcessWire is open source and free to use with no strings attached. Unlike some other systems. (Sorry, had to go there.)

It's possible that I'm still missing the point, but if the underlying problem is that there are multiple data sources with differing data formats, there are only two top level approaches that I can think of: write a separate import script / profile / configuration for each data source, or write an adapter per source that converts them to single, uniform format, which you can then import. For me personally scraping is never the preferred option, as it comes with a number of potential issues. For one you may not be able to scrape all relevant data, or you may get malformed or partial data — and you may not know it before it is too late. Getting your hands on the raw data is almost always much, much better. At the very least I would contact each vendor before scraping to confirm that a) they think it is doable and b) it won't result in them blocking you due to your scraping tool exceeding rate limits etc. If you can't make sense of the data format you've got, ask for some kind of documentation. The worst case is that you need to figure things out on your own — that can easily lead to nasty issues, as your assumptions could be completely wrong. If there is no way to get solid documentation for the data, let your client know that it's essentially a guessing game at this point. Especially when money is involved that's not a great situation to be in. Anyway, from what I've heard so far this all seems completely doable, but could obviously get pretty time consuming — and hence costly 🙂

https://github.com/teppokoivula/ImportTool was built to handle a similar need, in case you want to check it out. It’s most useful for imports that may be needed again later, though; the idea is that you define an import profile, which can then be executed via the admin while also providing an input file for the data. Depending on the data I usually set limit somewhere between 50-500 pages and set the “on_duplicate” setting for the profile to “continue”. This way you can keep running the same import profile with the same data file until you’re done. This module is a bit unpolished, but in use on a few of our sites 🙂

@Ivan Gretsky, this feature is now in master branch (0.31.0). Though please test a bit before putting it in action 🙂 Regarding this, I gave it a bit of thought and added something that I hope makes sense to you: if the view prefix value has exclamation mark as a suffix, e.g. "!theme/", it will be considered a strict value. If that's the case, the exclamation mark is automatically stripped from the view prefix, and in case a view file with the prefix can't be found, Wireframe should act like it didn't find a file at all. I'm definitely open to revisiting and/or tweaking this behaviour. My motivation here was mainly to a) find a solution that feels intuitive without introducing too much complexity, and b) preferably avoid adding more configuration flags. I didn't really have a lot of time to test the latest changes yet; hopefully I got them right, but please let me know if I've caused any new issues 🙂

Good question. Version Control is not currently under active development, but not abandoned either. For an example if anyone wants to contribute, I’m always happy to go through pull requests 🙂 I don’t currently have much use for this module myself, and it’s a bit of a beast so working on it tends to be time consuming. Not a great combination. That being said, I’ll add a reminder to get back to the posts in this thread as soon as possible. Notifications are not working so well for me, and I’m pretty awful at checking module support threads manually.

@adrian, that should already be there, but it requires specific permissions: https://github.com/teppokoivula/ProcessLoginHistory/blob/b14b68286a4df41b2b7beb5ada6e38e90e81d2b1/ProcessLoginHistoryHooks.module#L235

Yes, it does. As others have pointed out: if you only want to index a single page, indexPage($page) is the correct method — but I also have no idea what the purpose of that would be. My guess is that it was either added due to some kind of misunderstanding, or perhaps you indeed did want to recreate the full index every time a page is saved. If it was the latter reason then that might make some sense, but it is also a very bad idea in terms of performance (as you've noted here) 🙂

@Ivan Gretsky, just wanted to let you know that I'm currently working on the theme feature, but it will require a bit more testing at least. Admittedly this was a bit more complicated than I had originally assumed. That being said, I've just pushed an initial version with a new "view prefix" feature to dev branch, in case you have time / want to give it a try: https://github.com/wireframe-framework/Wireframe/tree/dev. This is pretty much the first option that you described. I ended up rewriting it a couple of times, though, but hopefully have now landed on a solution that makes sense. View prefix can be set in a couple of different ways, but likely the easiest is calling Wireframe::setViewPrefix() in the bootstrap file (wireframe.php): // init Wireframe $wireframe = $modules->get('Wireframe'); $wireframe->init(); // if we're on a theme page, set view prefix if ($page->template == 'theme-home') { $wireframe->setViewPrefix('theme/'); } // render the page echo $wireframe->render(); View prefix will be used whenever Wireframe is rendering a (template/page) view file, component view file, or partial file. It should also work with separate renderer modules, but that's not something I've yet had a chance to test. At least for now default view files are used in case a prefixed version doesn't exist. This could be made configurable, but it felt more intuitive to me that this is (at least) the default behaviour. Note that in the example above I've intentionally used a prefix that is a path, e.g. has "/" — it's not necessary to use a path, it could just as well be something like "alternative-" 🙂 And a big, big warning at the end: I quite literally got this thing up and running half an hour ago. I've done very little testing, so it's entirely possible that there are still issues with it. I hope to get back to it and test properly soon.

Hey Ivan, I'll have to get back to this later, but just wanted to say that this is an interesting idea. I've never really gone further than specifying a different layout file for different themes — so basically they've all had their own layouts, styles, etc. but still shared the same template specific views. And had a shared pool of components and partials. Both of your ideas sound feasible, but I must admint that the overrides/theme folder sounds "cleaner". It would probably be conceptually similar to WP child themes, e.g. you can override some features, but those that have not been overridden are the same as in the "parent theme" — right? That being said, the first one sounds like an easy to implement thing as well. I'll have to take a closer look at the code to be sure.

Exactly. Composers are useful for cases where we need to share data among different views, or certain types of views. Say, you want all your component views, partials, or perhaps field specific render files to have access to some shared data. Or you have a set of "conceptually related" templates and/or views that all need same variables. In the context of WordPress / Sage I've used this for things like shared settings, details about current session (such as user specific content, or some stats that I don't want to fetch/calculate multiple times, or in multiple locations), blocks of data that all events or news/articles share (such as a list of latest news/events), etc. You can achieve similar results via the bootstrap file (e.g. /site/templates/wireframe.php), and for some use cases it works very well. Especially when combined with utility classes or feature modules. But if there are a lot of "if template is x then..." type if-statements there, it can get a bit out of hand. Not to mention that some things are not automatically passed to all views. Anyway, the main reason I've not jumped right into this is that I'm also debating whether it truly makes sense. I do like the concept and it "feels right", and could potentially be beneficial outside of Wireframe as well. But at the same time I'm not too keen to introduce new concepts just because they sound fun 😄

Hey @Ivan Gretsky Going fine, just been busy and all — so nothing new really 🙂 I don't have new features in the works right now, mostly because for the type of projects I've been working on recently I've felt that it's more about the stuff that's outside Wireframe than in the scope of it that needs work. But since you asked, there are some ideas I've been thinking of adding. Either as a part of the framework, or as a stand-alone things. One of these is Composers, likely similar to what they've got in the Sage theme for WordPress: https://roots.io/sage/docs/composers/. Honestly still not sure how good an idea that one, but I can see some benefits, and it might be fun to experiment on 🙂 Makes sense to me, so I've added a new method for that. Usage looks like this: $wireframe = $modules->get('Wireframe'); $wireframe->initOnce(); // pass in an array of Wireframe dir names, or null to create all; defaults to null, // default value is an array with dir names as keys and disk paths as values $dirs = $wireframe->createDirectories([ 'lib', 'views', 'layouts', 'partials', 'resources', 'components', 'controllers', 'dist', 'resources', ]); Note that this is not well tested, and there may be situations I've not accounted for 🙂

I hate to break it to you, but... you are now 😉 Seriously though, thanks for sharing this module!