Big number of shipping locations

We are creating shipping plugin similar to Pickup plugin ( There is a lot of pickup locations. Each has id, location and cost. We are able to store only 328x rates in one settings/select. It can lead into 3x328 = 984 nodes in JSON format. Is it possible to store more data? Database looks fine. Framework cuts longer JSON (in number of nodes) and returns well formated, but shorter JSON.

array_push ($locations, array(             
    'id'         => $id,
    'location'   => $address,
    'cost'       => $cost,

Data are stored in table shop_plugin_settings in DB.

[{"id":"540","location":"Address 1","cost":"5"},{"id":"469","location":"Address 2","cost":"5"},... ]

1 answer

  • 1
    Mike Webasyst April 12, 2017 15:37 #

    Why not storing each location as a separate settings field rather than an array inside one field? In this case each location will be stored as a separate entry in the database table.

    • +1
      Tomas Sibek Tomas Sibek April 12, 2017 15:45 #

      It looks like DB problem (text length). Is it possible to change type to mediumtext, or longtext? In some WA supported way (not just in DB).

      Ad storing separate settings. As I get it, it needs more code and it will put into table shop_plugin_settings hundreds of rows. Is it a clean way?

      Thanks Mike

      • +1
        Mike Mike Webasyst April 12, 2017 16:11 #

        Shipping plugins are system plugins and thus are intended for multiple apps, not just Shop-Script. Therefore, it is not correct to speak only about shop_plugin_settings table, because other apps using the same plugin may store its settings in different ways; e.g., in wa_app_settings or even in files.

        So, since Shop-Script stores shipping plugins' settings in the database, I would take this fact into account and would try to implement a universal settings format for a shipping plugin, which could be "one settings field (i.e. database entry) per location" method that I suggested.

        Another (somewhat hacker-like) approach that I think of could be to add a custom JavaScript handler to the plugin settings form 'submit' event, which would save all your settings to a file in a serialized form and save only that file's name in the common plugin settings. That file name in the database table would be a "link" to the actual settings values stored in a file which you can access in your calculate() method.

Add answer

To add a comment please sign up or login