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.

Wow, thank you all for the very deep insights you shared! You really helped me made up my mind on the topic. I'll try to answer some of the direct questions and main arguments discussed. Sure, I'll illustrate it with an example: if you search for the function Pages::saveField()and use a simple grep search like grep -R 'function saveField' wire/ you won't find it. A simple grep -R 'function _*saveField' wire/ gets you there, anyway, so it's not that big of a deal. Adding new methods with an event system wouldn't be much different from the current implementation in terms of functionality. Pretty much like in the current implementation it could be possible to dispatch an event in __call() when a method called is not defined. A listener would then be executed and cary out the implementation. An event-system-driven implementation wouldn't remove any of the actual flexibility. Before hooks could be implemented by dispatching a respective event in the first line of a function. Passed arguments would be added to the Event object that is passed passed to the EventDispatcher and could be modified by all listeners. The same would be true of after-events with their respective return values. Reading through all these arguments it became more and more obvious to me, that what I was proposing isn't that different at all from the current implementation. Essentially there are just two differences: added verbosity and a central event authority (which we also nearly have already). This would have some benefits and some drawbacks, so it's really questionable whether it would be worth the hassle of converting. Well this is definitely a big drawback that I didn't think of until now. I don't have as much experience as you have with rolling out an event system in a big application and mostly know it from the "consumer" side of things, but your argument seems valid and really important here. What you mention here pretty much hits the nail on the head. Solving the issues you brought up, especially the last two, would probably completely solve the need for a change that I felt in the first place – and probably even more than an event system could ever improve the overall architecture. This also looks to me like a pretty big project that would introduce breaking changes as well. In theory it should be possible to build a smooth transition by keeping non-granular functions and only deprecate them. The question is how we could approach this and how we as a community could help get that transition done. Any ideas? Haha, I went through the exact same process when writing the initial post. Cheers, Ryan, for always being a few steps ahead! I hope I made that clear in the first place, but just want to emphasize it again: Processwire is by all means the greatest CMS I know and I can't tell you how much I appreciate the work by all contributors, especially Ryan. With the next major version on the horizon, I just just think it's a great opportunity for the whole community to think about the small tads that can still make it an even better overall experience. Good that you mention runkit_method_add, because I know that I read about it some time ago and then completely forgot about it. Yes, this would enable much nicer ways of debugging than any event system could provide, so it's probably the best thing to improve the code (granularity) with the system we already have and wait for the runkit extension to become stable to improve it further. Thanks you all for the great discussion.

Hey BitPoet, thanks a lot for your answer. Probably you're right and this is the most-straightforward solution to the problem. I'll just go and and try to get it working. Will definitely publish my solution for the PagePathModule here, maybe it can be helpful for someone (or merged into core). With kind regards Marc

