extiverse / bazaar Goto Github PK

The API endpoint for that is ready, but it's not implemented in the UI.

Add a button in the dropdown to update an extension.

Also add a visual indicator that an update is available.

We only need to communicate with our own server. No need to keep it interfacable.

Bazaar page should show the max allowed memory and warn if it's less than 1GB.

Good afternoon guys, I just started testing Bazaar and must admit I'm more than amazed with your work. Although, I have reached an issue. I successfully installed a few extensions but somehow there are some that it won't install.

Here you have the list of the extensions that I couldn't install:

• BBCode Helper
• Chat
• Birthdays
• Flagrow Split
• Widgets

I am running Flarum on a dedicated server with CentOS 7 and just did a composer update to double check and reconfirm my issue.

Hope you can help me! Blessings!

Whenever bazaar enables (or mutates) an extension we need to update the state in the core extensions list in the frontend too and vice-versa - extensions enabled/disabled need to be set to the same value in our own ExtensionRepository.js. This will prevent that a discrepancy exists between the two pages.

Possibly create tabs to show initially the tab with installed extensions and their state, we need to update the ExtensionListItem to be full row or something too.

Other tabs might show most downloaded, most favorited (once implemented) and recommended aka reviewed?

Bazaar needs permission to write composer.lock, composer.json and the vendor directory, in addition it should be able to create the vendor2 directory.

cool to pick up with #49

Hi, I have an issue when trying to uninstall / install / update an extension. It seems that it tries to clone from github and fails.

Steps to reproduce

1. Go to admin
2. Open bazaar tab
3. Try to uninstall / install / update and you will get this error

Expected behaviour

It should update / install / uninstall.

Actual behaviour

I get an error. Oops! Something went wrong. Please reload the page and try again. This happens on any extension. It doesn't even seem to be trying to clone from the extension I'm actually updating / installing / uninstalling.

Configuration

Version of Bazaar: 0.2.2
Version of Flarum: Beta 6

such as the skywalker512/flarum-ext-simplified-chinese is a deleted packages , but it still apear in bazaar

Composer does not create or use the composer-home folder as assigned via ENV variable and ends up downloading every package every time.

It looks like it uses the storage/cache folder but clears it after it's done. Webserver has full write access to storage so it does not seems to be permission-related.

System: Ubuntu 16.04

The repositories setting in composer.json accepts two formats: array or object.

When the format is array, the native Composer\Json\JsonManipulator::addRepository() method (used by Bazzar to add our private Satis endpoint) fails silently.

We should handle this in Bazaar or even fix it upstream.

Additional note: this has a high chance of impacting developers because in all guides we recommended to add a workbench entry as array instead of object. In order for Bazzar to install correctly on a dev install, the workbench entry should be formatted as follow:

        "workbench": {
            "type": "path",
            "url": "workbench/*/"
        }

Moving this issue out of #21 will allow us to merge sonner (I hope)

When filtering extensions (example: select only installed), the tooltips are still displayed based on what extension was there before filtering

Before filtering:

After filtering:

Probably an issue with Mithril dom re-use. Must be missing some key attributes.

Hello i Need a Token for my Website http://wum.cu.cc
Thank you

As there were significant extension changes between Betas 4 and 5 (and to a lesser extent, 5 and 6), anything made for Flarum Beta 4 or earlier is almost guaranteed to be incompatible. We should drop these from being downloaded, it would be too troublesome to manually check which ones might still work. Any authors who find their extension dropped from Bazaar can simply update it if they're still around (and if not, it's probably abandoned).

The loader popup has to move behind the debug popup.

we should try to do an ini_set if the user allows us

If an extension is both Installed and Enabled, it will show two icons far too close together. This means that on hover, it's hard to get the different pop up messages for description, installed and enabled messages.

Possible solutions:

1. Combine Install and Enabled icons
2. Make icons bigger

We should allow the extra json part of the composer.json to hold a key that allows setting a value to point to the official thread over at discuss.flarum.org, we can then link to it from within bazaar.

It would be really handy if a search bar is added to allow us to simply search whatever extension we want!

While implementing the search feature, I removed an unwelcomed call to flushCacheKey that was clearing the whole extension cache on each request, making the search extremely slow.

#73 (comment)

That method call was undocumented. From @luceos words:

@luceos A drawback of removing this line all together is an issue caused when we add an extension to the UX that wasn't received from Flagrow.io but is installed.

But I can't reproduce the issue. If a package isn't available in flagrow.io, it simply doesn't show in Bazaar page, with or without a call to flushCacheKey... 😐

Providing an "update all" button has important implications.

From a developer perspective, extensions should be tested locally, the composer.lock should be copied to the server, and composer install should be used to install the extensions wanted at the version wanted. Running composer update means blindly trust extension stability and security.

