bfncs

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);

Thanks for the link to the branch. I had no idea, but that looks awesome!

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?

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?

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?

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.

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 days. There's one other thing that has been corrected in the current development version of the module and this is proper handling of URLs with non name-format characters (all characters but -_.a-zA-Z0-9/~), i.e. to redirect content from a legacy website. Due to the way Processwire currently handles these URLs, you will have to edit youR .htaccess file to enable this functionality. I added a short description of what has to be done to the module's README and issued a pull request on core to make the need for manual modifications obsolete in the future – let's see how this turns out.

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.

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 improvements. Edit: I've been looking for this, but didn't find the place where this new behavior is documented. Could you please point me to the correct ressource? If I get it right, it is not possible to set the status of the newly created page this way, is this correct? It's too late for today, but I'm going to add all this in the module tomorrow. Thanks a lot for the review!

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 Screenshots to get a better idea of what you can do. Installation Install the module PagePathHistory from within the Processwire admin. PagePathHistory is included in core but not installed by default. Grab the module from its Github repository. Install this module from within the Processwire admin or copy the file content to/site/modules/PagePathHistoryManager. In Admin, click Modules → Check for new modules to refresh module directory. Afterwards install the newly registered module PagePathHistoryManager. You can now manage past URLs from within the settings tab when editing any page. Screenshots Notes This module doesn't install or require PagePathHistory because I'm currently working with a fork of it that is language sensitive. I'll try to publish this one here as well, but I'm not done with final testing. Links You can grab this Module from Github: Source Releases Download latest release I would be glad if some of you could give this module a quick test drive and comment with some feedback here.

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 whether they want to use a tool or not. I don't think that anybody would doubt that the right tools have a big influence on how efficient you can work on something, and the right tools are normally the ones you already feel comfortable with. For any piece of software, this means that it's an advantage to allow the usage of as many tools as possible. For sure this should never stand in the way of making an API concise and well consumable for humans. But in my opinion it's worth to consider both. For example when I work on projects based on Symfony or CakePHP (yep, introducing a slippery slope argument here, since both projects have a fundamentally different scope than Processwire) in my IDE, I can always click on a method call and the file where it is defined is opened. I get autocompletion for classes, methods and variables and I can read the documentation of all of them by merely hovering an occurence. In addition, obvious errors (like reading a variable that has never been declared, calling a non-existing function etc.) are shown with a curly red line under it. All of this (and a lot more) is pretty helpful to me. I have been working on PHP projects for years without any IDE or debugger, was absolutely satisfied with my technique and thoroughly opposed to the idea of using a heavyweight IDE. Then I discovered PhpStorm, gave it a try and it easily multiplied my work outcome and my grasp of the architecture of frameworks and libraries I used. However, with Processwire – that I love in nearly every other aspect – I have to eschew some of the benefits I was used to. I don't think that everybody should work like I do, to the contrary: everybody should choose his/her own tools by preference. But the current situation excludes some tools that rely on static analysis in the first place. Well, all I wrote is also slightly offtopic, because there's not really a possibility to reconcile all of this requirements for humans and robots. The only method I can imagine to fulfill all criteria while keeping the great flexibility would be dynamic code generation. And this is in itself creepy enough that I would dare to propose it. In the future the already mentioned runkit extension might be of some help, not for static analysis but for debugging. Otherwise I learned a lot about why the current implementation was chosen in this thread and can now much more appreciate its benefits. The questions I'm still eager to discuss, though, are how to improve the granularity and the documentation of hooks. @interrobang: Thanks for pointing out what can be achieved with PhpDoc comments! This is just great and I'm already using all of this and have TemplateStubs installed as the first step in every new PW instance. Works like a charm but because of the dynamic nature of the software, there are still a lot of uncovered areas, especially when working on modules.

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 quality tools like PHP Mess Detector, PHP Code Sniffer and others. All kinds of code that is only available at runtime is not available to static analysis and thereby prevents some features of these tools from working correctly. The most clear example is code executed through eval(), but also magic functions, objects loaded by passing the class as a string argument to a function or functions executed by hooks can make problems here. I think it makes a lot of sense to prioritize having a concise, human-friendly API over making the code well-consumable by static code analysis. Still it would be great to improve in this sector to benefit as much as possible from the existing tools in the PHP world.

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.

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 know, that you already experimented with other types of event systems and this actually led to the current architecture. Omitting the overhead of a verbose event driven implementation now makes a lot more sense to me than when I initially started this topic and the feedback by others here is approving that this is the right way. The big advantage of working with Xdebug – apart from mere debugging – is that it makes you grasp the internal architecture of a piece of software much quicker. This is true especially if you work with a multitude of different frameworks. Currently, to create a module that extends the core system in a major way (think of something LanguageSupport-related) requires the author to have a very intimate knowledge of the core, the involved hooks and in what context they are called. This is ok and not really disputable, for sure, but since hooks are mostly documented in the source itself, there's no way to get to know all that by extensively reading through implementation details of core modules and hoping to find the right places to do so. With Xdebug and using step-debugging it should be very easy to sort out the relevant pieces of code, and thereby the hooks that need to be used etc.. If this is easy to do, it might help to get more people into module and possibly core development. The same is true and probably even more relevant for good IDE support. I think you're right not to prioritize these two aspects, but also they shouldn't be given up too easily. Unfortunately there's no easy way to improve on this, but I think we should at least give it a good thought and look at how other projects get this done. Well, I think this is more a matter of preference than anything else, but thanks a lot for laying this out in depth. That made it a lot plausible for me and I don't think that a change is badly needed here. All you say here makes sense, but I still think that BitPoet was on to something important when he mentioned hookability, statefulness and granularity as problems – much more than myself actually. The current procedure of making a method hookable when someone requests it on the forum worked out well until now because there was a manageable number of people developing modules. In my opinion it possibly leads to several problems, though: Not everyone is going to request a method made hookable in the forum, especially not, if it's possible to hook anther method with essentially the same outcome – event if it doesn't make sense to hook that particular method semantically. Hooks might be implemented relying on side effects of the hooked method that are more an implementation detail than a stable API. These technically working but not really fitting hooks might be broken in further core development without notice. Or they might block further development when the intention is not to break the de-facto API. The procedure doesn't scale well from a little developers with a few hook whishes to a lot of developers with a host of hookability requirements. In the end this could lead to a majority of functions being hookable, which – as you mentioned – isn't a good idea performancewise. In this respect it might make sense to use the fact that there will be breaking changes in 3.0 either way to also revise some parts of the hookable API and try to break it down some more. This should also be a community effort, so it would be needed to discuss some helpful criteria beforehand. I also see this as an advantage for the event system mentioned in the first post, because it doesn't matter in which method an event is thrown, as long as the documented premises or fulfilled. Thereby it helps with decoupling API from implementation detail and enabling module authors to develop modules without having to dig too deep in the core. But this is also possible without such a structural change and already happens with methods like Pages::___saved(), Pages::___added() etc. I hope I was able to make some arguments a bit more clear and advance the discussion a bit. I'm still really interested in any feedback.

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 therefore defeats most of the benefits gained by an event system in the first place. I'd say that this is one of the drawbacks of a verbose implementation that an event system approach would force on us, and a serious one. Thanks for pointing it out, it helps me appreciate the current implementation more and concentrate on the real weaknesses pointed out by BitPoet above.