Hello fellow wirecionados, looking at the roadmap to 3.0 always gives me the good feeling of being on the sunny, futureproof side when using Processwire. Everything we already have together with the features planned is all I ever needed from a CMS. At least this is what I thought until that next idea came to my mind. Actually, there's one thing about Processwire that I have been struggling with from the start and until now: the hook system. I know, the hook system is deeply enrooted in Processwire (as can be seen from the fact that it's implemented in the Wire class that virtually every other class extends) and therefore is one of the key aspects for its success in the first place. It allows for the relatively loose coupling of components, with a lot of the core functionalities being implemented as modules. This makes for the great extensibility that Processwire is famous for. There aren't many parts of Processwire that can't be tweaked and modified to anyones needs by developing a module that alters some core functionality. I'm really glad about that and probably wouldn't have started to use Processwire in the first place, if the hook system didn't exist. That all being said, I also see some more or less problematic downside to the current implementation. It's sometimes pretty hard to find out, where functions are actually implemented. How long did it take you to find out that the actual logic for Page::render() is implenented in PageRender::renderPage()? While this kind of flexibility is just great, the implementation is not very verbose. This makes things harder than they have to be – especially for beginners. Just to make the argument above worse, there are several different ways to define a hook: addHook(), addHookAfter() & addHookBefore(), and all can be called either with a Class name or on an object. This makes it even harder to find modules, that hook into a particular function. I know, we have Soma's fabulous Captain Hook, and I use it all the time, but it still feels more like a workaround than like a solution. Speaking of Captain Hook, there's still a „Crocodile Hooked“ missing, a central repository that keeps track of all methods that are hooked to another method, including (private) site modules – and if possibly available at run time. Hooks for classes are saved in a static variable of Wire, but local hooks can only be fetched from that particular instance of an object. The convention with the three underscores in front of a function name makes functions harder to find. It is a nightmare to debug. If you ever tried to follow a request through the system with Xdebug, maybe involving some hooks placed by modules, you probably know what I mean. You have to go through Wire::runHooks() and __call() again and again to get where you want. It also prevents some of the convenient features of your favourite IDE™ (e.g. code completion, parameter hints when using a function, go to the definition of a function by clicking on it, etc.) from working in some cases. While one could definitely argue, that this is the fault of the IDE used, it's still slowing down work and not likely to be changed anywhere soon. Please excuse me if this was too ranty and even more correct me if anything I mentioned is an error on my side. I have to emphasize that none of these downsides prevents anyone from getting something done, it just makes it a tad less obvious and comfortable. Thinking through the things that I don't like about the current implementation of the hooks system, it came to my mind, that what we currently have here is kind of a non-verbose version of a „traditional“ event system and maybe what's missing could be more verbosity, so maybe such an event system (that implements the mediator pattern) could be of help? What I have in my mind here is the Symfony EventDispatcher or the Drupal8 EventDispatcher component, which is similiar to the CakePHP Events System and the handling of Events in Laravel. Let's look at how a solution to the problems mentioned might work by way of example using the Symfony EventDispatcher. In this particular example, the difference would be that Page::render() would actually be implemented in the Page class but just dispatches an Event.render event. Functionally no real difference, but much more verbose and therefore it is much more clear, that you will find the implementation anywhere a listener for Event.render is added. A new implementation could use just one method to add listeners (e.g. EventDispatcher::addListener()). Execution before or after an event will have to be handled by multiple events where this makes sense. Because the event dispatcher is the application-wide sole instance where event listeners are stored, it's easy to get all registered event listeners at runtime (using EventDispatcher::getListeners()). No more underscore's, just calls to dispatch events and calls to listeners. Debugging get's as smooth as it get's with loose component coupling. No more running through __call() all the time, always be able to check the defined event listeners. Having separated before and after events prevents you from some running through runHooks(). The added verbosity also helps to grasp the existing architecture quickly. Most of the IDE comfort functionality that doesn't work now should work with the Event System in place, because functions are always really where they are expected and with the exact same name. As an added benefit this system is very well known to a lot of developers already. But there are also some downsides for sure: Added verbosity is, well, verbose. More keys will have to be hit to get something done. Method and property would have to be implemented differently. This can be done by sending events on missing methods/properties, but it certainly looses some of the appeal it has now. The key argument would for sure be, that it breaks compatibility with a lot of core and user contributed modules. This is definitely true, so there shouldn't be an easy decision on this one. I thought I'll use the time before 3.0 to bring this one up, because as I understand it, the next major will break some stuff either way. Also I think that it should be possible to do the switch by in the beginning only deprecating the old hook system while keeping it functional, by translating calls to the old functions to adding and calling event listeners. This will have a performance impact, but would make a gentle transition possible. Now I'm really interested on your opinions on this topic. Do you already like the current implementation and wouldn't want to loose it? Do you have other problems with hooks? What kind of solution could you imagine? Is such a deep change realistic (and worth it) at all? Thanks a lot for your feedback Marc

I don't know where your memory error comes from, but your application is already stuffing >256MB inside your RAM. You should definitely start searching for the actual cause of that problem, or your application might run into this on other occasions. Are you fetching all your 2m+ records at some place? Install Xdebug and use the profiler to analyze what happens before you run into serious problems. That said, your problem of getting rid of a field can easily be solved by directly working with SQL commands on the database. You'll need shell access to the mysql command line tool or a tool like phpMyAdmin or Adminer to execute arbitrary SQL in your database. You probably already know a way to get this done so I'll leave it to you, how you do it. Before you do anything: do yourself a favor and dump the contents of your database and save that backup somewhere safe for later. Never work on a live instance of your application, especially not without a backup and a tested way to reset your database from it. Ok, now let's get to the work. Field data is, as you already mentioned, only saved in three places of the database: the actual content data of the pages for field is saved in it's own table (called field_fieldname), the field settings are saved in the fields table, and the association between a field and a fieldgroup and therefore a template is saved in the fieldgroups_fields table. So, let's get rid of it all. Let's assume that your field is called your_field. To keep things simple (without any joins) we'll get the id of your field in the first step and use it later as your_field_id. # Get the ID of your field. Note it down somewhere, you'll need it later SELECT `id` FROM `fields` WHERE `name` = 'your_field'; # Delete field data from fields table by it's ID DELETE FROM `fields` WHERE `id` = 'your_field_id'; # Delete field associations from fieldgroups_fields table by the field's ID DELETE FROM `fieldgroups_fields` WHERE `fields_id` = `your_fields_id`; # Now drop the table created for your field called field_your_field DROP TABLE `field_your_field`; That should have been all that was needed. With kind regards Marc

