DisposableHero

It is not about being free or payware, or about making profit from something... Required code is already shipped with Disposable Special. But this does not mean that everyone can use it or just enable/disable it easily. And it is not "version locked" or "version specific", people using my method are well aware of how to edit core system files, how to track changes and take responsibility of their alterations etc. It is not something you install and then use style, when it comes to editing/altering core phpVMS files it becomes something different. Hope it is more clear now

@a7c12a5 Yes it is still valid. Don't mix fare capacity values with weight and fuel values. Fare capacities are not casted to some unit, they are just values, plain numbers as you write/save. Aircraft weights and/or fuel figures are casted with units and they are shown in your own unit (settings from admin) but always stored with internal units (which is pounds, lbs). So during live operations, for example generating some cargo load to your pirep, that capacity number is used directly. Thus, yes you still need to define your capacities manually in kg if you are using kg at admin settings (for weight units). Hope this helps.

Hi @IFL442, What you are asking is directly phpVMS v7 related, not something my addons can control or should control directly. Fares are a part of the core (as we call it) and they can not be altered with a module (without playing with core files). We can inject our custom income and expenses but it is not possible for the main fare (ticket income/expense). I do have a solution in Disposable Special (dynamic fare price calculation for each pirep when they get filed and accepted) , which I am using on my installs for a long time (and some friends also adopted it to their phpVMS v7's files) but unfortunately I can not share it publicly (or make it automatically installed) because it needs to be re-done after each phpVMS update. I also tried to implement something similar to what I have for phpVMS v7 itself but due to some logical differences it was not possible, thus that idea was trashed This is still something open for improvement at v7's core systems. Best wishes, Fatih

Please do NOT post the full log as a message, it makes it hard to read/follow and hard to help you, attach the file(s) or upload them to somewhere we can download. You still got the same error `Unable to detect application namespace.` and it points out Application.php line 1532... Looks like either your .env file is doing something weird, server is not returning proper application namespace (folder names, capitalizing first letters etc.) or there is something wrong in composer.json itself. Hope you can figure it out because we can not help much for server side stuff when it needs to be checked/fixed on that end. Good luck

I don't think that deleting that folder will help, if the contents are ok it should work but if there is a folder inside that folder, like `modules\DisposableBasic\DisposableBasic\` then it will fail of course. Also, there are errors in your log which have no relationship with DispoBasic (or any addon), your map page is not working too (again this has nothing to do with DispoBasic or an addon) so I think there are other problems, affecting everything running on your server. Maybe a .htaccess issue, an unintentional forced redirection, block of loading files, access issue some sort of.

FTP = File Transfer Protocol, filezilla as an example is a client, FTP Client. Well if you have DispoBasic, and the folder contents are ok, then you have different problems because that error in your log about migration tells a different story

As far as I know SimBrief does not have seat configuration definition and it can differ from airline to airline, and again as far as I know you do not need an API key to fetch the default profiles. I do define my fares according to the airline I simulate, I do not care what the addon provides at that stage because they do try to provide a single layout which can suit most of their users. Imagine it like Fenix providing a 220 seat A321, but the airline I do simulate has 20+180 for example, thus 200 seats max. Also opposite can be faced, the airline you try to simulate can have a special config of 230 pax (all economy on an A321, terrible config but there are companies using that), but the addon can give you 219 only. Thus reading something from SimBrief and then converting it to v7 fares is something I would never do (even if I can, I would not go that way), I do define my fares according to the real airline, then advise my pilots to match the Traffic Load or ZFW (if the addon is not providing enough seats or cargo space). Good luck with the script

I don't think that I understood the main aim here, will try to provide some answers though 1. If you want to dynamically check the simbrief profile, thus the selected addon aircraft and read its capacity then apply it back to phpVMS (for automatic random payload generation), sorry this is not possible. 2. If you have subfleets defined for each ICAO type (which as you said are tied to some simbrief airframes) then you can (and have to) adjust their fare capacities manually once (as described in other guides). Sorry but this is admin work, needs to be done. As the addons differ in capacities, it will not be logical to develop something to read simbrief profiles and then write them to phpVMS fares (to reduce admin work). Imagine a code reading iFly profile and adjusting the fares according to its seat config and then same code will read a Bredok profile which is totally different from iFly, same will happen while reading PMDG profiles and then reading a Zibo profile etc. Even if someone tries to spend some time to develop something for this, it will be practically useless and create more problems Hope this helps

Hi @RAI , even though it is hard to read a log from a forum post, I saw two critical issues, and probably they are causing lots of other problems. 1. Your phpVMS thinks you have DisposableBasic module, but it is not there or not installed properly. It can be installed once but then files may be deleted without de-activating the module etc. production.ERROR: Error running migration for DisposableBasic; error=Nwidart\Modules\Exceptions\ModuleNotFoundException: Module [DisposableBasic] does not exist! 2. There is a namespace error in your "seven" theme (which is really weird) production.ERROR: Unable to detect application namespace. I would suggest below actions, 1. Double check if you have DisposableBasic or not, if it is not needed at all, delete any folders of it from your modules folder 2. Delete the cache manually (please check docs, updating page step 3) 3. Be sure you are unpacking the latest release (7.0.3) files on your server directly, do not upload each file via ftp, this will ensure that all packages are there and ok. And then try to visit your admin page directly (yoursite.com/admin) Then if possible upload the log files in a zip package to somewhere, like your own server under public folder, so we can download and check the logs. Good luck

2. Cancelled Pireps: They need the "hourly cron" tasks to be deleted, not nightly. If it is not working then there is something more wrong in your install. 3. Statistics: This is an addon question, depends on the stats, some are updated (cached to be more precise) 6 hours. For Disposable addons, no I do not plan to change the cache logic, 6 hours personal stat cache is fine and a good balance for server performance. There were some discussions between users about how to reduce the cache or disable it, you can search (phpvms discord) for them and use offered solutions. Good luck

Provide logs, otherwise no one can help you

Hi, Original/default file is at "your phpVMS Root\modules\DisposableBasic\Resources\views\web" folder https://github.com/FatihKoz/DisposableBasic/blob/main/Resources/views/web/blank.blade.php I would suggest using "Duplication Procedure" or logic to have your own/edited blade files. https://github.com/FatihKoz/DisposableBasic#duplicating-module-bladesviews Good luck @ProAvia would you please move this topic to Disposable Addons section Thanks

Hi @William Looks like you added "SES_ENDPOINT" only to services https://github.com/phpvms/phpvms/blob/main/config/services.php#L26-L30 Technically the "MAIL_FROM_ADDRESS" and "MAIL_FROM_NAME" are already defined and can be controlled from .env itself, no need to modify mail.php for them, as it will revert back to defaults during an update. We can add that additional AWS SES Enpoint to phpVMS itself, so future updates will have it and you will not worry about updates Safe flights

Great news, enjoy your new install

Hi, Key info is there in this section `include(): open_basedir restriction in effect.` and the difference between old/new paths. If you moved your cache while moving the install, this can cause phpVMS (thus laravel and php itself) to still look for old file locations. While moving from one server to another, or even moving from one directory to another (like from domain to subdomain), it is better to skip copying cache related folders. So then the application can build new cache on first run properly. If you are not able to visit admin area and go to maintenance tab to clear all cache now, you can check the docs (updating page, step 3) to see how we manually delete cache related files. https://docs.phpvms.net/installation/updating Good luck

Even though you find the solution, this is not the correct place to get support for v7 themes/skins

Your phpVMS settings are corrupt, check Admin > Settings and define a map center properly. It needs to be lat, lon so something like 0.0, 0.0 Good luck

Looks like this project is 99.99% dead, as I wrote earlier, something not finished in 3+ years will never be finished. So called "additional fields" should not be a fact as they are not much in numbers and all were optional, a simple export from a recent build (or a check on export/import code) will give you the new fields in minutes, that simple it is. But, if someone does not want to do something, which is understandable and acceptable, then there is always "something else" to check. This is the reason I am thinking that this project is dead for a long time

What is the error after changing mailer to "ses" ? It should be something different compared to using postmark driver. If you've shared your logs with Nabeel it is ok, if not how he can help ? I checked phpvms config for ses, it looks ok though.

https://github.com/FatihKoz/DisposableTheme?tab=readme-ov-file#using-your-own-fontawesome-kit Check the readme, define and use your own FA kit, all will be fine. Good luck

Hi @William I don't think that `MAIL_MAILER=postmark` is right. Did you tried MAIL_MAILER=ses there by any chance ? Don't forget to clear application cache for .env changes to be applied. Good luck

In above solutions, SimBrief will not send the auto generated load back to phpVMS, it only creates the flight plan. You will rely on pilot input (to get the numbers back) This is important.

Hi, If you want to use SimBrief's internal random load generation logic then you need to either disable capacities in your fares (so phpvms can not generate any load) or you can disable pax, baggage and cargo amount transfer in SB form (so phpVMS will be able to generate but not send anything to SB) In any case there will be a mismatch between SB and phpVMS. Also there may be logical problems, mismatches in your phpVMS financial data. You may need to check SimBrief API documentation to better understand what to disable and how it behaves, also you may need to alter simbrief_form.blade.php if you want to select the second option. Good luck

Hi William, Please do not mix up different questions / problems in one topic It makes it harder to find and track stuff. This looks like a totally different theme or authentication related issue (and has nothing to do with landing g-force), please open a new topic about it by mentioning the theme you are using, preferably tag its developer if it is a 3rd party product. Safe flights

You can do it, even though it is not advised or suggested, it is ok to start over. Worst case scenario is a having an error due to a missing failsafe and trying to load a non-existing record. The logic behind not deleting is "relationships" used in phpvms v7 (laravel), a pirep has a relationship to the aircraft it is reported (created) with, financial system uses those deep relationships too. During the development process, we identied lots of errors coming up due to deleted records, no new ones are being reported for almost a year maybe more So we can assume that it will not be case for near future Hope this helps