Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Cache type changes (OCNA migration) #2087

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Cache type changes (OCNA migration) #2087

wants to merge 9 commits into from

Conversation

andrixnet
Copy link
Contributor

@andrixnet andrixnet commented Jul 23, 2019 •
edited
Loading

This is my work related to cache type changes according to:
CACHE_TYPE_ID changes, TODO list for OCUS, GeoPath FINAL cache type, ErrorException: Undefined offset: 12.

  • this changes the ID numbers for several cache types (exotic types, seldom used) to ensure no overlap occurs between OC branches, according to documentation here
  • implements in code and database dependencies the new cache types requested by OCNA
  • adds graphical resources for the new cache types.
  • removes Geopath FINAL type

Notes:

PR consists of code changes and database update.
Database backup is recommended before running the SQL file.
SQL file is for manual run by admin and is valid for all member sites.
This code can be seen in action at this devsite: http://ocro.dev.andrix.eu/ until merged.

Between code merge and DB update a few cache types may not work or be displayed incorrectly due to incomplete database definition.

andrixnet added 8 commits July 4, 2019 00:52
@andrixnet
CACHE TYPE icons overhaul
9c5f0c5 
Stage 1: graphics resources
Reference: opencaching#860

- removed stale and unused files
  (22x22*, 24x24*, usb*, mystery*)
- added graphics for new cache types
  (benchmark, bitcache, challenge, guestbook)
- created icon resources /public/images/cache/res
- created icon build script
- moved KML build resources and script to /public/images/cache/res
  (/public/images/cache/kml now contains only production images)
- updated KML icons build script

From now on it is easy to generate the entire iconset from res/ directory.
Just enable each cache type icon in res/__cache_types.txt.
Also, KML icons will be generated from the same set.
@andrixnet
New CACHE TYPES
821d08d 
Stage 2: code additions and changes
Reference: opencaching#860
Reference: opencaching#2024

- modified lib/cache.php definitions (old, but still used)
- modified GeoCacheCommons.php model
- modified translations (en first)
- new types are forbidden by default lib/settingsDefault.inc.php
- partial modification src/Views/mainMap/mainMapFilters.tpl.php
@andrixnet
Cache type id and new caches
95475f6 
- removed podcache graphics
- created (work in progress) geopath final graphics
- updated cache and GeoCacheCommons
- created SQL to update database
- updated translations
@andrixnet
Cache type changes
8d3f8cb 
- removed Geopath FINAL / podcache
- added BIT cache
- added Guestbook
- added Benchmark
- added Challenge

Updated translations, cacheType_1-15
Removed some duplicate translation strings having the same content and
purpose.

- updated cache.php
- updated GeoCacheCommons.php
- updated several files referencing cache types
- partial update of search pages
- updated exporters that export cache_type

TODO:
- log_cache_multi.php
- editcache.php
- newcache.tpl.php
- GeoCache.php
- CacheSetCommon.php
- powerTrailBase.php
- ajaxGetPowerTrailCaches.php
- newcache.php
- caches.inc.php
- openchecker_classes.php
- newcache_beginner.tpl.php
@andrixnet
Cache type changes
7007934 
- removed Geopath FINAL / podcache
- added BIT cache
- added Guestbook
- added Benchmark
- added Challenge

Updated translations, cacheType_1-15
Removed some duplicate translation strings having the same content and
purpose.

- updated cache.php
- updated GeoCacheCommons.php
- updated several files referencing cache types
- partial update of search pages
- updated exporters that export cache_type

TODO:
- log_cache_multi.php
- editcache.php
- newcache.tpl.php
- GeoCache.php
- CacheSetCommon.php
- powerTrailBase.php
- ajaxGetPowerTrailCaches.php
- newcache.php
- caches.inc.php
- openchecker_classes.php
- newcache_beginner.tpl.php
@andrixnet
Merge branch 'cache_type' of https://github.com/andrixnet/opencaching-pl
d207d30 
 into cache_type
@andrixnet
Updated SQL file with IDs according to wiki.
7a988e3
@andrixnet
Cache type changes - defining new caches at Geopath
c166b92 
- defined Geopath rules for new types
- defined size rules for new types
@andrixnet andrixnet added this to the OCNA migration milestone Jul 23, 2019
@andrixnet andrixnet requested a review from kojoty July 23, 2019 11:14
@andrixnet andrixnet mentioned this pull request Jul 23, 2019
Open
@harrieklomp
Copy link
Member

Just wondering. Is there any progress in this PR?

@Amberel
Copy link