Hi everyone, I want to use the core module PagePathHistory in a Processwire instance with multi-language URLs/page names activated through the core module LanguageSupportPageNames. From looking at that old Post by Ryan I was pretty sure that it should work without any problems and was surprised that actually it doesn't. PagePathHistory only saves entries to it's DB table when the page name in the main language changes, not when any of the other language names change. Looking at the code this is no suprise as PagePathHistory only hooks Pages::moved(), Pages::renamed() and Pages::deleted(), none of which would be triggered by a change in a language page name. Starry-eyed I started to implement the missing language-awareness in the module, how hard can it be, eh? ...pretty quickly it turned out that this isn't that simple, so I decided to first ask for some help and guidance. Does anyone maybe already work out a solution for this particular problem or something similiar? The problem with the implementation is that after saving a page with changes to language names, there still has to be a means of accessing the old names. For the default language name this is pretty simple because it's saved as $page->namePrevious. For language names the module would have to deposit the original names for later to build the PagePathHistory-URLs. I've been looking through all hookable functions in core classes/modules but haven't found the best place to hook into to implement this functionality. Does anyone have an idea where this would be done best? Any help is appreciated. Thanks a lot in advance Marc

Ok, I just pushed an update to the modules repository, also bumping the version number to 1.0.3. Could you please confirm that this fixes the problem for you? @Soma: I just tried to force the error in a frontend form but that worked fine instead. The problem in this case was in the function hooked after InputfieldTextarea::getConfigInputfields() which was only called in the backend. Thanks anyway for your - as always - very helpful suggestion! @Martijn: Thanks for the suggestion. I'm not sure whether this would be too restrictive because there might be handy uses of this module in the frontend - which would then be forbidden. I currently much favour to convert it into an Inputfield on it's own. Thanks a lot to all of you for your help.

Hi everyone, thanks, Joss for again pointing to the issue and Some for suggesting a fix. I want to maintain the module and would be more than happy to add a fix to the repository. The bug described (as well as the one on Github) does only occured when used in conjunction with Formbuilder, which is a paid module. I don't own it because I have no particular use for it, so it's also not possible for me to test suggested fixes. If someone could please check whether Soma's suggestion works out (which I suppose, because actually he is one of the good guys) and I'll add it in an instant. P.S.: Ryan's post mentioned above is actually an answer to me seeking advice on the best implementation. At the time asked and answered I didn't see too much benefit in implementing the functionality as an Inputfield of it's own in comparison with the current implementation - both had their advantages and drawbacks. Seeing that that this now caused confusion to some and the Inputfield implementation could possibly be used with Formbuilder, I see the really benefit in doing the other implementation. I'm seriously considering to add the other implementation as a separate module now.

Soma, you're right, there's something to be found in the source of LanguageSupportPageNames module: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/LanguageSupport/LanguageSupportPageNames.module#L781 Actually, Ryan creates a new InputfieldName for each language there, no real Multilanguage Field. Shouldn't this be possible as well? Edit: I just had a look at the relevant section in ProcessModule module and the way it is handled there sadly doesn't work together with "real" multilanguage fields.

I just stumbled over this as well, thanks a lot for fixing it already, Ryan. Just one question: I was looking for the commit that fixes this but couldn't find it on Github. Can anyone find it?

Hi valan, thanks for testing the module. I think I missed this in the documentation, but there's a need to also post a variable named "field" with the correct Field name when uploading the file via ajax (like described here: https://github.com/blueimp/jQuery-File-Upload/wiki/How-to-submit-additional-form-data). This is a residue from development that was looked over by me, sorry. I'm currently on the go, but I'll definitely fix this tomorrow.