Jump to content

teppo

PW-Moderators
  • Content Count

    2,731
  • Joined

  • Last visited

  • Days Won

    79

Everything posted by teppo

  1. I guess it depends on your point of view. I can see how "always compare old to new" might make sense, but personally I prefer current approach, which is basically just "selected revision compared to any other revision". At least for now I think that current approach is straightforward and makes sense (without requiring additional UI tricks, such as the one used by Wikipedia) πŸ€·β€β™‚οΈπŸ™‚
  2. Hey @Manon! This seems like a good idea, so I've gone ahead and implemented it in Version Control 2.x (available via the dev branch int the GitHub repository). Note that if you're using Version Control 1.x, this update is not available there β€” I'm planning to merge the dev branch into master soon (this year at least), making 2.x the default version, and as such I'm not going to make any additional feature updates for 1.x releases.
  3. Just a quick heads-up that Wireframe 0.17.0 went live a few hours ago. Versions 0.15.0 .. 0.17.0 mostly included behind-the-scenes improvements and refactoring for existing features, so didn't think these were particularly interesting. Full changelog can be found from CHANGELOG, as usual. Probably the one and only feature that might come in handy during development is the shortcut method for defining view template and view at the same time (to use a view from a specific template instead of current one), added in 0.16.0: <?php // find blog posts and render them using the "list_item" view of the "article" template: ?> <ul> <?php foreach ($pages->find('template=blog-post') as $post): ?> <?= $post->setView('article/list_item')->render() ?> <?php endforeach; ?> </ul> On a loosely related note I've removed the "WIP" label from the topic of this thread, and am considering submitting the module to the modules directory. I think it's long overdue, really πŸ™‚
  4. Hey @Jessie! I'm not familiar with this particular error, but the first thing I'd try would be to upload the wire directory again. FTP connections are somewhat prone to errors, it seems, and a missing or corrupted file could possibly explain this. If that doesn't help: Which version of ProcessWire are you using? What's the PHP version on your server? Also: I'm assuming this is a vanilla ProcessWire setup, and you don't have any third party modules installed? At least int he past the CropImage field has had similar issues, so if this isn't the built-in Image field we're dealing with, that'd be good to know. Sorry for not being able to provide a clear answer; hopefully we can figure this out without too much hassle πŸ™‚ As a general rule of thumb: never change anything within this directory. Wire is not meant to be edited.
  5. Hey @adrian! Just wondering: what's your take on extending current panel collection with custom tools on a case-by-case basis? Sorry if this has been discussed already, there's so much stuff in this thread that I can't keep up anymore πŸ˜… I just had a quick look and it seems that adding new panels is currently not possible without directly modifying the module file(s) and dropping the class file to the panels directory. I was wondering if you'd be open to adding some way of "injecting" custom panels from outside the module? My initial idea was something along the lines of allowing custom options to be pushed into the allPanels array by passing it to hookable methods at certain points and adding support for array values so that custom panel options could contain both name and path. (I didn't actually try this. It's possible that hooks won't work due to load order and all that, so another option would be the Tracy module reading them from config settings; not quite as elegant or robust, but pretty much guaranteed to work.) Anyway, just throwing in ideas. I'm working on some Wireframe related dev tools, and was thinking that it'd be neat to have them available in the admin β€” and what better way to do that than to introduce them to Tracy... πŸ™‚
  6. This issue is resolved in the latest version of WireframeRendererBlade. Let me know if the problem persists, though πŸ™‚
  7. Thanks, @mlfct. This seems to be related to the WireframeRendererBlade module β€” I've opened an issue for it here: https://github.com/mauricius/WireframeRendererBlade/issues/1. Simply put the Blade renderer appears to expect component views to be found from /site/templates/views/[component name]/[view name].blade.php, while Wireframe expects them to be at /site/templates/components/[component name]/[view name].blade.php πŸ™‚ I would recommend keeping tabs on that issue if you want to use Blade. Twig implementation shouldn't have the same issue, though.
  8. @mlfct, what version of the module do you use? I recently changed a few things that might've been related, so there's a chance that it's fixed already. That being said, I don't use twig/blade myself, so if the issue still exists in the latest version, I'll have to dig in to see what's going on. Also, thanks! I'm really glad to hear that uou've found Wireframe useful πŸ™‚
  9. Changelog for Wireframe 0.14.0: ### Added - New ComponentView class, as well as the ability for component views to access Component class public methods as properties, in the same way view files and layouts can access Controller class public methods. ### Changed - Hook related code moved from Wireframe module to separate Hooks class. - Accessing public class methods as properties in view files were moved into new trait MethodPropsTrait. This is used internally by Controller and Component classes. - Some minor improvements related to dependency injection within Wireframe objects (and ProcessWire objects instantiated by Wireframe.) @bernhard, what you suggested here... ... is now doable. The way it works is just like with Controllers (this functionality is provided by a new shared trait behind the scenes): <?php // component class namespace Wireframe\Component; class Test extends \Wireframe\Component { public function hello() { return 'world'; } } // component view hello <?= $this->hello ?>
  10. JavaScript πŸ˜‰ The easy way out would be to include both phrases (possibly one as a default and other as data-attributes or something similar), and then switch those as needed. You could also fetch entire blocks based on user selections, but that would result in some overhead. Alternative would be to set a variable in .htaccess based on cookie value, and then modify the ProCache rules to serve files from another directory. In this case, though, you'd likely need to use hooks in order to make ProCache store (and clear etc.) two different versions. This approach seems a bit over-complicated for my taste πŸ€”
  11. Yes, that's the intention. I actually assumed that these were field values, but if not, then yes β€” you'll have to define them here as well πŸ™‚ This is a little off-topic, but if/when you store custom non-field values within a Page object, I would recommend prefixing them with an underscore. It's not a big deal, but can make it a little more obvious that these are not actual field values. Also, ProcessWire will never save a property such as $page->_some_key to the database, so this way it's impossible to accidentally overwrite some *real* (field) value.
  12. Perhaps I'm missing something, but couldn't you do something like this in a saveReady hook? $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'book') { $page->my_sort_field = implode(' ', array_filter([ $page->subject, $page->cleanauthor, $page->cleantitle, ])); } }); ... and now that your sort field (which could be a hidden text field, or a textarea if there's a lot of data, which I assume is not the case) contains a single value, you can sort results by that. As far as I can tell the only issue here is that you'll basically have the same data stored multiple times πŸ€·β€β™‚οΈ (Unless I've misunderstood you, and you actually want to keep all books that have a subject before any of those that don't, etc. But in that case a simple sort by multiple field seems enough.)
  13. If you mean a form for public (possibly unauthenticated) users to send data with, I would strongly recommend checking out Form Builder. It's not free, but it's well worth the cost.
  14. Collecting super long referrer values seems pointless (they're likely spam anyway), so truncating seems like a good approach. And the same applies to UA string as well πŸ™‚ -- Edit: just checked a few log files, and I've got similar errors there... and some of these: Exception: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'user_agent' at row 1 (in /site/modules/ProcessJumplinks/ProcessJumplinks.module.php line 534)
  15. Hey @ryan! This is very loosely related to the weekly update, but I noticed that this week (as well as in some earlier updates) you've started converting $this->wire('api_var_name') to $this->wire()->api_var_name. Just wanted to ask if there's some benefit to this, or if it's mostly just a matter of taste? πŸ™‚ Not a big deal by any means of course, but I've been writing stuff like wire('session') all over my modules, so wondering if there's a reason why I should rather prefer wire()->session etc.
  16. Thanks for setting this up! πŸ™‚ Of course this won't be a problem for everyone, but personally I avoid direct downloads. Here are a few reasons: With direct downloads I can't easily validate the package to make sure it is indeed the original one in case the server has been compromised or something along those lines β€” which of course is something that shouldn't happen, but in this regard I have more trust in GitHub than individual hosting providers / server maintainers. GitHub (/ Git) allows me to see and track the full change history in case something doesn't work. This way it's easier to track what change caused the problem, why it was made (commit message), and (assuming that the module author is somewhat active on GitHub) file an issue or even submit a fixed version for approval. Finally, I prefer to handle updates via either Git or Composer. It would be too much work to keep track of different blogs for individual modules, let alone download the module package every now and then to see if it has changed . GitHub makes this trivial (periodic git fetch or git pull is quite enough). No pressure, but big thumbs up from here for always uploading modules to GitHub πŸ‘ŒπŸ˜…
  17. I'm going to start from the end, because this is the easy part (maybe) πŸ˜… First of all, all the main concepts found from Wireframe have been around, in one form or another, for about a decade. Wireframe (the module) was developed a couple of years ago, and components were added about six months ago. Partials have been around since the very beginning, while components are a brand new thing. As for "should there be both partials and components", this is a good question going forward: Components are more versatile, but also more complex. There's a class (for business logic) and one or more views (for markup). Partials are a lot simpler. Even though you can pass params to partials and arrange them in directories by type or whatever, they are essentially just individual include files. In my typical project there's a need for both: by default I prefer the simplicity of partials, but if I really need to do something more complex on a per-element basis (justifying the mental and technical overhead of the class based approach), I go with a component instead. Heck, in one recent project I even surprised myself by using components within components. Not what I'd call an "easy to grasp setup" (which is always something that I try to emphasize in my work), but it gets the job done and was fun to work on. Will components and partials eventually merge into one? I don't know β€” maybe, maybe not. For the time being I quite like having them both around. In my projects they tend to solve different problems, even though they could be used interchangeably πŸ™‚ Oh, I'm sure that this makes a huge difference! As I've mentioned before I haven't really used custom Page classes, because β€” for my use cases β€” controllers provide same benefits, and then some more. Nevertheless, had custom page classes existed when I started working on Wireframe, there's a good chance that I would've taken an entirely different route πŸ™‚ I might've already touched some of the same topics earlier β€” particularly the one about having more than one type of object in Wireframe β€” but a few additional notes on this: You don't have to use anything you don't need. Layouts, views, and controllers are all optional. In many of my projects there's one layout, a bunch of views (often much fewer than there are viewable templates, since many templates are so simple that the layout file takes care of all the markup), and a few controllers (just for those templates that require something "more complex" behind the scenes; news or event containers / lists, page search, etc. The "everything is a component" approach is quite possible with Wireframe, though that was never really something I intended (or expected, to be honest!) The roots of Wireframe are in the MVC architecture, and that's where controllers, view, and model (which in this case is actually ProcessWire) come in. Components were intended as something that you can use to "fill in the gaps"; a bit like utility classes, for that matter. When you say that "Controllers are tied to the template of the viewed page", that's actually not entirely true: by default Wireframe will indeed only know that for a Page using the "basic-page" template it should check if a controller class called BasicPageController exists... but you can also make multiple pages share a single controller, change the controller on the fly, etc. Much of this is pretty new and I'm still experimenting with it, but I have high hopes that it will become even more useful in the future. As for the "couldn't that also be handled by the component" part: controllers do certain things that components don't, there's always exactly one controller active for a specific page at any given time, and these two work in a different context. The context of a controller is a page render request, while the context of a component is much smaller β€” essentially the subset of the request that it has been provided with. In my opinion it's best to keep them as separate concepts β€” at least for the time being β€” though once again who knows what will happen in the future πŸ€·β€β™‚οΈ I hope I don't really need to say this, but... feedback, comments, and (constructive) criticism is always welcome. I can't promise that I'll agree with all of it, but I'm happy to hear others' experiences nevertheless πŸ‘πŸ˜… -- I'm pretty sure that you've seen this already, but I've got a couple of site profiles online β€” https://github.com/wireframe-framework/site-wireframe-docs and https://github.com/wireframe-framework/site-wireframe-boilerplate. These are a bit dated by now (neither uses components, for an example), but they may provide some insight into the way I personally use Wireframe. I've been really looking forward to revisiting the weekly.pw website and sharing that as well, hopefully something I can get done before the end of the year. This site is also really, really dated (both visually and feature wise), and I'd also like to show off some of the new stuff in Wireframe πŸ™‚
  18. Wireframe 0.13.0 went live a while ago. This version introduces only one new feature: variables sent by controller to the view β€” as well as $partials and $placeholders β€” now work as-is while rendering fields (= in field templates). In previous versions these were accessible via the $view API variable, which didn't feel quite as intuitive. This required a new hook so there's a bit of added overhead, but at the same time various optimizations were made here and there, so this is unlikely to be noticeable. One thing to note is that this version contains a few breaking changes, though I'd be a little surprised if they affected any real sites: some Wireframe methods were converted from public to protected (these were never really intended as part of the "public API"), and the first argument for Controller class constructor method is no longer an instance of ProcessWire (this wasn't actually necessary). Here's the full changelog: ### Added - New hook makes View properties directly accessible in TemplateFiles (e.g. when rendering field templates) ### Changed - Wireframe::getController() is now a public method that can return current Controller instance, the Controller instance for provided page, or a Controller instance for provided Page and template name. - Visibility of following methods was changed from public to protected: Wireframe::___checkRedirects(), Wireframe::___redirect(), Wireframe::___initView(), Wireframe::___initController(), \Wireframe\Config::getCreateDirectoriesField(). - Controller class implementation was streamlined: new objects are wired using the native wire() function, and thus Controller constructors no longer require the ProcessWire instance as an argument. - Wireframe no longer caches partials unnecessarily, plus new Partial objects are automatically wired. - Various minor optimizations, some code cleanup, and a few improvements to comments.
  19. Hey @bernhard! I believe this is the same concept that was discussed earlier, i.e. having direct access to public component class methods from the component view? If so, I'll be sure to dedicate this some thought soon, and if it does indeed seem like a good idea, I'll try to get it implemented for the next release (after 0.13.0, which went live a few minutes ago) πŸ™‚ I'm leaning towards adding this feature, but the added complexity still worries me. Just providing access to public methods of the class is one thing, but if I go on and add that, I pretty much have to add at least the (runtime) caching support currently provided by the controller to make sure that devs don't accidentally step into a really nasty performance trap. And if I add this, for the sake of consistency I have to consider also adding support for persistent caching, method aliases, disabled methods, and a few other things. Anyway, this is just me thinking out loud. I'll see what I can do about this in the near future πŸ™‚ I've added your idea about catching errors and logging them to my todo list. Not entirely sure about this one yet, but it's definitely worth thinking through.
  20. Hey @Brian Peat, Sadly I'm not able to answer your question β€” hopefully someone else can! β€” but just a quick note: "Landing Pages" is not a native ProcessWire concept, so presumably that's something that the original developer of this site added while setting things up. You also mentioned "widget template", and that (widgets) is another thing that isn't vanilla ProcessWire stuff. All in all the thing with ProcessWire is that since there's no "one true way to build sites", it can be hard to say much about the site in question without seeing the source code πŸ™‚ Normally all you need for a custom template to kick in is... Create a new template in the ProcessWire Admin and assign fields etc. to it. Create a page and select your newly added template as the template. Add a template file at /site/templates/your_template_name.php. View the page on the frontend and ProcessWire will render it using the your_template_name template and your_template_name.php template file. In case this is not the normal workflow with this site, I'd start by checking which modules are installed (look for something that might affect page rendering). Then check which template files the site has, and if one/some of those are using URL segments to achieve some sort of custom templateish effect. If at doubt, you can paste some code here β€” just make sure that there's nothing secret in there (keys or passwords etc.) Hopefully this will lead you to the right direction. ... and by the way: if possible, I'd try to contact the original author of the site. And make sure that they didn't leave any documentation (it'd be the decent thing to do, but obviously not everyone does that...) πŸ™‚
  21. What I meant was basically that there could be something unexpected that the proxy approach doesn't solve β€” i.e. what if some WP plugin depends on REST API and a method that the proxy doesn't pass along properly, or passes along but not with correct credentials, or something. You might also stumble upon various random paths that were not proxied but are expected by WP (or some plugin). Then again, I'd expect the same to apply to the case where both systems live in the same directory. Just be sure to test things (including back and front end, form submissions, and any possible plugins that might do "something" on the front end) carefully. Either way I think it'd be good idea to communicate to the client that the "truly clean and absolutely straightforward" approach would be setting up separate ProcessWire instance, move content over, and then publish that. A (temporary) mashup of WP and PW may indeed work as expected, but there may also be some quirks. As long as the client is OK with that, your neck is safe if something odd does eventually show up πŸ™‚
  22. Hey @fruid, SearchEngine finds content via the API and the operator used for text searches is configurable (see module config screen), so there's that. Depending on the operator you use you'll get a different set of results (obviously). You can read more about available selectors from the docs. As for Google-style search queries, there's nothing exactly like that built-in, but if you've got a newish version of ProcessWire (3.0.160+) and a recent version of SearchEngine installed, the module supports the advanced text search operator. The downside is that it's currently a little unclear how such queries should be sanitized so this feature is not fully functional. If you don't mind writing a bit of code yourself, there's also an example in the README about how you could provide your own search query and frontend (which, in turn, would allow you to sanitize the query string and then perform a find operation using the "#=" operator). ... and, as for the last point, it's actually also possible to use markup generated by SearchEngine yet still provide a custom results object. It involves a couple of extra steps, but something like this should work (requires SearchEngine 0.26.0 and ProcessWire 3.0.160+): // load and init SearchEngine $searchEngine = $modules->get('SearchEngine'); $searchEngine->initOnce(); // (for autoloader) // construct a Query object ($q stands for the _sanitized_ query string) $query = new \SearchEngine\Query($q); $query->results = $pages->find('search_index#=' . $q . ', limit=25'); // render results echo $searchEngine->renderResults([], $query); That doesn't remove the need to sanitize the query, though. That's something you'd (currently) have to do yourself if you want to use the advanced text search operator to the full extent.
  23. Heads-up! Wireframe 0.12.0 is now the latest master version. This is a pretty big update (in both lines of code, as well as features), so I'd recommend testing carefully after updating. The biggest parts are implemented as a companion module Wireframe API, but there are quite a few changes and updates for the main module as well: ### Added - Support for named arguments when using `Wireframe::component($component_name, $args)`. - JSON API. See comments in the WireframeAPI module file for more details. - New Page methods Page::getController() and Page::setController(). - Module config screen provides support for creating directories corresponding to configured Wireframe URLs, assuming that they were provided as relative paths. ### Changed - Wireframe::setView() accepts optional view name as an argument. - View::setController() accepts Controller name (string) in addition to Controller class instance or null. - When Controller is instantiated, it no longer overrides the Controller property of the related View instance. ### Fixed - Wireframe::partial() now works as expected for partial names with file ext included (partial_name.php etc.) - Wireframe::partial() prevents 2 or more dots in partial name, just in case (directory traversal is not intended).
  24. @Roych, you should probably report the issue at the module's support board, so that the author gets notified: .
  25. While you're at this, perhaps you could take a look at this as well: https://github.com/processwire/processwire-issues/issues/988. I haven't checked recently, but at least back then the modules directory wasn't updating the module version (note that this was unlikely to be caused by normal delay, as the version number hadn't updated in months). Thanks πŸ™‚ Just in case I've been updating the version numbers for all my modules manually. It's not a huge deal, but would be better if the automation worked (though again, I haven't done any tests recently, so maybe this was already fixed.)
Γ—
Γ—
  • Create New...