Amberel commented Sep 22, 2019 via email

@harrieklomp
Copy link
Member

Can I call you later? Rgds, Andy
Yes, sure :-)

@andrixnet andrixnet mentioned this pull request Sep 30, 2019
Merged
@andrixnet
Copy link
Contributor Author

@kojoty @deg-pl @following5 can this be merged?
In conjunction with corresponding OKAPI PR: opencaching/okapi#595 ?

Let's schedule the merge this week.

@kojoty
Copy link
Member

kojoty commented Sep 30, 2019

OK, I will try to manage to review it today...

@kojoty
Copy link
Member

kojoty commented Sep 30, 2019 •
edited
Loading

@andrixnet you made great work - my respect :)

I have a few questions:

-- 1: I see a few new types from OCNA:

  • Guestbook cache ID = 10 -> new ID = 13 (overlapping with OCDE and old OCNA)
  • BIT cache ID = 12 -> new ID = 12 (OCNA only)
  • Benchmark ID = n/a -> new ID = 14 (OCNA only)
  • Challenge ID = n/a -> new ID = 15 (OCNA only)

Please explain for me what these types mean - I have a dirty idea: maybe they doesn't need these types as much and we can go other way - just refactor OCNA caches in DB to "our" well defined types...
(sorry that I ask at the end of the process - I know I should have asked about it long time ago...)

-- 2: have you tested this?
I mean what will happen when we merge this with OCPL server - are you sure that if we just add these new types as forbidden there will not be any problem - for now I afraid of this...
I will also try to test it on my dev...

@kojoty
Copy link
Member

kojoty commented Sep 30, 2019 •
edited
Loading

OK, I see the problem:

  • forbidden types in config is only to prevent creating new caches of such types - but it not hide not used caches types...

At least at map I see now:
image

or this in search...:
image

@andrixnet
Copy link
Contributor Author

@kojoty these cache types are explained briefly here: https://wiki.opencaching.eu/index.php?title=Cache_types
I am planning a unified documentation there, with each cache type described in more detail, like
https://wiki.opencaching.eu/index.php?title=Size:Micro or
https://wiki.opencaching.eu/index.php?title=Log:Attended
It is on the TODO list :-)

Additional information (though not fully up to date) can be found here:
https://wiki.opencaching.us/index.php/Cache_parameters#Cache_type

Also, you can see the ID overlaps in this older version of the wiki page:
https://wiki.opencaching.eu/index.php?title=Cache_types&oldid=680 (before numbering refactor).

You can see them in action on one of my dev sites here: http://ocro.dev.andrix.eu/
This devsite is running the code from this PR (including RO data with SQL updates) and a few test caches using the new types.
As far as I managed to test myself (and perhaps Harrie), seems ok.
Note: this devsite does not include the corresponding OKAPI PR.

@kojoty
Copy link
Member

kojoty commented Oct 1, 2019

@andrixnet, Your work on unification types and attributes etc. and documentation of all of that is really impressive - I appreciate it (sure!) - many thanks for that.