We have two ways to implement update all:

An update all button that would have the same effect as composer update (that's option 1), this means it will update every extension to the latest version and update the composer.lock.

At the moment there is no security/stability rating on flagrow end, so updating every extension manually or updating all at once has the same effect. If we allow users to flag malicious extensions the "update all" feature would bypass every warning on Flagrow's side.

Another option (option 2) would be to send the current composer.lock to Flagrow server, where we update extensions according to these potential warning flags. We then return a new, "safe", composer.lock and run composer install on the Flarum install.

Feedback on this from the community is welcome :)

Steps to reproduce

1. Click install/update/uninstall on any extension without fulfilling the requirements

Expected behaviour

The error popup opens and the "processing" overlay closes

Actual behaviour

The error popup opens but the overlay stays there, making it impossible to click on anything else than the error popup. A reload is required. It's also not clear if it still processes (which is not the case)

We are automatically creating anonymous oauth personal access tokens for each Bazaar installation so it is able to use our Flagrow.io api. We now need to allow users in Bazaar to connect their Flarum to their accounts so we can enrich their user experience in the future and provide for instance a status dashboard.

If an extension install/update fails, we should send the composer.lock to flagrow.io so the error can be tracked and hopefully solved.

We should also report extensions that cause 500 errors just after installs.

I'm getting this error when trying to install anything on a fresh new install with Bazaar:

And with Debug mode on, I click it and it does nothing.

forums.postactiv.com's composer.json: https://spit.mixtape.moe/view/3d08d21e

Flarum version: 0.1.0-beta.6
Bazaar version: 0.1.0-beta.5

We need to provide the users with a list of resources they must authorize access to so bazaar can work in their environment. For instance (may be incomplete):

Server-side: (if using a proxy)

• Allow HTTPS access to flagrow.io

Client-side: (if using CSP)

• Allow HTTPS images from flagrow.io

Create a vendor/bin command (any package can create this) that uses the composer autoload, reads the config.php manually for db credentials and loads the last logged entries. With this information it will remove the last extension that caused failures.

We use a special Flagrow\Bazaar\Extensions\Extension object to merge both local (composer installed.json) and remote (flagrow.io) information about an extension.

When installing or updating an extension, we expect the API to return the updated extension data, like here https://github.com/flagrow/bazaar/blob/fa45531846c63769dbbb92803b2f972cebde94a4/src/Api/Controllers/CreateExtensionController.php#L52

This line is not working because 1) the Flagrow\Bazaar\Extensions\ExtensionManager object was refactored and 2) because we have no way of crafting a single Flagrow\Bazaar\Extensions\Extension object from the FlagrowIOSearcher

We need to add a sort of get of find method to FlagrowIOSearcher. This, in turn, requires a way to search the local flagrow.io cache or do individual GET queries to flagrow.io for missing packages

Of course, we can also never return individual data like that.

look its just blank with no extensions wtf

Anyone using bazaar most likely does not need any dev dependencies, let's not install those in our vendor.

It might be a good idea to have a details page (or something like the UserCard popup) that contains the author name and the description, among other stats we might want to include. This would especially be useful for languages.

As you know, the allow_url_fopen is usually off due to security risks. Is it better using curl to fetch the file instead of url_fopen?

Sorting would be useful. Search might be better, but sometimes browsing by category can help locate better than search.

So how do we sort? Right now, composer.json gives us mediocre resources. We could use its keywords, but some have crappy keywords (for example, Bazaar uses flarum, extension and flagrow which says nothing useful if we were to sort).

We could manually sort them using flarum.today as a framework (but that would mean pulling from two sources) or using a manual list (but that would mean updating every time a new extension came out, which is less than ideal).

We might be able to sort out languages by looking for the locale tag in composer.json, if that information is supplied in a way we can access.

And at the very least we could sort by author as well.

Not sure how to solve the rest. Might have to wait until real categories are established and enforced for Flarum extensions via composer.json.

@ibrahimk157 reports having issues with bazaar, the error triggered is:

