Exporting Property Set: Request-URI Too Large - My Forums

Re: Exporting Property Set: Request-URI Too Large

donshakespeare — Apr 16, 2016, 09:06 PM

Excellent! MyComponent would have both the plugin and its default properties... did not cross my mind to use it.

...use MyComponent to create a package for the project and just email them the transport.zip file when I do upgrades.

I have just now stolen your idea, mucho thanks!

Re: Exporting Property Set: Request-URI Too Large

BobRay — Apr 16, 2016, 06:24 PM

Very nice.

Another way to go would be to create a package with MyComponent, run ExportObjects, then Build, and upgrade the package on the production site. With this method you could package a lot of other stuff at the same time if you need to.

When I do work for clients, I often use MyComponent to create a package for the project and just email them the transport.zip file when I do upgrades.

Re: Exporting Property Set: Request-URI Too Large

donshakespeare — Apr 16, 2016, 01:12 AM

It also helps if you don't have special weird xters in your descriptions or property name/value , trust me, keep it simple!
JSON_ENCODE will escape the xters, and these might cause trouble when importing.

Exporting Property Set: Request-URI Too Large

donshakespeare — Feb 14, 2016, 03:30 PM

Say you have built a fantastic but ridiculously long list of properties for your plugin, snippet etc... and you want to import it in production site
You click the "Export" button and bam!

Request-URI Too Large
The requested URL's length exceeds the capacity limit for this server.

Now you are panicking because this has always worked for you, and you have developed many a thing like this.
You google solutions to this error, they tell you to restart PHP ini, gini, and fini files ... some say a reboot, some say na.... impossible - server won't allow it.

You think Eureka - phpMyAdmin! You find the exact table, find say, your plugin, and the properties field ...
You see that the code in there is a little less than gibberish - JSON's sister from another mother.
You say oh well, lemme copy this exact thing to the other database in question - surely 'copy and paste' is panacea!

You refresh your production site and the plugin's properties now contain worse than rubbish ... jumbled garbage!
You scratch part of your head bald ...

Well, I finally wrote a snippet called "getDATpropsNOW" to export my stuff, thank you very much!

[[!getDATpropsNOW]]

$stress = $modx->getObject('modPlugin', array( 'name' => 'myInfamousPLUGIN' ));
$stress = $stress->get('properties');
$stress = json_encode($stress, JSON_PRETTY_PRINT);
$stress = str_replace(array('[[',']]','type'),array('&_#91;&_#91;','&_#93;&_#93;','xtype'),$stress);
//(remove underscore)
return "".$stress."
";

Open a resource with a base template and call that snippet inside.
The result should be pretty pretty enough.
Copy it all and paste in a new file myInfamousPLUGIN.js - then "IMPORT" that file in your production plugin.

This got all my required values- no complaint.
$stress = str_replace(array('[[',']]','type'),array('&_#91;&_#91;','&_#93;&_#93;','xtype'),$stress);
// (remove underscore) prevent any [[MODX tag]] from being parsed on the resource
// convert the word "type" to "xtype" so that there are no issues

If you have better ways of doing this please share for all of us to benefit.

Cheers,
- what is in a name?