I reviewed the new cache types from OCUS - sorry again that I made it so late (that was something what I was not analyze deeper before - I feel bad with this because you made lot of works and at the end I start discussion on that) - anyway - my thoughts:

  • BIT Caches - is in fact a specific type of virtual cache (or mobile if it can be moved - I'm not sure how it works) - you need to find a sticker with the code - right? - in my opinion this should be just virtual (or mobile if can be moved) + maybe some attribute - I don't understand why we want to recognize it as a separate type of cache

  • Guestbook - same - it can be traditional (if gestbook is on coords) or multi (if there are a few stages + gestbook at the end) or quiz (if you need to solve puzzle to find guestbook) or other (if this is not on coords) etc... I think it can be attribute of the cache - not a type of cache... - in fact this is just a specific type of logbook...

  • Benchmark - same - if this is a point under coords it is traditional - we can add attribute with information, that theses coords are confirmed or something (I don't understand this type...)

  • Challenge - same as above - challenge means what - I need to do something hard to get the cache like climb on the wall to grab the box or don't sleep 3 days and then meet the owner? It can be traditional or own or quiz or any other type of cache - challenge should be an attribute!

My idea for now:

  • let's merge the PR with unification of attributes - I understand that there was a big mess between nodes (number overlapping etc.) (am I right?) and now we will have a clear list of that + the simple way to extend that list (another thing is that we should migrate it from the db to the code - but this is next step)

  • let's discuss if we really want to introduce the new types - in my opinion these are not "logical" and it will make system more complicated and less clear (virtual is a virtual or bit-cache if this is a sticker with a code... ?!)

  • even if we want to support the new types from OCUS we need to implement configurations which allow to DISABLE not supported types (at least for list in search page + filters on the map) for the node (I guess that our COG even doesn't know about new types and I think that RT shouldn't just introduce something like that without discussion with them)

@deg-pl, @harrieklomp @andrixnet @mzylowski
please take a look at this discussion - please share your thinking!

PS.
@andrixnet again - sorry that I understand what is going on here and react so late :)

@andrixnet
Copy link
Contributor Author

@kojoty regarding cache types: I will try to relay things as requested by OCNA team:

  • BIT caches: best documented here: https://wiki.opencaching.us/index.php/BIT_Caches
    Physical object, though not container with log. Sticker usually also features log password. Not mobile.
    Closest equivalent IMO would be Munzee.
    Explicitely requested by OCNA and a pre-existing cache type that they had implemented in their old site.

  • Guestbook: it is a new or existing guestbook for visitors to sign it, both geocachers and non-geocachers. https://wiki.opencaching.us/index.php/Guest_Book_Cache
    It has been requested by US people explicitely as type and a pre-existing cache type that they had implemented in their old site.. (they rejected the attribute)

  • Benchmark: physical object as geodetic benchmark, this can be looked at as a special kind of virtual since it has no container with log.
    Explicitely requested by US people, since the concept seems to have a special meaning for them and they knew about the attribute and rejected such variant.

  • Challenge: meeting a specific geocaching challenge like finding for example all caches in a given area, etc. The bounds for possible challenges are still being worked out by the US team. AFAIK the given coordinates have no explicit meaning to visit and there is no physical container with log (unless stated otherwise), logging a find requires one to provide proof of meeting the requirements.
    Up to now US used "Unknown" type for this purpose, but they requested it as type.

OCNA also had these cache types:

  • USB dead drop: replaced by tradi/multi/puzzle with appropriate attribute

  • Podcast: replaced by tradi/multi/puzzle with appropriate attribute
    (note this was also an old type at opencaching-pl, AFAIK it's code was reused for some time for a Geopath bonus, then it was dropped)

  • Letterbox: replaced by tradi/multi/puzzle with appropriate attribute

I have discussed all these in depth with the US team. They requested the former be as types and agreed about the latter to be assimilated with attributes.

  • Attributes was a HUGE mess. It has PR here and PR at OKAPI. I have also submitted these as future changes to c:geo, so after we merge, they should be able to integrate easily.

  • Attribute cleanup: I did the entire renumbering in one step, however there are some requests from several sites (such as US, UK, NL, RO) to add/remove attributes. I am planning on doing this (including work on attribute graphics) as a later stage.

  • I totally agree and support disabling certain cache types both as new hides and as search option for sites that do not desire to support such cache types. As far as my code and coding knowledge goes, it only works up to not allowing as new hide, they still show up as search criteria.
    If we want to remove them from search criteria, another restriction should be implemented, but this is beyond my skills.

That is:

  1. cache types allowed as new hide -> they show up in new cache page and edit cache page

  2. cache types allowed to be listed -> they show up everywhere (in lists, as seach criteria, etc)
    These can be more then those at 1 to allow the display of existing caches of types no longer hideable.

One specific detail would be to allow editing an existing cache (of type not hideable) with the ability to retain the type.

@andrixnet
Copy link
Contributor Author

AFAIK this opencaching/okapi#595 should be fine at OKAPI, several points raised by following5 have been resolved.

@harrieklomp harrieklomp mentioned this pull request Oct 11, 2019
Open
@andrixnet andrixnet mentioned this pull request Mar 3, 2021
Open
@andrixnet
Copy link
Contributor Author

Please review this PR in the light of the code changes this past year. Problems with cache types that persist and significantly affect OCNA are solved.
Thank you.

@andrixnet
Copy link
Contributor Author

A short review (for other purposes) today revealed that there still are many instances where cache_type table is still actually used. See here: #1394 (comment)
Please also take this into account while reviewing this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@kojoty kojoty Awaiting requested review from kojoty

Assignees
No one assigned
Labels
Component Cache Component CacheEdit Component DataBase Component Export (GPX etc.) Component GeoPaths Component i18n Component My Routes Component Search OCNA migration temporary label to fast find issues OKAPI fix needed Type Refactor
Projects
None yet
Milestone
OCNA migration
Development

Successfully merging this pull request may close these issues.
4 participants
@andrixnet @harrieklomp @Amberel @kojoty