{
  "errors": [
    {
      "code": 500,
      "title": "Internal server error",
      "detail": "LogicException: Lost connection and no reconnector available. in /home/u542484920/public_html/forum/vendor/illuminate/database/Connection.php:715\nStack trace:\n#0 /home/u542484920/public_html/forum/vendor/illuminate/database/Connection.php(684): Illuminate\\Database\\Connection->reconnect()\n#1 /home/u542484920/public_html/forum/vendor/illuminate/database/Connection.php(624): Illuminate\\Database\\Connection->tryAgainIfCausedByLostConnection(Object(Illuminate\\Database\\QueryException), 'select exists(s...', Array, Object(Closure))\n#2 /home/u542484920/public_html/forum/vendor/illuminate/database/Connection.php(324): Illuminate\\Database\\Connection->run('select exists(s...', Array, Object(Closure))\n#3 /home/u542484920/public_html/forum/vendor/illuminate/database/Query/Builder.php(1637): Illuminate\\Database\\Connection->select('select exists(s...', Array, true)\n#4 /home/u542484920/public_html/forum/vendor/flarum/core/src/Settings/DatabaseSettingsRepository.php(43): Illuminate\\Database\\Query\\Builder->exists()\n#5 /home/u542484920/public_html/forum/vendor/flarum/core/src/Settings/MemoryCacheSettingsRepository.php(52): Flarum\\Settings\\DatabaseSettingsRepository->set('flagrow.bazaar....', 1)\n#6 /home/u542484920/public_html/forum/vendor/flagrow/bazaar/src/Search/FlagrowApi.php(99): Flarum\\Settings\\MemoryCacheSettingsRepository->set('flagrow.bazaar....', 1)\n#7 /home/u542484920/public_html/forum/vendor/guzzlehttp/promises/src/FulfilledPromise.php(39): Flagrow\\Bazaar\\Search\\FlagrowApi->Flagrow\\Bazaar\\Search\\{closure}(Object(GuzzleHttp\\Psr7\\Response))\n#8 

The current UI shows an icon for every extension that can be downloaded, which creates too much clutter. Switch it around and only show an icon related to downloadable state if it cannot be downloaded. This will make it more easy to pick out extensions that are unusual, rather than hunting for a change in icon among all of them.

When memory_limit is set to -1, FileSizeHelper::identifySize() fails with exception "Cannot identify -1."

This prevents the admin panel from loading because that check is run at every request.

We need to handle this case without the method failing.

Hello,
When I installed this it just said Killed after about 30 seconds. I cd to my install directory

• We need to import all extensions into our satis

Until flarum/framework#837 (comment) is fixed in core maybe we should clear the manifest.json ourselves so assets get a new name and bypass the old version from Cloudflare/Proxy ?

Might also help against the CTRL+F5 CTRL+F5 CTRL+F5 CTRL+F5 CTRL+F5 effect

Use some color/icon to mark Flarum official extensions as official.

Maybe do a similar thing with Flagrow extensions.

For example we could place a small orange F and a small blue phoenix (the respective logos) beside the vendor names.

Hi,
I've installed Flarum and Bazaar using pockethold and don't have a token.
How can I get a token?
Thank you

While working on improvements for the package list endpoint, I noticed a few things.

First, even with a local flagrow.io instance, it takes about 1.7 seconds to load the list of packages when not cached. But once cached, performance can greatly increase:

Before my improvements, I noticed we were caching the raw text response from flagrow.io, but were parsing it and extracting the data key each time. By moving the code around I checked the following. (Time is the average in seconds for 5000 readings from the cache, I did the serie a few times for each case). The cache was already filled at the start of the test.

• Cache body, then decode and get: 0.0078702149868011 0.0077699553966522
• Cache body and decode, then get: 0.006110792016983 0.0056095233917236 0.0055253109931946
• Cache body, decode and get: 0.0056348145961761 0.0060723432064056

Caching the raw text clearly has no advantage. The serialized version of the output of json_decode is parsed quicker than JSON itself.

I'm closing this issue immediately, I just wanted a trace of this to stay somewhere. But it's irrelevant in the code because it's closely tied to my own machine.

Bazaar should read the composer.json and understand the current value of minimum stability. With that we can show a one-time popup whenever the user attempts installation of an extension with a lower stability. If the user approves we will update/add the minimum-stability on behalf of the user.

We need PR's to require some stuff, eg what is tested. I was considering something like:

• what is this pr about
• does this pr add tests
• did you test that extension installation, updating and uninstalling works

.. etc?

When attempting to use Bazaar on a mobile device to install an extension, the installation appears to proceed (processing appears, refreshes page) but the extension remains uninstalled.

My site installed this plug-in "504 Gateway Time-out".

Having extensions with blank icons looks unfavorably on Bazaar (like we are the problem and not the ext). A solution to this could be to assign icons to these extensions manually, perhaps using the first letter of their names?

We need to split up our logic of enriching the native Extension object and the Flagrow result from the Searcher. Every install, update, favorite etc action we do now enacts a full redraw and xhr call. We should send appropriate return json back that can replace the existing ExtensionRepository.js items.

The reason is that data defaults to [] in ExtensionRepository and we never check the http code.

Expected behaviour:

The Bazaar UI displays an error and don't cache the result

Actual behaviour:

The 500 errors are cached and the UI simply displays an empty list of extension.