Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

101 Excellent

About bfncs

  • Rank
    Sr. Member

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    Münster, Germany

Recent Profile Visitors

7,870 profile views
  1. This thread is already quite old, but I just stumbled upon the same problem and wanted to add my solution to this thread. When you install the LanguageSupportPageNames module, you also get the Page::localName($language) method to easily retrieve the page name in different languages. This has been added in 2.3.0. So, to get the page name in a the language (or any other), you could do something around these lines and be done: // Get default language $defaultLanguage = $languages->getDefault(); // Get default page name $defaultName = $page->localName($defaultLanguage);
  2. Thanks for the link to the branch. I had no idea, but that looks awesome!
  3. I just stumbled over the roadmap for version 3 and couldn't do anything about asking myself, what the state of namespaces and the implementation of psr0/4 in ProcessWire is right now? With Drupal having just released the first RC for v8, I suppose this is going to be an important topic for all content management systems in the very near future. @mindplay.dk already did most of the heavy lifting years ago, but his changes were never pulled and his repository is now gone. This will be quite a lot of work, so how can we approach this? How can the community be of help?
  4. Thanks for the quick answer! I wasn't sure about support, but well, with all the great additions around images lately, it's probably hard to keep up with that. Is horst's CroppableImage module the recommended way to get this running now? And what to do about legacy websites?
  5. Has there ever been a permanent fix for this? I've updated a site from Processwire 2.3.15 to 2.6.1 and FieldtypeCropImage::init() isn't called any more which results in the known Method Pageimage::getThumb does not exist or is not callable in this context problem. I don't see how I can get this working without manually loading the FieldtypeCropImage module everytime before using getThumb() (or making it an autoload module for convenience). Is this generally working for you in 2.6.x?
  6. I forked the original module and use this fork for a project in development already. In my opinion it would be much more useful if merged into core, so I opened a pull request for it. You can assess the patch on Github, or you can test it using this temporary standalone module version (not to be used in conjunction with the core PagePathHistory module but as an alternative to it). The Page Path History manager module might be helpful in evaluating it. As always, I'd be grateful for any feedback.
  7. Thanks a lot for your comments. Looking at the code of Process::___installPage() showed that there currently is no possibility to set the page status using the descriptive way to set up a page. Thanks anyway, knowing about this will come in handy soon enough, really saves some repetitious copy-paste work. I already though about this myself but shirked from the duty of implementing it for the first release. But you're absolutely right, sooner or later this will be needed, so thanks for pointing it out. I've already added an issue for this feature and will implement it during the next
  8. Thanks again for your review, Soma. I just uploaded a new release that should solve the problems you mentioned. The module has now been split into two distinct modules, one autoloaded and the other for the process. That also means that if you already had the first version of the module installed, you will have to either uninstall it before the update and reinstall it afterwards or have to manually install the newly added submodule ProcessPagePathHistoryManager.
  9. Hey Soma, that was quick, thanks a lot for giving it a try! That's actually a very good question, the answer is probably that I got somewhat stuck in a rut while working on the module. It would probably be better to split this into two modules: PagePathHistoryManager to hook into the settings form and ProcessPagePathHistoryManager to provide the URLs for the process. Absolutely right, didn't know that until now, thanks for pointing it out! The next thing that I missed because I didn't follow closely. Processwire development is as always rapid and brings really great improvemen
  10. If you are using the great PagePathHistory module in core, this one might be helpful: Page Path History Manager https://github.com/boundaryfunctions/PagePathHistoryManager General This modules allows you to easily manage past page URLs tracked with the PagePathHistory module. It extends the settings tab on the page edit form in the backend and allows you to: view past URLs of the current page and parent pages, delete past URLs, and create new fallback URLs. How to use Use the form in the settings tab on the page edit form of every page in admin to view and manipulate past URLs. See
  11. Thanks for your feedback! Horst, I can totally understand your anger about the Google mobile optimization thing. While in the long run their recommendation might be a good idea, this is definitely not helpful at all for at lot of projects at the moment. And especially not, while the picture element isn't something we can rely. However I don't really see how this relates to PHP static code analysis. It's one thing when a quasi-monopolist transnational company tries to force conventions on how you should write markup, but it's another whether users of a piece of software can freely choose whet
  12. Well, in fact this was worded the wrong way around, for sure it's the IDE that should support things that make it easy to work with a piece of code and not the other way around. That said, when writing a piece of software the author can make it more or less easy to do static analysis of the code. The information that is gatherable by static analysis enables IDEs to do their "magic" in providing all kinds of convenience when working with code (look at PhpStorm's features to see what this might include). It makes it also more easy to work interactively with a debugger like Xdebug, or code qual
  13. Hi Larry, thank you loads for going through the efforts of putting this together. I've been experimenting with different ideas of implementing *VC along Processwire again and again, but was never really satisfied. Glancing at your solution it looks like it might be what I was looking for. I'm definitely going to try it out for the next smaller project.
  14. Thanks for the very elaborated and enlightening answer, Ryan! After you explained the rationale behind the current architecture, a lot of what I was criticizing in the initial post simply makes sense now. As everyone here knows, one of the main points for Processwire is your dedication for the code and the community, and this post certainly is no exception. I'd still like to go through some of the points mentioned, not at all for proving to be right, but to either underline why the current solution is the best or to explore what improvements might be possible. It's very interesting to k
  15. Wanze, I think an event implementation would have to handle this in one of the following ways: Either by attaching arguments by value to the Event object and later reassigning changed values to the variables (definitely too verbose). Or by passing parameters by reference, though this might be a bit unconvenient to do (one function call per assignment, at least until we can safely use the new variadic functions splat operator of PHP 5.6 with pass by reference). The third, most convenient way would involve the usage of __call(), much like it is already done in the current implementation – and
  • Create New...