Search

Hi all,

I've made a start on creating an extension that generates a 6-character hash using the hashids library. Although one of the primary purposes of Hashids is two-way encryption, I'm mostly just interested in the hash it generates - as I wish to use it for generating obfuscated, unique IDs that aren't sequential. It's super basic so far, just a modified text input field that dumps in a 6 character hashid generated from the entry id. So for example an entry with id 2 might have a hashid field value of 9uy7gw.

The decryption side isn't (on the most part) required, because of course we can just use the hash itself as a datasource parameter for relating the hash to the entry contents.

Couple questions!

  • Firstly, is there anything already like this? Would hate to be battling through it if someone's already made the same thing.
  • Secondly, although I'm sure I'll have many questions… an immediate one i'd like to tackle before using it in production, how can I disable the input? i.e. add disabled="disabled" to the markup? Is this possible using Widget::Input? Or will I have to get creative?

Just in case anyone else ends up here, I found the answer to question 2 when fiddling with another extension. I'm sure this is in the docs somewhere, but I couldn't find it:

Widget::Input(NAME, VALUE, TYPE, ATTRIBUTES);

(Am I missing anything? Misinterpreted something?)

So in my case I needed:

Widget::Input(NAME, VALUE, TYPE, array('disabled' => 'disabled'));

Nathan,

I did make a fork of the Reflection field to allow it to hash any value you wanted reflected: https://github.com/orchard-studio/reflectionfield/tree/hashed

But not with a salt option or anything. There is a hash field in existence as well: https://github.com/symphonists/hashfield

Cool, thanks for that Andrew!

Funnily enough I did think about using a reflection field as the base, as it allows for some interesting flexibility!

I'm going to flesh out my extension over time, so it would be good to see how best to push it forward so it doesn't end up replicating the functionality of the others - as it stands it works a little differently to the other options, which is good!

Might need to look at the naming though, as I didn't come across the hash field when I looked originally, and I've called the extensions 'hash_field' for now (although due to its limited scope there's probably a more descriptive name for it).

Incidentally the discussion for the actual extension is now here: http://www.getsymphony.com/discuss/thread/106936/

Working on a new version that would allow a different salt for each instance (so it could be used in different sections and maintain uniqueness), I've tentatively called this one hashid_field.

Cool beans,

Looks like an interesting approach. I may take a look at your code and see if the reflection fork could benefit from that functionality if that's cool?

Yes please do!

I've actually just finished fleshing out the extension a little more - you can now define a salt and hash length when adding the field to a section, so every instance can be different. Hopefully get a commit up this evening.

If nothing else I'm getting a good grip of how to work with extensions, so a useful exercise!

Good man!

It's quite fun when it starts to click eh!

Certainly is! Got a ways to go yet, seem to be cleaning up the code every time I look at it :p Will get there eventually.

By the way Andrew - I do have an issue with the way the extension currently works, so if you have any ideas I'm all ears:

As the extension uses the entry ID for the hash source, it can only actually be generated after the entry is created, as it doesn't yet have an ID.

So the UX is a bit wonky, as you actually have to first create the entry, and then save it. I'm assuming there's a clever way around this kind of problem, any suggestions? Ideally the hash would be created when the entry is created (it looks like it is, but don't be fooled).

I'd even like to use this field in the context of an event - so I'm guessing the above becomes even more crucial, as there won't be a 'save', just an initial creation.

Check out the reflection field then Nathan, because it actually re-saves the field after the entry is created in exactly the same way. So the issue you are experiencing above is why I went with the reflection field as the basis for my alteration... it has the re-save stuff already coded: https://github.com/orchard-studio/reflectionfield/blob/master/fields/field.reflection.php#L304

This function is the magic and it's called here: https://github.com/orchard-studio/reflectionfield/blob/master/fields/field.reflection.php#L270 to do the re-save and capture the ID.

I think that's right anyways.

There's also the delegates EntryPostCreate and EntryPostEdit to hook into here: https://github.com/orchard-studio/reflectionfield/blob/master/extension.driver.php#L57 which in turn run a function called compileBackendFields ... which in turn uses the compile function to grab the Entry ID. Complicated stuff eh :)

You are a gentleman and a scholar.

Finally have it working! There should be minimal redundant code now as well :)

Latest commit fixes that issue. I still have to tackle the event side of things, but that should mostly just be replication of what I've already done.

I'll make it look prettier at some point too.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details