宫论App
登录
注册
小小乐
lv.2
实名用户
2023-03-14 22:20
iPhone
查看作者
宫论项目开发记录
记录2023年项目进度周期。
刷新置顶
2
524
0
11.92w
请登录之后再进行评论
登录
0
小小乐
lv.2
实名用户
2024年10月29日
1、在xc_query_identify方法中新增了一个名为“uncache”的变量字段,默认设置为false。当将其设置为true时,本次查询将拒绝使用缓存,强制通过数据库获取最新的有效数据,获取到的数据会更新已有的缓存。在某些特定场景中,数据的敏感性要求较高,通过拒绝缓存的方式确保返回的是真实可靠的信息。
2、在使用 xc_query_identify 查询鉴定订单时,如果将 uncache 设置为 true,且传递的订单号正好是主键ID值,那么在通过 xc_get_sql 发起查询请求时,将会增加一个第三个参数(false)。这一设置表明此次数据查询需要直接通过 wpdb 的原生方法获取数据,而不使用缓存结果,以确保查询结果的实时性和精确性。
3、优化了wpdb查询语句以防止注入风险。在使用wpdb构建查询语句时,通过prepare方法进行SQL查询,从而有效防止SQL注入。同时,将查询方式改为get_row,仅返回第一条记录,从而提升查询性能和效率。此外,表的前缀现在通过$wpdb->prefix动态获取,这使得在后期更新数据表时可以轻松进行一键切换操作。
4、已完成对 xc_query_identify 方法的封装,这一方法将用于未来所有订单类查询的封装处理。其执行逻辑如下:首先,检查给定的 ID 是否为数字。如果是数字,通过主键 ID 进行查询,使用封装的 xc_get_sql 方法来发起数据查询,该方法内置了缓存设计方案。如果缓存被关闭,相同的 xc_get_sql 请求也会被标记为不使用缓存的情况。若 ID 不是数字,则将其视作鉴定编号进行处理。为此,系统会构建一个缓存键名(形式为 query_identify:" . $id),并使用 get_redis_meta 方法检查 Redis 缓存中是否已存在对应的数据。如果缓存中有结果,则进一步判断其内容,如果结果为字符串 "false",则直接返回标记为 false 的结果。对于其他情况,直接返回缓存中的数据。不存在缓存时,系统初始化数据库表名并添加 WordPress 前缀,准备生成 SQL 查询语句以通过鉴定编号查询数据库。查询操作会获取一行结果作为关联数组返回。若查询成功,结果会被缓存至 Redis 中,缓存有效期为一天。若查询失败,则会将结果记为 'false' 缓存至 Redis,防止后续重复查询。
5、function/query.php订单缓存查询脚本库现已集成至宫论核心库中。对于所有使用宫论的项目,这意味着可以直接调用该脚本库的文件和方法,而无需加载任何外部依赖。考虑到订单查询是一个非常关键的环节,后续操作会相当频繁,直接将其继承到核心库中将有效减少频繁引入的麻烦,提升系统性能与操作效率。
6、order_details(鉴定订单页面)基于全新的标准构建,标识命名通过动态化引入实现优化。page-content容器添加了xc_app子类,以明确页面属于APP移动端,从而支持标准组件的集成与监听功能。前端在进行页面交互监听时,可以结合页面标识和content使用,以精准定位和操作元素。此外,该页面还通过is_page方法判断最终页面的位置,提升了页面的响应能力和管理效率。
7、在xc_is_page_open访问拦截钩子处,新增了一项拦截机制。当用户请求访问identify_order_details页面时,将启动xc_query_identify方法检查鉴定订单号是否有对应记录。如果查询结果为不存在(即返回false),系统会立即激活拦截机制,将用户强制重定向至错误页面,并在页面上明显提示【鉴定订单号不存在】。此拦截在页面加载之前便已完成,以确保用户无法访问不存在的鉴定单据页面,从而提升系统的整体安全性与用户体验。
8、为确保鉴定订单列表页面的设计规范明确,使得鉴定师和用户在查看时不会出现功能模块重叠的状况,页面设计需考虑区分两者的不同操作权限。由于该页面既供鉴定师也供用户查看,因此需要根据订单的不同状态(如待鉴定、已鉴定、已退回、已取消)提供相应的操作选项。为此,当用户进入页面时,系统将生成两个变量以明确身份:一个对应鉴定师(expert),另一个则对应申请人(applicant)。如果来访者是鉴定师,则expert变量为true;如果来访者是申请人,则applicant变量为true。页面操作功能的构建将依据这两个变量的状态来判断权限,确保功能模块的操作体验清晰、界限分明,从而避免产生误操作和功能混淆的情况。
9、在订单详情页中新增了一个名为“apply_box”的页面容器,用于展示鉴定申请的基础信息。具体条目包括:鉴定编号(如xxxxxxx)、鉴定栏目(通过key参数鉴权后返回对应分类,如瓷器)、鉴定人(显示站内的昵称信息)、鉴定申请时间(格式为Y-m-d H:i:s)、鉴定状态(根据订单的status字段输出对应内容,例如状态1表示“等待鉴定”)。
10、对鉴定订单表(xc_identify)进行了索引优化处理。首先,将number(鉴品编号字段)设置为主键唯一值,并为其建立单独索引。这是因为许多后续查询都依赖于鉴定编号,为了提升性能,这一优化是十分必要的。其次,将price价格字段的数据类型从varchar(32)调整为decimal(10,2),以便更准确地表示和处理金额,例如2.32元。最后,删除了原有分类索引中的number字段,因为该字段已升级为主键,组合索引已不再需要。
11、新增通用CSS样式规则【box_info】,该样式专用于页面头部容器内容的展示。此前,每次都需要单独编写样式,非常不便,而且这样会导致样式表逐渐变得庞大冗杂。因此,我们引入了一个固定类名,通过此类名统一管理样式。这一新样式将与WeUI组件配合使用,以提升样式美观度,主要用于展示单据和客户信息的基础内容。
12、鉴定订单状态包括以下几种:1. 待鉴定:鉴定订单已完成付款,当前正等待鉴定师进行评估。2. 已完成:鉴定师已对订单完成了鉴定工作。3. 已退回:由于某些原因,鉴定师将订单退回,需进一步处理。4. 已取消:用户在鉴定师开始鉴定前主动取消了申请。5. 鉴定关闭:由于超时、违规操作或其他原因,订单被系统或管理员强制关闭。请注意,状态3和4的订单都会触发退款流程,意味着鉴定订单的关闭,一个是由鉴定师操作关闭,另一个则是由用户操作关闭。
0
小小乐
lv.2
实名用户
2024年10月28日
1、在infinite_loading页面监听器中新增了一个作用域变量:infinite_content。该变量用于定位到.page-content. + page_name + _content元素的位置,即页面page-content容器的内部。这一调整是因为许多自定义属性无法通过组件模块直接获取,因此在执行AJAX分页加载请求时,需要使用page-content选择器对页面属性进行调整。为了避免重复调用造成的性能浪费,此次优化提前将选择器结果存储在作用域变量中,实现更加高效的页面操作。
2、在xc_template_infinite_page_html模板组件方法中,新增了一个可选变量:meta数组字段,默认为空数组。该变量用于在特定场景下传递自定义属性。例如,在鉴定师订单列表页中,分页加载时需要传递鉴定师的对象UID;或者在查询已完成退款的支付订单时,需要提供status状态字段进行判断。这些需求都可以通过传递meta数组来实现处理。模板内部会解析meta数组,并将相关属性写入待生成的模板HTML中。
3、安全优化:目前,宫论模板组件中的所有字符串信息都会通过esc_attr方法进行转义处理,以有效防止非法字符或恶意脚本的注入,避免可能导致的恶意执行问题。注意,此优化措施适用于所有模板组件中自定义PHP变量的字符串输出,确保每一处都经过esc_attr进行安全处理,避免非法参数写入的情况出现。
4、在后台新版缩略图配置中,新增了一个场景功能,即藏品鉴定的图片缩略图配置(identify)。用户提交藏品进行鉴定时,上传的图片将默认通过缩略图样式进行呈现。只有当用户点击查看大图或使用灯箱浏览时,才会真正加载原图。这一设计有效地减少了不必要的流量消耗,并显著提升了页面的加载速度。缩略图的样式采用:?imageMogr2/thumbnail/300x。值得注意的是,这种缩略图配置将贯穿整个宫论项目,是实施不可或缺的一部分。
5、新增鉴定订单详情页面:module/xc_identify/order_details.php,页面唯一标识:xc_order_details。该页面是一个关键的功能模块,专用于展示鉴定订单的详细信息。默认情况下,此页面的访问权限仅开放给鉴定师和发起鉴定的用户。根据用户权限的不同,他们在查看页面时获得的信息和可操作的选项也会有所差异。鉴定订单具有多种状态,而每种状态下,不同的用户和鉴定师可以执行的操作选项也各不相同。这也使得页面的设计变得相对复杂,但其对于整体业务流程至关重要。
6、访问鉴定订单详情页时,需要通过GET方式传递两个参数变量:1、id,即鉴定订单数据表的主键id值;2、number,指鉴定编号。这两个变量参数用于识别当前用户访问的鉴定藏品订单的唯一标识。通常,只需根据实际情况传递其中之一即可。如果两个参数都为空,页面将返回错误提示。建议优先使用number来传递变量,以避免对外暴露id。
7、鉴定师订单详情页现在按照新标准构建。首先,页面标识采用动态变量进行传递,所有涉及页面操作的地方均通过page_name变量进行输出。其次,在核心库的脚本加载完成后,会立即加载页面访问事件拦截文件(ajax_page),使用内置方法过滤和屏蔽非法及恶意访问行为。最后,引入模板引擎文件,通过引擎生成和处理订单详情页的模板组件。
8、订单详情页集成【xc_is_page_open】访问拦截钩子,当用户访问订单页面的时候,会判断是否有权限进行访问。判断标准如下。通过id或者number来构建wpdb方法去获取鉴定订单表信息,同时使用xc_is_login获取当前用户ID。并与返回的结果进行进一步对比,如果当前用户不是指定鉴定师、不是发起鉴定用户。则视为无权访问。注:拦截钩子执行的时候需要主动传递id或者number,要不然无法获取到相应参数信息。
9、新增了一个名为 xc_get_identify() 的订单读取方法,该方法专门用于获取鉴定订单的信息。其参数需要传递一个变量ID,这个变量支持输入鉴定编码(number)或鉴定表主键ID,函数内部会利用正则表达式来判断ID的类型。借助 WPDB,该方法能够读取并提取鉴定师订单的详细信息。当信息读取成功时,该方法将返回一个包含相应数据的数组结构;如果读取失败,则返回 false。
10、xc_query_identify方法现已支持缓存设计方案,缓存的键值为:get_identify:(鉴定编号或主键)。该方法首先检查缓存中是否有记录,如果存在则直接返回结果,提高了查询效率和响应速度。如果缓存中没有记录,则通过wpdb查询获取相应记录,并在返回结果之前将其存储到Redis缓存中,缓存有效期为86400秒(1天)。需要注意的是,如果wpdb未能查询到结果,方法会返回false,并将此结果以字符串形式写入缓存。当读取缓存时,会首先判断返回结果是否为字符串'false',如果是,则直接返回false。这种处理方式确保了Redis缓存的结果更为精准可靠。
11、宫论项目新增了脚本库【function/query.php】,此脚本专门负责管理和维护订单查询接口的封装。所有订单类型的查询接口按照统一的封装规则命名为:xc_query_订单类型。例如,淘货订单查询接口为:xc_query_tao,保真阁订单查询接口为:xc_query_bzg。传递的参数将根据不同订单类型进行确定。该脚本的核心目标是实现统一管理,提升后期维护的便利性。鉴于订单查询接口通常涉及复杂的缓存管理机制,实施统一管理显得尤为重要。
12、在xc_query_identify执行结果返回前,会首先进行权限验证。如果当前用户未通过xc_is_login验证登录,则直接返回false。若用户已登录,在读取缓存或从wpdb获取结果时,系统会核实用户身份是否为鉴定师或本人账号。如果以上条件均不满足,也会直接返回false。不过,如果用户是管理员,则会跳过这些拦截措施。通过这一验证机制,确保鉴定订单的返回结果仅对相关当事人可见,增强数据的安全性和隐私保护。
0
小小乐
lv.2
实名用户
2024年10月27日
1、修复并解决了“我的鉴定列表”页面的下拉滚动监听问题。在鉴定师向下拖动页面时,现在能够正确检测页面距离底部的距离。如果该距离超过500像素,则会触发下拉的ajax事件,从服务器请求更多数据以填充页面。之前版本使用的是page_content容器来处理监听事件,而在新版中,改用了模板组件,因此需要调整监听器的位置。通过调整后,监听器能够在页面拖动过程中实时计算距离,确保能够正确触发下拉加载功能。
2、宫论分页数据接口统一化标准:默认页数设定为20,无论是首页还是后续的分页数据请求,皆默认返回20条数据。为了防止兼容性问题,现有的分页请求暂时不做调整,依旧按照原先的页数进行数据返回。然而,对于通过模版组件构建的分页请求和下拉数据,一律采用20条的新默认值。需要注意的是,传统的10条返回可能在后续的大屏和折叠屏处理时出现兼容性问题,可能导致无法触发下拉滚动监听。
3、优化了全局页面的下拉滚动监听事件。现在,在监听当前页面(模板组件)的自定义属性page(页数)时,如果发现该属性为0,将自动触发$('.page-content.' + page_name + '_content').trigger('infinite');事件,从而进行数据初始化请求。通过这种方式,即使在模板分页组件场景中未主动传递初始化数据,也能够在用户访问页面时自动完成数据的初始化装填。
4、分页模板组件现已支持【infinite_loading】全局对象的判断处理,该对象负责管理所有AJAX分页请求。对象键值为【infinite_loading[page_name],其中page_name是页面的唯一标识】。当页面符合分页加载请求条件时,对应的键值为true,不符合分页加载请求时则为false。在实现无尽滚动监听时,需要通过判断infinite_loading对象是否符合AJAX请求,以防止无限加载情况的出现,从而避免性能开销的浪费。
5、为了确保首页内容准确展示,分页模板组件的初始化内容的时,首先会通过page_list.empty()方法清空页面原有内容,避免原来的页面内容与新加载的数据叠加。完成清空操作后,在调用trigger('infinite')方法模拟滚动下拉事件,实现页面数据的重新填充。修复了之前未进行内容清理而导致的数据加载错误,避免了新的分页数据被加载到原来默认错误提示的后面。
6、宫论统一分页接口现在已适配(infinite_paging_api)请求,当收到模版组件构建的分页请求,都将转发到这个接口进行处理。该接口需要传递infinite数组对象,必备的参数有【page:页码,表明当前是第几页、key:场景标识,唯一属性】。可选参数有很多,可以根据场景的需求来传参,比如【sort:请求分类、author_id:用户对象】等等。
7、模板分页接口文件现已调整为返回标准的 JSON 数组结构。由于分页场景多样且各自返回的错误不同,所以不适合采用传统方式来返回数据结构(例如,在无数据时直接返回 false)。这种情况下,前端无法有效处理错误码,因此采用数组结构来处理返回结果。具体而言,code=0 表示数据返回成功,html 已经封装好的前端内容字符串(前端可直接插入);code=1 则表示无记录或有错误,msg 字段提供具体的错误信息。
8、考虑到前端解析存在困难,分页接口在返回数据时,即使没有记录或出现错误,也会包含一个HTML字段。这一字段会通过xc_empty进行转换处理。前端只需专注于对code值进行判断,即可接受结果,将分页接口返回的HTML字段直接插入到相应的容器中。这样既减少了前端的解析和处理负担,也使得后续对返回结果的管理和维护更加简便。
9、前端已完成分页组件模板的结果处理。在服务端完成数据请求后,前端会根据返回的code值执行相应的页面逻辑。首先,如果成功获取到分页数据,则会将生成的HTML内容通过append方法插入到页面底部,并将page变量递增1。接着,通过attr方法将当前页数设置为有效值,同时将infinite_loading[page_name]标记为false,以允许继续触发下拉滚动来加载更多数据。其次,如果未能获取到更多的分页数据(code=1),则会将错误信息通过append方法显示在页面底部,并将infinite_loading[page_name]标记为true,以阻止后续的分页滚动加载。
10、新增前端回调钩子:template_infinite_page_callback()。该钩子将继承模板分页组件中的infinite对象属性值,并在服务端成功返回JSON数据包后被触发,无论code状态如何,都会主动触发此事件。目前,该钩子主要执行两个操作:首先,它会关闭加载动画,以完成页面的交互动作;其次,通过empty方法移除list中可能出现的xc_empty错误提示。
11、为优化前端回调钩子的管理,新增了脚本文件(callback.js),唯一标识为(xc_callbac)。该脚本采用延迟加载的方式,在页面完全加载后执行。通过wp_enqueue_script方法,将其加载到宫论项目中,仅供移动APP端使用。值得注意的是,所有回调事件均被整合到此脚本中,以便后续的维护和更新更为便利。此前使用的HOOK脚本方案非常不便,因此进行了这一改进。
12、宫论服务端同样也新增一个回调动作脚本【function/callback.php】该脚本库负责宫论统一钩子的回调处理,命名规范:xc_钩子的名称_hook_callback($result)在设计钩子的时候,如果需要对返回结果进行后续业务交互处理的时候,就集成一个回调动作脚本,在动作脚本中使用websocket+redis,来完成消息转发功能。注:回调动作,必须是已完成状态,并且不支持任何形式的结果返回监听。只是单纯的触发事件。最好采用异步来处理回调行为,避免阻塞钩子的业务进程。
0
小小乐
lv.2
实名用户
2024年10月25日
1、在处理媒体文件的回调动作时,当鉴定订单成功建立后,系统会从identify数组中检查是否包含【image:图片列表、video_url:视频地址】等信息。如果存在这些数据,将调用xc_upload_media_ok方法,将相关的图片或视频上传记录更新至对应的鉴定表ID。这一过程确保相关的附件媒体信息与鉴定订单正确关联,防止被系统的计划任务误删或延迟处理。
2、针对xc_upload_media_ok钩子进行了优化,现在第二个变量不仅支持字符串形式的图片或视频地址(切割;),还能够处理数组结构的图片列表。这个方法通过is_array函数来检测变量类型。如果检测到变量不是数组,就会使用explode函数对字符串进行切割处理;如果检测到是数组,则直接跳过切割环节。这一调整有效提升了方法的灵活性和兼容性。
3、在鉴定师获取新订单通知时,系统出现了“Uncaught Error: Call to undefined function get_user_mea()”的错误信息。这个错误的根本原因在于“Undefined variable $id”,具体来说,是因为在通知数组中,当尝试下发消息时,需要提取鉴定订单ID,并获取相应的鉴定信息。然而,在通过xc_get_sql函数读取数据时,由于ID参数缺失,导致了一系列的异常回调错误。目前,所有相关问题已被逐一修复。
4、已修复并解决大量出现的【Warning: Trying to access array offset on value of type bool in 】报错,问题出现在517、527和536行。该错误是由于identify并不是一个数组,试图提取键值时返回异常。这一问题导致短信和邮件消息发送出现异常,而服务号和公众号未受影响。经过排查,发现异常源于xc_identify数据表返回的数据错误,现已完成修正和处理。
5、藏品鉴定助理的UID参数已从19更改为35,以避免鉴定藏品类型订单通知错误地由余额助理下发。正确的服务号消息应由UID 35,即鉴定助理来处理。在创建鉴定师服务号消息通知时,由于疏忽忘记修改这个参数,导致所有鉴定订单的站内信和服务号消息都错误地由余额助理进行处理。
6、今天解决了在通过服务号消息访问订单列表时出现的致命错误问题。该错误具体表现为“Undefined array key 'author_id'”和“Uncaught ArgumentCountError: Too few arguments to”的报错。这一问题源于xc_is_page_open函数在访问拦截时需要传递author_id参数,而用户查看自己的订单时通常不会传递这个参数。为此,采用了三元运算符来处理参数可能为空的情况,从而成功避免了报错现象。
7、在修复访问鉴定师订单列表页面时,发现通过xc_identify_expert_identify_order_list_consult接口返回结果为空,并且出现了致命异常。经过排查,问题出在缺少对author_id的传递。该方法需要两个关键变量:author_id和$status,然而页面中并未主动传递author_id,这导致数据读取失败并引发相关错误。为解决此问题,需要确保在接口调用前,页面正确传递所需的author_id(鉴定师访问,这个值应该是user_id)。
8、修复并解决了【鉴定师订单列表】页面返回的错误问题,包括“Undefined variable $list_consult in”和“Undefined array key 'author_id' in”。由于新版接口已无需通过内置方法主动发起初始数据的加载,因此原来的list_consult数组对象已被移除。新版方法可以自动读取组件数据,从而顺利完成订单初始化的加载,实现了更高效的数据处理流程。
9、在开发分页滚动加载模板组件时,通过使用模板引擎生成该组件,以往流程中author_id(操作对象UID)是通过配置文件设定和提取的。然而,在实际的业务操作中,该变量应通过页面的GET请求参数来获取。如果继续采用固定值提取,可能会导致页面数据加载异常。因此,为了避免错误返回,我们决定取消这一属性的固定配置方式,使其更加灵活地通过页面传参进行动态获取。
10、分页加载组件的初始页数从1调整为0。之前由于初始页数设置为1,自动监听器会误认为页面已有内容输出,从而不会自动触发内置的ajax分页请求接口向服务端发送数据初始化请求。这一数值设置错误直接导致用户在访问订单列表页面时,无法看到相应的订单数据列表,页面显示为空白。
11、前端新增了一个名为is判断方法的xc_is_now_page(),该方法用于返回用户当前所在页面的标识。如果同时打开了多个页面,该方法只会识别出用户当前所处的最后一个页面。方法的判断逻辑如下:首先检索页面元素 page-content.xc_app,并通过last来获取最后一个页面。如果成功获取到相关元素,则直接返回该页面的标识名称(可通过page_name自定义属性来获取)。如果未能成功获取,则返回false。需要注意的是,该方法非常可靠且有效,当需要检测用户所在页面时,基本可以得到准确结果。但需特别留意的是,该方法仅支持新版页面,应避免因不支持旧版页面而错误地返回false。
12、宫论APP端页面路由访问机制新增了方法 xc_page_visit(),用于发起移动端页面访问请求。此前,大多数请求都是通过 xc_mobile_url(link) 方法处理,该方法仅支持通过JavaScript直接访问URL,并仅限于APP内嵌页面,适用于传统页面的跳转。然而,这样的方式无法满足现代页面访问的多样化需求。为了应对这些需求,新的页面访问请求方法需要支持多种操作,包括页面正常向下跳转、页面向上后退访问、刷新当前页面以及在当前页面加载新的内容。因此,我们特地设计了这个新的页面请求方法,以拓展现有功能,提供更灵活的页面访问机制。
0
小小乐
lv.2
实名用户
2024年10月24日
1、支付成功订单的回调动作进行了新的封装处理。如果支付请求是藏品鉴定请求(identify),那么在完成缓存清理和数据表插入等一系列操作后,会通过xc_notify_hook下发通知给鉴定师。该消息的场景标识为identify_apply,并且附带以下参数:1、user_id:申请鉴定的用户ID;2、id:鉴定订单的主键值。
2、identify_apply消息场景,通用的三个字段变量值分别为:title:新的鉴定订单、content:XXXX,向你发起了藏品鉴定申请,请及时处理、link:这个通过短代码进行生成,指向的地址是用户鉴定师订单列表页(非订单详情页)。具体地址参数为:do_shortcode(' [xc_module type=xc_identify]/expert_identify_list.php')。基本站内信、app、服务号的消息内容,都固定为上述字段。
3、鉴定师在收到新的藏品鉴定请求时,系统会通过xc_notify_hook接口发送短信通知。短信内容为:“{1} 您好,您有一条新的鉴定请求等待处理,请及时前往APP处理!”,其中{1}为鉴定师的名称,采用动态参数传递。为了避免过多打扰,每位鉴定师每天最多接收五条此类短信,超过五条的请求将不触发短信发送。
4、除了短信通知提醒外,新的鉴定订单现在也支持邮件通知提醒。鉴定师如果绑定了邮箱,就可以收到邮件通知。邮件标题为“新的鉴定订单”。邮件正文如下:尊敬的 $user_nickname,您有一条新的藏品鉴定申请,详细信息如下:申请者: $user_nickname,申请时间: " . date('Y-m-d H:i:s') . "订单编号: 。请及时处理该申请。如需帮助,请联系官方客服进行处理。
5、在执行消息通知时,许多参数并未从外部传递到通知数组对象中。因此,需要通过xc_get_sql方法来读取之前建立的鉴定订单,获取如【鉴定编号、鉴定藏品的申请信息,例如分类和鉴赏描述】等详细信息,并将其写入到通知消息事件中,以丰富提醒内容。需要特别注意的是,鉴定编号应从number字段读取,而不是从废弃字段order中读取,order字段将在后续版本中删除。
6、服务号与站内信的通知功能已经完成封装处理,通知的接收对象为【鉴定师助理】。标题为:藏品鉴定申请。正文内容为:xxxx向你发起了藏品鉴定申请,请及时处理。菜单选项包括:菜单1(鉴定编号:ddddddd)、菜单2(申请时间:' . date("Y-m-d H:i"))、菜单3(申请人:' . get_user_mea($author_id, 'nickname', true))、备注部分如有鉴赏描述,则在此处显示。
7、公众号模板消息通知功能已成功部署。若鉴定师绑定了微信且关注了公众号,那么在收到鉴定请求时,系统将自动向对方发送公众号消息。消息的模板标题为【订单处理通知】。其中,keyword1显示鉴定的编号信息,keyword2告知用户有一条新的藏品鉴定申请。使用的模板编号是YRpZrq__R2hb0i1vBoJr1n0snvWcyXoLWpkWJBiXtQA。请注意,公众号模板消息每日发送有30条的限制,超过这一限额后,当天将暂停发送。
8、identify_apply消息通知场景现已全面封装完成。当支付订单触发回调动作时,系统将向鉴定师发送新鉴定订单提醒。这些提醒的内容包括短信、邮件、公众号、站内信、APP通知和服务号消息。其中,短信、邮件和公众号提醒需要鉴定师事先绑定相关信息才能接收,且每天有收发限制。相较之下,站内信和服务号消息则无此限制,确保能及时地传达到每位鉴定师。
9、已修复用户支付藏品鉴定费后,系统生成鉴定订单时出现的两个关键字段缺失的问题。缺失的字段是“cat”(藏品的所属类别)和“collection”(包含所有申请信息,如图片地址、视频地址、鉴赏文字描述)。这些字段的缺失导致订单无法被正确指派。经过排查,问题源于token令牌写入错误。由于安全性考虑,整个交互过程依赖于令牌进行鉴权,鉴权中的意外错误导致信息丢失。目前已修正令牌写入机制,确保鉴权过程的稳定性和信息完整性。
10、在藏品鉴定支付订单回调的优化方面,新增了一项功能:在进行缓存清理时,会主动清理鉴定草稿和鉴权令牌的缓存键值。这一措施旨在避免因令牌未过期而可能引发的安全隐患,即同一令牌可能会被多次用于发起付款请求。同时,我们也移除了草稿记录,以确保在藏品发布时不会误导入已付款的鉴定信息。
11、已修复支付回调接口中返回的异常错误【Attempt to read property "prefix" on null I】。问题的根源在于通过wpdb构建SQL语句进行插入操作时,未提前引入wpdb,导致语法出现异常,从而造成前端接收到意外报错。此外,该错误还导致同步回调接口出现故障,无法主动退出统一支付页面,不过websocket下发的回调通知仍能正常执行。目前,这一问题已经得到有效修正。
12、藏品鉴定支付回调通知已完成封装动作。在用户完成付款后,将依次执行以下步骤:首先,触发统一的回调事件,包括支付订单回调和通过websocket进行消息下发。接下来,系统会创建相应的xc_identify鉴定订单记录,并从令牌中提取相关的图片、视频和文字信息,正确写入对应字段。同时,系统会处理原支付订单中的【shop_order、shop_type】字段绑定回调。为保证数据的可靠性,将执行相关的缓存清理。最后,下发xc_notify_hook消息通知,确保整个流程的完成和数据的一致性。
0
小小乐
lv.2
实名用户
2024年10月23日
1、服务端新增了一个业务请求:identify_expert_manage。当鉴定师的首席鉴定师(官方)资质被管理员设置或取消时,该请求会被触发。此方法需要传递一个固定参数:status,其中1表示将当前鉴定师设置为首席鉴定师,0表示取消其资质。由于该方法相对简单,因此不需要推送通知消息,以避免可能的误操作(后期如有需要可以补充通知功能)。因此,不需要封装成功钩子,直接在API业务逻辑中进行处理即可。
2、为official_identify_expert_switch元素新增一个自定义属性:author_id(当前鉴定师的UID)。在通过change事件进行状态切换时,将从当前操作对象中提取该鉴定师的ID,并与状态信息一起发送到服务端进行处理。服务端在执行状态变更时,会通过xc_is_identify_expert验证操作用户是否为鉴定师,如果验证失败,则返回相应的错误信息。
3、在前端进行状态切换时,会通过 xc_is_admin 验证用户身份是否为超级管理员。如果用户不是超级管理员,则会弹出错误提示,并将 official_identify_expert_switch 元素的状态恢复到原始状态,同时阻止后续的 AJAX 请求。同样地,服务端也会进行基础规则的拦截。注意:只有超级管理员才有权限设定官方鉴定师的资质。
4、新增了一个服务端钩子:xc_identify_expert_manage_hook。该钩子用于处理鉴定师是否为首席鉴定师的业务逻辑。它需要接收两个变量:author_id和status。在内部,该钩子会执行相应的业务处理,并返回一个标准的数组结构,其中code=0表示操作成功,code=1表示执行失败,msg则提供失败的详细原因。为了便于后期的维护和扩展,我们将其封装为钩子进行处理。
5、设置首席鉴定师是一项极为敏感的操作,即使在超级管理员状态下,也必须进行严格的安全验证,以防止任何非法行为的发生。前端通过user.is_security来检查安全性,如果验证不通过,则会执行xc_hook_jump_page进行页面跳转。服务端则通过xc_is_security进行安全性验证,如果检测到不安全的环境,会提示【设备环境不安全,需要短信验证。】并返回jump=security,要求页面强制跳转以进行处理。
6、在处理首席鉴定师的操作时,服务端首先会进行基础的安全校验,确保所有安全检查完全通过。接着,通过调用 xc_is_identify_expert 方法获取鉴定师数据表的主键ID,然后使用 xc_update_sql 方法更新鉴定师的 official 字段。完成SQL操作后,服务端会返回 code=0 和 msg=操作成功,以便前端进行进一步的响应处理。
7、在进行缓存清理操作时,当超级管理员对鉴定师的资质进行设置或取消(例如首席鉴定师)时,系统会更新xc_expert数据表的结构。为了确保在其他事件中通过xc_is_identify_expert方法获取鉴定师信息时数据的一致性,必须同步更新缓存。缓存的清理键值为identify_expert:加上$author_id。清理操作通过调用delete_redis_meta方法来执行异步清理,以确保缓存中的信息与数据库保持一致。
8、在服务端增加一个额外的验证机制,当鉴定师的状态不正常时,系统应立即返回错误信息:“错误:鉴定师状态非接单状态,不可设置”。只有当鉴定师的状态字段为2(表示可接单)时,才允许进行进一步的操作。这一机制旨在防止那些处于封禁状态或已停止接单的鉴定师被误设为首席鉴定师。需要注意的是,如果是取消首席鉴定师的资格,则可以绕过此限制和拦截。此设计的初衷是避免停用的鉴定师被误操作为首席鉴定师。
9、服务端新增了一个名为xc_identify_expert_manage_hook_ok的回调通知钩子。当首席鉴定师的资质发生变动并且操作成功时,该钩子将被触发。此钩子会接收两个变量:$author_id和$status。如果后续需要集成推送通知消息,或者在为鉴定师写入一些自定义字段时,可以通过这个回调来实现。该钩子不返回结果,也不接受处理请求,仅用于执行相应的操作。
10、当服务端完成首席鉴定师状态变更请求后,会返回一个JSON数据包供前端处理。前端接收到结果后,将根据code值执行相应的交互操作。首先,调用xc_loading_hide函数以关闭加载指示器。接着,使用xc_msg函数触发消息提醒,消息内容由服务端返回,提示操作成功或失败。如果code值为1,则还需额外触发复原按钮的动作事件。
11、在调整首席鉴定师的认证状态时,页面显示“您没有权限执行此操作”的错误提示,这是因为前端使用了错误的判断方法导致的问题。正确的做法应该从user对象来判断用户是否是管理员。同时,还需要修复服务端返回的错误信息,即“Undefined array key 'author_id'”。这个问题是由于前端未能正确获取author_id,导致参数传递异常所致。确保正确地传参以解决这个问题。
12、新增方法xc_is_identify_manage($user_id),该方法接收一个鉴定师ID,用于判断该鉴定师是否为官方鉴定师。如果该用户是官方鉴定师,则返回其详细资料,以数组形式呈现;如果不是,则返回false。需要注意的是,即使是鉴定师,只要不是官方首席鉴定师,此方法同样会返回false。若需判断是否为普通鉴定师,请使用方法xc_is_identify_expert进行处理。
0
小小乐
lv.2
实名用户
2024年10月22日
1、在xc_hook_subnavbar函数中,第一个变量从key改为page_name。这是因为页面的操作逻辑通常是通过page_name来初始化和管理的,为了保持一致性,提高代码的可维护性,建议在此处也采用page_name作为变量名。由于监听器和钩子的处理逻辑基本保持一致,因此如果代码发生变动,两者都需要做出相应的适配性调整,以确保系统的稳定和功能的连贯性。
2、在完成菜单切换的基础事件处理后,系统将执行一系列操作以触发页面数据的加载。首先,需要将页面组件的sort参数属性更新为从钩子传递过来的参数,以确保菜单状态标识得到及时更新。接着,将page页码重置为0,这样在之后进行ajax请求时,实际请求的页码将会是1,从而确保数据从第一页开始加载。此外,使用empty方法将现有的page_list内容清空,以为即将到来的新数据填充预留空间,确保新的数据能够无误地被加载并显示在页面上。
3、xc_hook_subnavbar 的数据填充模式并没有采用传统的方法,而是通过在内部构建相应的 Ajax 请求,向服务端请求数据,然后在页面上执行插入操作或其他交互动作。这种方法的维护相当不便,要求对监听器和钩子同时进行同步修改。为了提高维护效率,现在采用了一种新的填充模式,即直接通过触发器(trigger)来激活 infinite 元素,从而模拟数据填充操作。这一方法转而利用内置的监听器来实现数据的自动填充。
4、宫论分页数据填充的业务逻辑已经基本完成封装,新版本的下拉数据加载机制已经完全以组件的形式引入,只需在页面上设定对应的参数信息,即可轻松实现滚动条的部署工作,避免了每次执行分页加载请求时都要繁琐地编写大量监听器代码。分页数据填充模式还支持菜单切换功能,并提供了一个前端钩子,用于处理菜单切换时的业务交互。
5、鉴定师订单列表页(identify_expert_order_list)现已顺利集成了下拉滚动组件和菜单切换钩子,极大提升了用户的交互体验。页面的数据加载与切换操作均由内置监听器自动完成。当用户进入页面时,系统首先检测页面中是否包括相应的组件标识;若检测到存在,则会立即构建相应的组件模块,并通过触发器来初始化数据加载。当用户进行下拉动作时,页面能实时监听并迅速响应,实现数据的自动填充,
6、在执行支付鉴定订单的回调动作时,通过xc_insert_sql方法将支付表中已成功付款的单号和收款人信息一起插入到xc_identify鉴定订单表中。这样一来,鉴定订单便可以通过payment字段获取到支付订单数据表的详细信息,例如追踪退款详情、核对支付订单数据等操作。此外,为了简化查询过程,此处写入的单号为ID主键。
7、当用户完成藏品鉴定订单的付款操作后,系统会自动触发一个额外的缓冲清理操作。这一操作通过调用 clean_redis_key 函数,将所有与鉴定师订单列表相关的分页查询缓存彻底清除。由于新的订单产生,之前的缓存内容不可避免地需要更新,因此进行此操作是必需的。缓存的清理按照特定的键值标准进行,具体为 expert_identify_order:*。请注意,这意味着系统将清理掉所有鉴定师订单记录的查询缓存,从而确保数据的最新和准确。
8、在对鉴定师订单缓存机制进行优化时,我们对缓存键值的命名方式进行了调整,新的命名格式为:expert_identify_order_' . $author_id . ':' . md5('consult' . $status . $offset . '-' . $number)。此次调整的关键变化在于将author_id(即鉴定师的UID)从MD5哈希计算中移除,并直接插入到缓存键的前端位置。这一改动的主要好处在于,当需要清理缓存时,我们可以更具针对性地清理特定鉴定师的记录缓存,而无需对所有鉴定师的记录缓存进行全面清理。
9、在鉴定师配置页面,我们增加了一个新的字段:xc_identify_official_list(官方鉴定师)。这个字段用于填写鉴定师的UID,对于多位鉴定师,我们使用分号进行分隔。这个名单中的鉴定师被视为官方首席鉴定师,他们在鉴定藏品为真品时,用户可直接进行送拍或选择寄售回收操作,而无需进一步的官方审核。需要注意的是,这个方法尚未最终确定,此外也可以考虑通过用户资料页面来实现官方身份的设定与绑定。
10、新增的字段“official”(VARCHAR(16))旨在为鉴定专家表(xc_expert)增加一个官方标识功能。当某位鉴定师被认定为官方人员时,此字段将被设为“1”;如果不是官方鉴定师,则该字段保持为空或标记为“0”。如果鉴定师具备官方身份,系统将优先推荐其进行鉴定,而且他们出具的鉴定报告上也会特别注明官方标识。此外,官方鉴定师所鉴定的藏品一旦确认为真品,便可以直接进行拍卖等相关操作。此举可以提升官方鉴定师的权威性和可信度。
11、在鉴定师资料管理页面中,基础资料区块(identify_expert_info)新增加一个切换开关,用于控制当前鉴定师是否具备【官方鉴定师(首席认证)】的身份。当页面加载时,系统将读取鉴定订单表中的official字段,以确定该鉴定师的当前状态。如果该字段显示为官方认证,则开关默认设置为选中状态,即属性为【checked="checked"】。若非官方认证,则开关处于未选中状态,移除checked属性。管理员可以通过切换此开关来轻松设置或取消鉴定师的官方认证状态,从而灵活管理鉴定师的认证资格。
12、在identify_expert_manage页面新增了一个change监听器,用于监控official_identify_expert_switch元素的状态变化。当该选项框的状态改变时,系统会检查其当前的布尔值状态。如果状态为true,则将变量status初始化为1;如果状态为false,则将status初始化为0。随后,程序通过ajax将这个status变量发送至服务器,以便进行相关业务处理。此变量的值用来确定鉴定师是否担任官方首席鉴定师的角色。
0
小小乐
lv.2
实名用户
2024年10月21日
1、分页API接口现已支持(infinite_paging_api)请求。当监听器自动触发分页请求时,系统会自动解析无限数据包,并构建标准的分页方法以获取当前分页数据。需要注意的是,由于请求的复杂性,服务端的分页接口数据返回将根据不同场景进行自定义处理。整个监听器场景,自动化部署仅是针对前端处理。
2、通过使用xc_template_infinite_page_html模板生成的前端分页滚动加载组件,我们新增了一个自定义属性,即场景的标识名称(也可以理解为页面标识)。在现有的前端触发器中,这个标识名称会被提取到infinite对象数组中,并传递到服务端进行响应处理。服务端将根据这个标识名称来判断请求的来源,从而执行相应的分页请求数据填充操作。
3、服务端分页接口触发器请求现已支持【鉴定师订单列表:identify_expert_order_list】的数据返回处理。当收到该场景的请求时,系统将通过xc_identify_expert_identify_order_list_consult方法获取相应页码的订单数据。如果数据获取失败,系统会返回相应的错误提示;如果数据获取成功,系统将遍历数据并将其赋值到HTML中进行展示。
4、为了优化鉴定师订单的分页方法,将第一个参数从user_id更改为author_id。这是因为分页请求可能由管理员发起以查看鉴定师的订单。如果使用user_id作为参数,传递的用户UID会被内置的xc_is_login覆盖,导致返回的并非指定用户的鉴定订单,而是当前用户的鉴定订单。请注意,函数内部相关的用户参数已经进行了相应的修正处理。
5、模板组件方法:xc_template_infinite_page_html 新增了一个第三个可选变量 author_id。在某些场景下,需要读取指定用户的 UID 来获取分页数据。例如,查看审核日记、用户的鉴定申请记录或淘货的订单交易记录。这些场景都需要传递相应的用户 UID(而非当前用户)以便返回指定的参数。在这些情况下,提取页面的 UID 是完成订单数据源处理的关键步骤。
6、分页模板组件的方法得到了进一步优化,现在仅保留两个变量。第一个变量是key,用于标识场景;第二个变量是infinite,这是一个数组,默认情况下为空。如果不需要传递特殊参数,可以选择将其置空。举个例子:如果我的组件方法需要使用author_id(作者)这个参数,那么可以通过infinite['author_id']来传递参数,这样参数会自动接入到自定义属性中。再比如,在分页场景中需要使用cat(藏品分类)参数,也可以通过infinite['cat']来传递参数。
7、监听器升级优化,当onPageBeforeInit监听进入页面后,如果页面包含元素【.page-content.' + page_name + '_content.infinite_loading】则会触发ajax分页加载的监听。这里有个重要调整,如果page_content.attr('page')元素返回的数字是0,则会主动执行一个动作【page_content.trigger('infinite');】。注:意思是,检查初始页码是否为0,如果是,则主动请求数据。并执行原有的填充机制。换句话就是页面可以选择不提前填充内容,通过内置方法来进行页面初始化填充。
8、如果首页的数据需要通过监听器自动填充,那么在执行触发动作时,应提前使用page_list.empty();方法清空列表容器的所有子元素和文本内容。这样可以避免在插入分页数据后,原有的初始化提示信息(例如:“暂没有相关鉴定订单”)仍然保留在页面中,从而确保页面显示的内容是最新的和相关的。
9、页面标准化处理:目前在【page-content】后面新增了一个通用类名:xc_app。通过使用page-content.xc_app的选择器,可以有效判断页面是否归属于宫论APP。这一元素选择器极其重要,未来所有的页面位置检测和判断将依赖于这个类名组合来实现。对于移动端的页面开发,未来都必须强制将这个类名写入其中,以确保一致性和功能的正确性。
10、除了页面需要通过监听器来执行下拉滚动组件的数据加载填充外,还需要对应的菜单切换事件来完成指定分类的下拉滚动事件的处理。考虑菜单切换的场景也很多,因此单独封装一个前端事件来xc_hook_subnavbar()动态处理数据类型切换。该方法将结合分页组件,实现页面菜单切换,组件也会自动进行参数切换。
11、在进行页面交互时,xc_hook_subnavbar钩子需要提供三个关键变量,以确保功能顺利实现。首先是sort,这个变量用于状态分类,在从A菜单切换到B菜单时,通过sort标识可以实现数据的动态填充和更新。其次是key,该变量主要用作场景标识,通常是页面的唯一标识符。通过key,系统能够识别当前的数据请求来源,从而准确提供相应的数据支持。最后是this,这是一个上下文对象。处理菜单内部事件时,使用this可以便捷地操作和管理当前对象的属性和方法,确保功能逻辑的连贯性和一致性。
12、xc_hook_subnavbar:在进行菜单数据填充之前,该钩子会执行一系列交互操作。首先,会创建一个作用域变量【page_content】,后续所有的页面交互都会使用这个变量作为选择器进行操作。接下来,系统会检查名为.page-content.' + key + '_content'的元素是否存在,如果不存在,则会立即返回一个错误信息【非法请求】。然后,通过animate函数将导航栏的滚动位置重置为顶部,这一操作在菜单切换时尤为必要,以便刷新页面数据。最后,使用obj为当前选中的菜单项添加选中样式,同时确保移除其他菜单项的选中样式。
0
小小乐
lv.2
实名用户
2024年10月20日
1、新增的模板组件脚本文件库【/global/publish/template.php】旨在简化组件的管理和使用。当项目中涉及到组件的调用时,只需通过require_once加载这个文件,即可实现自动加载所有的组件脚本库,例如:publish_report.php和publish_video.php等。未来扩展的新模板组件也将通过这个统一的脚本库集成进来,大大提升了系统的维护性和管理效率,使得组件调用变得更加方便快捷。
2、模板引擎解析脚本库新增了一个函数方法【xc_template_infinite_page_html】,用于处理分页下拉滚动加载的模板组件。这个方法需要传递两个变量。首先是分页的页面标识参数,这是一个唯一属性,对应后台配置的具体场景,用来防止监听器的错误重复注册。其次是html变量,即容器内的初始化展示内容。这可以是一段xc_empty的提示信息,也可以是已经封装好的li列表内容,具体的内容形式取决于前端的构造方式。
3、在使用模版引擎构造滚动下拉组件的过程中,首先会调用xc_is_config方法,检查验证配置xc_template_infinite_page中是否包含特定的页面标识场景的key。如果该key存在,那么将开始构建设计,并返回生成的HTML内容。这种直接返回HTML的做法是为了方便将内容输出到页面中。如果所需的key不存在,流程则会被跳过,函数会直接返回false,而不产生任何输出或数组结果。这种设计旨在提高页面渲染的效率和灵活性。
4、在修复页面返回功能时,我们发现了一个错误:页面返回时出现了“Uncaught ReferenceError: page_name is not defined”的报错。这种错误导致页面的后退动作异常,无响应的现象第一次发生后,用户很难再进行正常的页面返回尝试,第二次尝试返回时页面直接关闭,所有打开的页面都消失。经过深入分析,问题的根源是page_name这个变量被let声明,因此它的作用域受到限制,导致无法在全局范围内访问。为了彻底解决这个问题,已经将page_name变量移出局部作用域限制,并改为使用全局变量配置,使页面的后退行为恢复正常,避免了异常监听错误的出现。
5、通过模板引擎构造的下拉滚动器功能已经完成封装,这里提供的输出CSS类名结构如下。首先,我们有三个主要的全局class类名。第一个是template_infinite_page,这是父级类名,用作组件的标识。所有元素的操作都是通过这一父级类名来进行的。接下来是第二个类名:$config['key'],通常用作页面标识,根据具体页面场景的不同,可以设定不同的样式和行为。最后一个是自定义的$config['class'],这是由后台进行设定的,可以根据实际应用需求进行调整和适配,以确保组件在各个场景中的正确显示和功能性。
6、模版引擎的自定义属性和正文输出部分:自定义属性主要包括三个方面。首先是page属性,表示当前的页数,默认值设置为1。其次是number属性,指的是每页返回的数据量,这个数量通常由后台场景进行配置,默认值为20。最后是sort属性,这是一个分类状态标识,与页面的菜单切换功能相关,如果页面有切换菜单的功能,这个属性就必须被指定;但如果是单一页面的下拉滚动加载,这个属性可以为空。正文的输出部分通过<div class='list'>" . $html . "</div>来处理,其中$html是可变内容,如果它为空,则通过函数xc_empty($config['info'])生成适当的错误提示信息。这种设计确保了在不同条件下页面内容的动态调整和有效显示。
7、我的鉴定列表(identify_expert_order_list)现在已经升级,通过xc_local_link引用模板引擎库脚本。这种方式使得在页面中能够灵活调用xc_template_infinite_page_html(key,key,html = '')方法,来实现分页滚动加载组件的部署。当用户在页面上进行滚动操作时,系统会自动读取该组件的配置信息,然后通过请求服务端的分页接口,动态加载并填充相应内容到组件中。
8、为了提高滚动监听器的性能,我们对其结构进行了优化。之前的实现方式是利用page-content设置自定义属性,并通过内部统一监听器来读取这些属性信息。然而,这种方法需要将整个页面容器都纳入监听范围,这在处理页面自定义时显得不够灵活。因此,我们决定进行调整。现在,通过xc_template_infinite_page_html方法部署的滚动加载容器,不再依赖原有的page-content页面属性来完成配置读取。取而代之的是,通过其自带的属性来实现相应的处理,使得配置更加灵活,提升了页面的自定义友好性。
9、onPageBeforeInit页面访问监听器的机制进行了一次重要改进。之前通过使用page_name作为父级类名来进行处理(分页滚动加载)的旧方法,现在已经被淘汰。新的方法是通过检测页面中是否存在分页组件来进行选择器的判断【即:('.page-content.' + page.name + '_content .template_infinite_page')】。此外,页面自定义属性的获取方式也发生了变化,不再从page-content中直接提取,而是改为通过具体组件的自定义属性来获取。这种更新不仅提高了页面加载的灵活性,也增强了对复杂页面结构的支持能力。
10、在鉴定师订单列表页面(identify_expert_order_list)中,系统现在利用分页接口函数【xc_identify_expert_identify_order_list_consult】来获取首次加载时的首页数据。如果该请求成功且有订单记录返回,系统会创建一个名为list_consult_html的变量,随后,通过for循环将所有订单记录逐条转换为li元素并添加到list_consult_html中。完成数据的处理后,将赋值的list_consult_html变量传递给分页组件,实现页面的初步加载与展示。如果请求失败并且未返回任何订单记录,则list_consult_html会被标记为false,以反映数据加载的状态。
11、考虑到页面越来越多,组件扩展也越来越丰富。很多文档更新跟不上进度,页面交互动作写入出现重复问题。对于一些特定的页面结构设计,文档中单独列出一个示例文件夹。比如视频组件的调用方法,单独命名一个video.php,里面将会详细演示这个组件的调用使用方法。避免时间久了,忘记页面引入使用方法。造成阅读困难,甚至重写的问题。
12、在对监听器的自动分页递增动作进行优化时,原先的做法是通过读取content容器的page属性,将其值加1后重新写入,以确保页面标记始终处于有效状态。然而,在新版本的方法中,由于放弃了通过page-content作为父级类名的策略,原有方法失效。新的实现不仅更新和读取组件的页数,且引入了parseInt方法,将页数转换为整数后再进行累加,以防止可能出现的错误字符干扰,从而提升操作的准确性和稳定性。
0
小小乐
lv.2
实名用户
2024年10月18日
1、在实现标准的通用ajax分页加载填充事件时,需要为加载li内容处理指定一个容器类名。这一类名的固定标识为【page_list】,书写格式规定为(page.name + '_list'),其中前者为动态页面标识符,后者则表示为列表的含义。不同页面的容器可以有各自独特的风格设置,支持根据子类进行个性化设定。通过场景标识解析,可以灵活应用不同的CSS样式,确保页面显示效果与其特性需求一致。
2、在page_content中新增了一个名为type的第四个属性,这是一个服务端API接口标识参数。由于封装的需要,对分页接口请求进行type表示处理显得尤为重要。例如,当type被设定为review_identify_expert_api时,系统在执行ajax填充请求时将自动识别并响应此type,从而执行相应的业务逻辑处理。通过在不同的场景下设定不同的type值,能够有效地实现接口业务的分类和优化处理,提高系统的灵活性和响应效率。
3、在通过onPageBeforeInit监听器来触发分页内容的加载时,提交到服务端的请求参数采用对象数组结构进行处理。为防止内存溢出,初始化变量定义为【infinite:作用域变量】。目前,该请求参数具备三个固定的键值:首先是“type”,用于标识具体的场景;其次是“page”,代表页数,默认为1;最后是“sort”,则用于指定分页类型,例如可以传递参数来仅返回已退款的订单或仅返回已通过审核的鉴定师名单等。除了这三个基础值外,还可以根据具体应用场景,动态提取并附加相应的属性值,然后对其进行封装再提交请求。通过这样灵活的参数设计,确保系统在满足多样数据请求场景的同时,维持高效的内存使用。
4、宫论的统一分页接口请求(paging.php)现已增强功能,支持监听器的分页请求功能(标识为:infinite_paging_api)。当监听器成功完成对infinite数组的对象封装时,会在页面的list容器中通过after方法插入一个loading_post动画,然后触发ajax请求以访问分页接口,此时会携带infinite数组一起发送。分页接口在接收到API请求后,首先会对请求的合法性进行验证,若验证通过,则提取infinite数组参数,并进行相应的业务处理。
5、为了优化分页请求的返回数据量,针对不同的场景需求进行调整,某些场景可能需要返回更多的数据内容,而某些场景则需要较少的数据量。为确保这种多样化要求的兼容性,采用了监听器自动化部署滚动加载器的新技术。通过此自动化系统,允许在容器内部设定一个自定义属性:“number”。这个属性的默认值被设置为20。若需要调整返回内容的数量,可以根据具体需求对这个数字进行修改。此属性会被封装成infinite['number'],并通过分页接口传递,实现了灵活的内容加载和用户体验优化。
6、监听器在自动触发分页请求(infinite_paging_api)后,首先进行接口的安全验证。完成验证后,它会从请求的post对象中提取出infinite数组,并对该数组中的值进行基本处理。具体来说,首先处理的是infinite['page'],即请求分页的页码。如果该值为空或不存在,则默认重置为1。接下来是每页设定的内容数量,即number参数。如果number为空或不存在,则默认设定为20。最后,通过设定offset来计算偏移量,具体公式为(infinite[ ′ page ′ ],即请求分页的页码。如果该值为空或不存在,则默认重置为1。接下来是每页设定的内容数量,即number参数。如果number为空或不存在,则默认设定为20。最后,通过设定offset来计算偏移量,具体公式为(page - 1) * $number,从而获取到正确的页码内容。
7、为了实现前端页面的自动化滚动填充功能,通常需要设置多个复杂的容器参数。然而,为了简化这一过程并减少操作步骤,决定采用模块化设计处理方案。通过使用宫论内置的模板引擎,构建一个页面方法来完成容器组件的生成。这样的方法只需要传递一个场景名称,就能完成整个模块的生成。这不仅大大简化了部署工作,还使得后期的维护更加轻松,无需对每个页面进行单独维护,只需专注于模板方法的优化和调整即可。
8、在后台发布设置中,新增了一个名为【xc_template_infinite_paging_config】的配置组,专门用于模版引擎中的分页加载监听器配置。此配置器需要传递以下几个关键参数:首先是name参数,用于提供来源说明和详细文字介绍,以便用户理解该配置的作用。其次是key参数,这是一个为配置项提供唯一标识的标识符,设置后应保持不变,通常采用页面标识名称以确保唯一性。然后是class参数,负责定义样式,以便进行样式适配,确保页面呈现一致性。此外,number参数设定了每页加载的条目数量,默认为2,固定不变,便于保持统一的加载体验。最后是sort参数,其作为分页标识名称,主要用于指定需要状态的分页情况,若无特别需求则可以留空。
9、在xc_template_infinite_page的配置中,特别增加了两个新的字段,以提升其灵活性与用户体验:首先是“header_html”字段,它是一个大文本输入框,当你需要通过ajax加载一个自定义的HTML区域时,可以在此输入具体内容。这不仅支持HTML代码,还允许使用短代码,为用户在开发和设计上提供了更大的自由度。其次是“info”字段,用于显示提示内容。当系统需要告知用户某些信息,比如“没有更多鉴定订单”或“没有更多收藏记录”时,可以在这里自定义相应的提示或错误信息。这些字段都是作为扩展选项添加的,因此可以根据实际的使用场景选择是否进行配置,从而确保页面在加载和提示时的个性化需求都能得到满足。
10、新增第一个模版引擎[分页滚动加载]场景:【identify_expert_order_list:鉴定师的订单页面】。此场景的参数设定如下:自定义样式(identify_expert)被用于指定页面的样式布局,以确保页面显示符合预期。每页加载的订单条目数被设定为20,以便于用户在滚动时能够流畅查看订单详细信息。默认状态标识为0,这意味着在没有特别筛选条件的情况下,页面将返回所有订单,因为该页面支持菜单分页加载,因此默认设定为显示所有订单。加载更多内容时,若无更多订单需要显示,则页面将提示“没有更多鉴定记录”,以明确告知用户当前已浏览完所有可用记录。
11、新增的模板引擎配置文件【configure/template.php】中预设了图标为fa-opencart。在宫论项目中,模板引擎的概念已经被引入,并通过封装不同的组件实现了一键化的页面部署。然而,由于不同组件的配置选项各异,使得维护过程复杂且繁琐。为了解决这个问题,特别设定了一个独立的配置页面,用于存储和管理这些参数信息,从而简化维护流程,提高整体项目的可管理性。
12、以下配置字段已从其他地方迁移至【模版引擎配置页】:1. 模版引擎的[分页滚动加载]配置。2. 文本框表单配置字段:xc_publish_textarea_config。3. 图片上传组件配置:xc_publish_component_image。4. 表单内容填写组件配置:xc_publish_component_textarea。5. 视频上传组件配置:xc_publish_component_video。6. 藏品分类内容组件配置:xc_publish_component_category。7. 视频上传的相关配置:xc_upload_video_config。8. 图片上传的相关配置:xc_upload_image_config。这些字段都是为了优化模块的灵活性而封装的模版组件配置,通过将它们集中到一个配置页,可以更方便地进行管理和维护。此外,所有后续的模版组件也将整合封装到template.php文件中
0
小小乐
lv.2
实名用户
2024年10月17日
1、page-content(鉴定雷暴新增两个自定义属性)首先是page:该属性用于记录鉴定订单列表的页码,页面首次加载时默认设置为第一页。其次是sort:用于定义鉴定订单列表的排序类型。這兩個自訂屬性极其重要,無論是在页面的向下滚动加载过程中,還是在菜单切换时,皆潜在需要进行數值的更新與維護。需特别注意的是,在执行分页请求时,前端所传递的信息必须确保其有效性和可靠性,以便系统能够准确无误地响应用户的操作需求。
2、在执行分页菜单数据请求之前,xc_exoert_identify_list_order会进行一系列的页面交互处理。首先,它会将sort参数更新为事件传递过来的status,以确保接下来的AJAX请求可以稳定地获得预期的数据。接着,将page参数设置为1,这是因为菜单切换的操作本身意味着需要重置为第一页的内容。最后,它会在当前选中的菜单项上添加相应的选中样式,同时移除其他菜单项的选中样式。
3、当用户访问鉴定师大厅列表页面时,将会触发onPageBeforeInit监听器。该监听器负责实现一系列页面交互行为。例如,执行AJAX分页加载的初始化,以便动态获取和呈现更多内容,同时,监听滚动事件以确定是否需要进一步加载数据。此外,用户与鉴定订单的交互操作,如查看详情、提交反馈或申请修改等,也会通过此监听器进行处理。只要用户进入该页面,所有主动操作行为都将通过这个内置监听器进行管理
4、鉴定师订单列表页的监听器主要负责监控Ajax请求的滚动事件,以及处理分页数据的加载与填充。在用户进入此页面时,会初始化一个名为identify_expert_order_list_loading的全局变量(非作用域属性)。这个变量的变化用于判断页面是否继续监听无限滚动事件,并决定是否执行后续的数据填充操作。由于有两个不同的地方涉及到内容填充,因此需要依赖全局属性来验证当前状态,以确保填充过程正确,并且避免数据的重复加载或遗漏。
5、在订单列表页面中新增了一个容器,名称为.list.identify_expert_order_list_page_list,用于加载和填充相关的订单列表信息。页面初始化时,通过调用xc_identify_expert_identify_order_list_consult方法函数来获取订单数据。如果数据获取失败,则通过xc_empty显示提示信息【没有更多鉴定订单记录】。在初始化过程中,系统默认会传递参数status:0,以便获取所有相关的鉴定订单。
6、在宫论项目开发中,经常需要处理大量的分页滚动加载页面,这导致每次都要编写复杂冗长的监听处理代码。为了解决这个问题,尝试通过统一化封装的方式,简化并规范化这类操作。具体方法是将所有的类名处理通过新版page_name进行子类元素锁定。无论是点击事件还是滚动监听,所有元素的取值和选择都基于page_name作为父级类名来关联。比如,通过page_name + '_loading'可以作为全局状态参数变量,而使用$('.page-content.' + page_name + '_content')可以精确找到对应的容器位置。
7、全局分页加载统一事件适配处理:当用户所在页面需要支持分页加载功能时,应在page-content页面中添加一个通用类名【infinite_loading】。该值的存在标志着页面支持分页加载动作。接下来,将设置一个访问监听器,以检测当前打开的页面是否存在类名.page-content.infinite_loading。一旦检测到该标识,监听器便会自动启用并处理分页加载的相关逻辑,以确保用户体验的流畅性和功能的实用性。
8、要部署标准的分页加载事件,除了要给元素添加 infinite_loading 类名之外,还必须提前设置三个自定义属性。这三个属性是实现分页功能的关键,无论在何种场景下都不可或缺。此外,如果分页请求需要其他特定的参数,可以在之后新增自定义属性进行配置。这三个必备的属性包括:1. page_name:这是当前页面的唯一标识符,也可以用作全局父级类名。在处理分页请求时,通过这个全局父级类名来确保不同页面间的请求不发生冲突。2. sort:这是分页菜单的状态标识符。由于大多数分页场景中都涉及菜单切换功能,设置这个属性有助于对不同菜单状态进行识别和处理。3. page:表示当前的页数,初始化时将其设定为1。该属性用于跟踪和维护页面加载次数,确保分页顺序及内容加载的正确性。
9、在onPageBeforeInit阶段,增加一个全局监听事件。当访问的页面中包含具有类名【.page-content.' + page.name + '_content'.infinite_loading】的元素时,该事件会被触发。这一元素标志着当前页面需要实现通过AJAX进行分页的下拉滚动数据加载。其中,page.name是当前页面的标识名称,按照标准命名规范,即指代当前页面的容器区域部分。一旦检测到该页面元素的存在,监听事件将把元素的选择器赋值给let作用域变量:page_content。这一变量将在后续的页面交互中,用作父级类名的锁定。
10、onPageBeforeInit在初始化时,会从page对象中提取出page.name,并将其赋值给全局变量page_name,以便后续事件能够方便地进行调用。当成功监听到infinite_loading事件时,将会从页面中顺序提取出【page_name、page、sort】这三个自定义属性。随后,会初始化一个名为infinite的对象,将此对象设置为一个空数组,然后将提取到的三个属性值分别存储到该数组对象的对应键值中。这些值将用于后续的AJAX请求,直接将数组对象传递过去以便于请求的执行。
11、在动态生成变量名称时,通过直接使用page_name + '_loading'这种方式会导致返回Uncaught SyntaxError: Invalid left-hand side in assignment错误,因为它试图在赋值语句的左侧使用一个不合法的表达式。为了解决这个问题,目前的修正方法是借助对象来动态访问属性。首先创建一个超全局变量数组infinite_loading,通过使用infinite_loading[page.name]的方式来进行布尔值状态的管理和处理。这种方法不仅可以避免语法错误,还能更清晰地管理与不同页面状态相关的数据。
12、全局管理函数脚本库【global.js】已成功加载并初始化了infinite_loading对象数组。onPageBeforeInit监听器也已设置完毕,确保支持该数组对象。在分页加载请求被触发时,系统将通过infinite_loading[page_name]来动态更新其值为false或true,以此保证页面能够精准地执行AJAX分页请求并完成数据填充。此外,分页菜单的切换也需要兼容并适应这个对象数组,以确保功能的稳定性和一致性。
0
小小乐
lv.2
实名用户
2024年10月16日
1、在分页函数脚本库中新增了一个方法:xc_identify_expert_order_list_consult,用于处理鉴定师订单列表的分页请求。该方法需要传递以下固定参数:首先是user_id,即鉴定师的UID参数,用于指定需要查询的用户对象;其次是status,即状态标识,该参数的值对应于数据表中的状态字段。所有涉及到鉴定订单提取的请求都通过此方法进行处理。如果请求失败,该方法将返回`false
2、为了优化鉴定师订单分页接口方法,我们新增了两个变量参数:【offset:结果集的偏移量,默认为0,即从第一条记录开始;number:返回的记录数量,默认为10】。通过引入这两个参数,可以有效地实现返回结果的分页处理。在请求数据时,只需计算offset值,即可实现页数的计算,这样便能精确获取对应的结果集并返回。
3、现在分页函数将加载wpdb方法,通过SELECT查询【xc_identify】数据表,筛选出符合指定状态和鉴定师的所有记录。这个过程中,将使用prepare函数为查询语句指定参数类型,以确保执行安全性。如果查询结果中存在满足条件的记录,则返回相应的数组结果集;如果没有找到符合条件的记录,则返回false。
4、分页接口现在新增了一个名为【uncache】的第五个变量,用于控制缓存机制。默认情况下,该变量为false,表示启用缓存。如果未显式禁用缓存,系统将首先尝试读取缓存记录,缓存键为【'expert_identify_order:' . md5('consult' . user_id .user i d.status . offset . '-' .offset. ′ − ′ .number)】。仅在缓存记录不存在时,系统才会通过wpdb获取相应的数据记录,并同时更新缓存。请注意,缓存记录的有效期被设定为86400秒,即24小时,超过此时间缓存将自动刷新。
5、在将鉴定师订单缓存查询结果写入缓存时,如果查询结果为false(表示没有相关的鉴定订单记录),这种情况下也会触发update_redis_meta缓存更新操作。然而,由于Redis本身不支持存储布尔值,我们会将false以字符串形式"false"写入缓存。当前端从Redis中读取缓存时,如果结果存在,会进行额外的验证,检查返回结果是否为字符串"false"。如果匹配,则实际返回false。这样做确保了系统能够正确识别和处理缓存中代表无订单记录的特定标识符。
6、鉴定师订单查询接口已重新命名为:xc_identify_expert_identify_order_list_consult。此方法现在具备两个基础拦截规则:首先,如果用户未登录,则直接返回false;其次,如果用户不是管理员或鉴定师,也直接返回false。这些规则旨在防止数据的非法请求,确保只有管理员和鉴定师可以查看该分页数据接口的信息。
7、鉴于分页接口已经支持同步返回所有订单的请求,在使用鉴定师订单分页查询接口时,会针对status字段进行灵活性调度处理。目前,除了可以传递特定的数字状态外,该字段还新增了对【all】值的支持。当传递all时,表示此次请求不需要限定特定状态,系统将返回所有关联的订单。
8、鉴定师订单列表大厅页面(identify_expert_order_list)现已改进为通过分页接口函数来初始化鉴定订单记录。具体获取方式为:首先优先从鉴定师对象中读取author_id,若未指定author_id,则将使用当前的user_id。订单状态(status)被设定为ALL,以便获取所有状态的订单。偏移量(offset)设定为0,表示从初始位置开始读取。每次提取数量(number)设置为10,意味着每次返回前十条订单记录。获取到的结果集将会被存储在identify_list字段中。
9、前端新增了一个名为xc_exoert_identify_list_order的方法,用于管理鉴定师订单列表的菜单切换。此方法需要传递两个变量值:首先是status变量,它是一个状态切换字段,用于区分不同类型的鉴定记录。例如,你可以通过设置此字段来查看鉴定师待处理或已完成的鉴定订单记录。其次是thisL,它代表对象的上下文环境,确保方法在调用时的数据准确无误。通过这种参数传递方式,程序可以灵活地根据当前的this上下文读取和处理参数,实现菜单的动态切换和数据的即时更新。
10、无论是前端还是后端,当检索鉴定师的所有订单时,传递的状态参数一直是字符串“ALL”。这种做法缺乏灵活性,并且不符合通常用整型数字表示状态的惯例。因此,增加一个整型的状态值,以便在业务处理时能够更方便地进行参数校验。为了实现更好的统一管理,决定将该状态值变更为0。数值0代表获取所有鉴定记录,即不对状态进行匹配,进而提取与expert相关的所有订单记录。
11、在前端通过xc_exoert_identify_list_order方法读取鉴定类型菜单数据请求时,需要进行以下几项基本验证。首先,系统将通过user和xc两个属性对象来判断用户是否具备管理员权限和鉴定师资质。如果用户不同时具备这两项资格,系统将拦截该请求并进行相应处理。其次,系统会提取page-content.identify_expert_order_list_content元素,并生成一个名为content的作用域变量。在进行后续操作之前,系统将对该变量进行验证,如元素获取失败,则会将该请求视为非法请求。此外,系统还会通过xc.is_login方法验证用户的登录状态,如果用户未登录,系统将强制弹出登录页面以确保操作的安全性和连续性。
12、在鉴定师订单subnavbar菜单中,现新增了一个父级类:$page_name。这个全局唯一的类名主要用于解决多个页面同时存在subnavbar菜单时可能出现的监听异常问题,通过页面标识的方式来处理选择器,从而确保功能的正常运作。此外,subnavbar菜单中的li元素也增加了一个自定义属性【data】,此属性包含了status标识码。在后续的点击事件监听中,可以直接从li对象中提取出该标识码的值,以便于进一步的处理和操作。
1
小小乐
lv.2
实名用户
2024年10月15日
1、对xc_is_page_open结构方法进行了二次优化。该方法现在支持传递两个变量属性。首先是“name”,这是一个固定且必须的值,用于对每个页面进行唯一标识。其次是“page”,这是一个数组结构参数,为可选内容,默认情况下为空。具体传递的参数由每个页面自行决定。同时,该方法的返回结构体保持不变,依然是标准的数组结构。这种优化提高了方法的灵活性和适应性,更好地满足了不同页面的需求。
2、对xc_is_page_open函数的默认返回值进行了优化处理。在用户访问请求被拒绝或鉴权失败的情况下,除了返回code和msg两个变量参数外,还将额外返回以下内容:1、title:表示被拒绝页面的标题,以便用户明确了解到当前页面访问状态。2、content:描述被拒绝页面的主体内容区域,通常用于提供详细的拒绝原因或后续步骤的简要说明。3、link:指向强制跳转的页面地址,默认为403错误页面,但这个设置并不固定,可以灵活调整,比如将用户重定向至登录页面或注册页面,以促使用户进行认证或注册,从而获得访问权限。
3、对link执行的路径进行必要的调整和处理,目前的执行路径默认设为【403.php】。在路径加载时通过xc_require方法进行处理时,需要特别注意不要在自定义函数内部使用该方法,否则将可能导致异常错误的发生。如果需要跳转至其他页面,只需提供/acocoa/的真实路径。请注意,目前系统仅支持本地服务器路径的访问,对于以域名形式的页面路径访问机制尚不支持,且暂无计划进行支持。
4、xc_is_page_open功能现已支持对identify_expert_order_list页面的访问检测处理。当用户尝试访问鉴定师管理页面时,系统将依次执行以下两步检查:首先,检测用户角色以确定其是否为管理员或超级管理员角色。如果用户满足其中之一,则不会进行访问拦截,系统直接将open标记为true,允许访问。其次,即使用户不是管理员,系统还会调用xc_is_identify_expert方法进一步验证当前用户是否具有鉴定师身份。若验证通过,也将open标记为true,以确保鉴定师可以正常访问相关页面。
5、页面访问拦截器现在具有闭合操作功能,当完成用户的访问鉴权操作后。会在结尾部分对$result['open']进行验证处理。如果等于false,则将result中的code标记为1,msg返回错误【无权进行访问】、如果等于true则将code标记为0,msg返回【拥有访问权限】。然后直接继承result的结果【包括路径指向、标题、正文、等一系列的参数】。进行结果返回处理。
6、目前,xc_is_page_open 方法被临时整合到【ajax_page】页面中,这意味着每次用户访问该页面都会触发此函数的加载。将来,我们计划开发一个单独的脚本库专门用于处理请求验证,以提高整体代码的结构化和可维护性。目前,该方法新增了一个基础验证功能:在对传递的页面名称进行验证时,使用 is_string 和 empty 函数。如果传递的页面名称不存在或者为空,则立即返回错误提示。这种改进有效确保了输入数据的有效性和系统的稳定性。
7、对xc_is_page_open函数的跳转逻辑进行优化,先前版本的实现是通过返回一个标准的数组结构,并根据其中的code值判断用户的访问权限。在用户无权访问的情况下,需调用相应的页面跳转逻辑,以实现页面的强制接管。尽管该方法有效,但操作步骤稍显繁琐。因此,在优化后的方案中,增加了一个验证步骤,在保持原有业务逻辑的基础上,通过内部执行require_once $result['link']; exit();来实现,使得页面跳转和权限控制过程更加简洁流畅。这样一来,系统可以根据用户权限自动判断是拦截跳转还是直接放行,极大地提升了代码的可读性和维护性。
8、服务端的页面访问拦截器已经完成封装,部署方法非常简单。首先,使用require_once加载ajax_page.php,这是每个页面都需要加载的文件,不仅仅是在需要拦截访问事件时才加载。其次,如果页面需要拦截访问事件,只需调用xc_is_page_open($page_name)即可。如果需要传递外部变量,比如GET参数或令牌密钥,可以将这些变量作为数组传递到第二个参数位置。然后,在xc_is_page_open方法中执行相应的页面逻辑,对符合条件的访问进行放行,而对不符合条件的访问进行拦截。
9、考虑到管理员有时需要查看鉴定师的记录,需要提供便捷的访问方式。为此,在【identify_expert_order_list】页面新增一个GET参数(author_id)。当页面被访问时,系统会自动检测该GET参数的存在性。如果该参数存在并且当前用户是管理员,那么页面中的user_id将不再通过xc_is_login读取,而是直接采用GET参数中的值来进行赋值。验证方式的判断逻辑是(xc_is_admin_x() === true && isset($_GET['author_id'])),以确保只有管理员用户能够通过该方式访问鉴定师的订单列表页。这样设计旨在提升后台管理效率,使管理员能够更快速地获取和查看相关信息。
10、在移动APP端,新版页面的头部区域标准结构体已经完成封装,结构如下:1、首先,通过添加注释语句来标明页面名称、页面创建时间、最后更新时间及页面维护员的信息,这样设计是为了便于后续的维护和更新。2、使用require命令加载wp-load.php文件,将页面的核心组件全部集成,以确保功能的完整性和一致性。3、通过xc_is_login函数获取当前用户ID,并将其赋值给user_id变量,为后续的用户相关操作做好准备。4、构建page_name页面标识标量,页面的所有标识处理均通过此参数完成,以保持识别的统一。5、使用require_once加载集成的xc_local_link('ajax_page.php')文件,以实现全局统一的页面访问事件拦截,保障页面交互的可控性。6、根据实际需要加载【xc_is_page_open】访问拦截钩子,以稳定页面的访问逻辑。7、其他自定义区域则根据具体需求执行页面逻辑处理,确保结构的灵活性和扩展性。
11、在鉴定订单列表页面顶部新增了一个菜单选项,菜单内容包括五个鉴定订单状态分类:【所有鉴定订单:all、等待鉴定订单:wait、已完成鉴定订单:ok、已退回鉴定订单:refurn、已关闭鉴定订单:close】。鉴于鉴定订单仅有这五种状态,鉴定师可以通过页面顶部的菜单,方便地筛选和查看不同状态的订单。这样不仅提高了订单管理的效率,还为鉴定师提供了更直观的操作体验。
12、在使用xc_is_page_open方法验证【鉴定师的订单页面】时,该方法会检测页面请求中是否包含author_id参数。如果检测到author_id参数,则会生成第二个page数组,并将author_id作为该数组的元素传递给函数。函数内部负责进行验证操作。具体来说,如果page['author_id']存在,系统会进一步验证此ID对应的用户是否为鉴定师身份。如果此用户不是鉴定师,系统将拦截访问请求并返回相应的错误信息。需要注意的是,author_id的存在意味着管理员正在查看鉴定师的记录,此情况下不应验证user_id的访问权限,而应确认查看操作的用户是否具有鉴定师身份。这一流程确保了管理员可以正常查看鉴定师的记录,而不受一般用户访问限制的影响。
0
小小乐
lv.2
实名用户
2024年10月14日
1、新增了鉴定师订单页面【identify_expert_list】,其路径为:/module/xc_identify/expert_identify_list.php。通过短代码访问时,路径为:[xc_module type=xc_identify]/expert_identify_list.php。此页面用作鉴定师的订单列表,在此页面上,鉴定师可以查看其所有的鉴定记录,包括已完成和待处理的鉴定记录。页面名称为:“我的鉴定记录”。页面的设计旨在帮助鉴定师更高效地管理其工作进程和任务状态。
2、在identify_expert_list页面中,通过使用xc_local_link机制来实施页面访问的拦截策略。当用户的请求出现异常、环境存在异常或访问频率过高时,系统会自动阻断对该页面的访问。具体的阻断方式包括强制进行人机交互验证或直接进行页面拦截跳转,具体采用哪种方式视拦截处理策略而定。同时,后台系统已设置限制条件,目前该页面仅允许在线用户进行访问。
3、鉴定师订单列表页目前已成功集成了名为xc_order_access的访问拦截器功能,该功能的拦截标识为identify_expert_list。此功能的第二参数默认值为空。当用户尝试访问此页面时,系统首先检查用户的登录状态。若用户未登录,则会直接拦截并阻止其访问。若用户已登录,系统还会进一步核实其身份是否为鉴定师。如果用户并非鉴定师,将被拦截并强制跳转至403错误页面,提示无访问权限。总之,鉴定订单页面仅对具有鉴定师身份的用户开放访问权限。
4、为了实现统一化管理,xc_order_access函数进行了优化拆分。如今,这个函数不再整合集中到全局脚本函数文件中,以减少页面访问开支。相反,它通过ajax_page页面来动态加载。在ajax_page文件中,通过require_once方法引入access.php文件。在access文件中,首先利用function_exists进行检查,确保xc_order_access函数是否已经存在。如果该函数已经存在,则会跳过输出,避免重复执行的问题,提升系统的效率和稳定性。
5、为了进一步优化拦截器机制,页面在加载核心组件之后,将会初始化一个名为page_name的变量,其值对应页面的参数。这样做的主要目的是使ajax_page.php能够获取并继承这个页面属性,从而有效地处理页面的访问行为。同时,page_name现在也被用作页面的标识符,并动态写入到HTML元素的data-page属性中。
6、page页面现在新增了标识类名,便于管理和维护。在原有的特有类名“page”和“no-tabbar”基础上,增设一个动态类名:<?php echo $page_name; ?>。这使得前端在操作页面元素时,可以直接通过组合“page+页面标识”来精确锁定对应元素,而无需再依赖路由功能。需要注意的是,这个新增的页面类名需要在后续逐步适配到以前的所有页面上,以确保整个项目的一致性和可维护性。
7、ajax_page宫论页面访问拦截器,现在已支持【page_name】属性的处理。在进行页面访问时,拦截器会通过检查上级页面是否传递了page_name变量来判断是否进入特定的处理逻辑。如果page_name被有效传递,系统将执行相应的特定操作流程。需要注意的是,目前page_name属性仅在新增页面中才会出现,因此拦截器在大多数情况下仍然遵循现有的处理方法。
8、新增了一种全新的服务端方法:xc_is_page_open($key)。此方法作为xc_order_access的替代品,已被整合到ajax_page拦截器中。通过该方法,可以主动传递页面标识(在新版页面中,可以通过page_name继承获取)。此方法在内部负责验证并处理访问请求的合法性。如果请求不合法,则返回false;若请求合法,则返回true。此设计提升了系统对于页面访问权限的控制与安全性管理。
9、为了进一步优化xc_is_page_open功能,必须充分考虑到页面的复杂性,并设计更健全的错误监听机制,以便在检测到问题时,为用户提供明确的反馈信息。因此,仅仅返回布尔值(true或false)显然不能满足需求。这个方法的返回结构体需要进行调整,采用标准的数组结构将更为合适。新的结构中,code值为0时表示符合访问要求,而code值为1则表示不符合;另外,一个msg字段将用于提供错误的详细信息。
10、xc_is_page_open 方法所传递的参数不再固定为单一的 key 值,而是改为一个 page 数组变量。这一改变使得该方法可以根据不同页面的需求传递不同的数组结构参数,从而实现复杂的页面验证处理。在设置 page 数组变量时,需要依据页面访问机制的不同进行灵活配置。然而,无论任何页面,数组中都必须包含一个固定值:name,即原来的 key 标识,用于表示页面的唯一标识。这是拦截器的核心参数,绝对不可或缺。
11、新版访问拦截监听事件中新增了一个初始变量:open,默认值设置为false。这意味着在默认状态下,用户没有访问权限,系统需要进行拦截事件处理以确保安全性。为此,系统通过xc_is_page_open方法,根据不同的页面类型执行相应的验证逻辑。如果检测到用户符合访问条件,就会将open标记设置为true,从而允许用户正常访问页面。
12、在xc_is_page_open内部,除了初始化【open鉴权变量】参数外,该函数还会预设两个变量的值:【title:访问被拒绝】和【content:你无权访问页面】。如果鉴权过程失败,这两个参数将被用于显示默认信息。当然,开发者也可以选择在代码中针对特定需求动态修改这两个参数的值,以影响跳转页面的标题和正文,否则系统会自动采用这些预设内容进行页面展示。
1
小小乐
lv.2
实名用户
2024年10月13日
1、鉴定订单回调事件处理:在支付成功并顺利通过基础检测拦截后,系统会自动触发支付回调事件,并执行xc_insert_sql操作,将相关数据写入数据库表中。此过程中,将【user_id:代表鉴定人或付款人、expert:代表卖家或鉴定师、cat:指代藏品的分类标识、time:表示操作发生的时间点、onumber:用于标识的随机唯一编号、type:指明鉴定的场景标识】作为关联参数,生成一条新的记录并写入到xc_identify数据表,以正式完成新的鉴定订单的创建流程
2、写入订单鉴定的时间会处理open字段,该字段的默认值设置为1(公开)。如果订单不公开,则状态标识会更新为2。同时,订单状态status的初始值设置为1(待鉴定),这一调整是为了规范化流程,之前的初始状态为0,显得较为混乱。为确保信息一致性和便于后续处理,这两个字段的修改与更新已整合同步至开发文档中。每次状态的变更都会在开放文档中更新,以便于跟踪审核。
3、在藏品鉴定表中,现已彻底移除order订单字段,不再进行保留处理。鉴定订单现在有两种追踪和锁定的方式。第一种是通过id,也就是数据表的主键ID值。这个值具有唯一性,是主要的单据跟踪方法。第二种方式是通过number字段,即订单编号信息。这一编号是通过uniqid函数生成的随机数,用户在界面上看到的鉴定编号正是这一值。
4、在对藏品信息进行独立封装处理时,首先会初始化一个名为collection的空数组。在插入鉴定订单表之前,该过程开始时会使用empty函数逐一检查是否存在【image、video、textarea】等信息。如果这些信息存在,则将其分别写入到collection数组的相应字段中。完成这一系列的数组封装操作后,在执行xc_insert_sql时,这个封装好的数组将会被存入到数据库中相应的字段中,以确保数据的完整性和结构化存储。
5、在通过 xc_insert_sql 插入鉴定订单后,返回的结果会被赋值给 insert_result。接下来,我们会对这个值进行验证处理。如果返回的值为空,则立即返回错误,并将错误信息写入日志中,以便后续追踪和处理。同时,拒绝后续的执行,以防止异常错误的传播。需要注意的是,在正常情况下,insert_result 会获得一个ID,即插入的主键值。
6、一旦成功获取鉴定订单的插入主键值后,系统会立即触发xc_pay支付订单的回调处理。在此过程中,需要将支付订单表中【shop_order】字段的值更新为获取到的鉴定订单主键ID。同时,将支付订单的场景来源字段【shop_type】设置为“identify”。通过这样的操作,确保支付订单与鉴定订单之间的关联关系得以正确建立。
7、当付款完成后,在触发支付回调业务时,如果涉及鉴定藏品的订单,系统会在插入鉴定订单的过程中捕获本次支付订单的ID主键值,并将其写入到payment字段(支付订单记录)。随后,系统执行插入创建操作,通过这个字段,鉴定表能够反向追踪到对应的付款详情记录,从而实现订单与付款信息的有效关联。
8、缓存清理操作:在成功完成鉴定订单表的写入工作,即【insert_result】有记录返回时,为了避免可能的冲突错误,将主动清理与用户相关的缓存记录【publish_identify:' . md5($user_id)】。这样可以有效预防由于缓存存在而导致的重复付款记录或重复草稿导入的问题。通过这一机制,确保系统运行的稳定性和数据的准确性。
9、新增短信模板ID【1302223:新的藏品鉴定请求】,模板内容为:“{1}您好,您有一条新的鉴定请求等待处理,请及时前往APP处理!”该模板的应用场景是:当用户指定鉴定师进行鉴定并完成付款后,系统会自动向对应的鉴定师发送一条短信提醒,以便对方能够及时处理请求。请注意,该通知通过场景模板触发,且每日发送次数有限制。
10、在后台配置PUSH通知的场景时,将【identify_apply】通知栏目设定为:鉴定订单通知。同时,新增一个公众号模板消息的功能,具体的模板编号设定为:订单处理通知(模板编号:YRpZrq__R2hb0i1vBoJr1n0snvWcyXoLWpkWJBiXtQA)。当用户提交鉴定申请后,如果鉴定师已绑定微信并关注了相关公众号,他们将会收到一条模板消息提醒。需要特别注意的是,该消息通知的发送次数没有上限。
11、藏品鉴定通知系统(identify_apply)现已全面升级,支持通过APP消息、服务号以及站内信三种方式进行通知,进一步提升用户体验。用户在成功支付鉴定藏品订单后,将接收到由"identify鉴定助理"发出的通知。此通知将通过统一的通知接口发送至用户手机,其中在线用户将直接接收来自APP或网页的弹窗消息,这些消息是通过websocket实现的。如果用户处于离线状态,则会通过厂商的离线接口发送APP通知,确保信息的及时传达。同时,所有消息也会在服务号列表中展示,以便用户随时查阅。
12、identify_apply消息通知场景设定了通知上限。短信通知每天最多发送五条,超过五条的提醒将不会再发送,以防止短信包消耗过大。公众号模版消息每日上限为20条,超过此数量的模版消息将不会发送,以防止滥用模版导致举报。邮件通知每天仅发送前十条通知,超过的部分将不再发送。以上参数可以根据具体需求进行自定义调整。
0
小小乐
lv.2
实名用户
2024年10月11日
1、用户在通过正常渠道发起藏品鉴定时,如果他们主动选择了鉴定师并提交了鉴定请求,该请求的场景标识应被设定为【default:默认请求】。然而,若此请求涉及关联性鉴定,则场景标识需要根据具体情况变更为相应标识,比如tao、bzg等。这样通过不同的场景标识,鉴定请求得以有效进行归档和分类,便于日后的管理和检索。
2、关于status状态标识的处理规划,当用户发起藏品鉴定申请时,订单状态将依据status字段来进行标记。具体状态包括以下几种:【1:待鉴定,表示订单已提交并等待鉴定师进行鉴定;2:超时关闭,指由于用户或系统原因,鉴定流程未能在规定时间内完成,因此订单自动关闭;3:已退回,表示订单被退回到用户处,可能是由于信息不全或其他问题;4:已关闭,表示订单已被管理员或系统操作关闭,无需进一步处理;5:已撤回,指用户主动撤销了鉴定申请,不再进行后续流程;6:已完成,说明鉴定过程已顺利完成并送达结果。请注意,藏品鉴定表只有在完成订单支付后才会生成相关记录,因此不需考虑监听待支付状态的业务流程。
3、在藏品鉴定发布页面【publish_identify】中,新增一个自定义属性type,其默认值为default。该属性用于标识当前的藏品鉴定场景。当用户点击xc_hook_identify_next进行操作时,系统将在现有基础属性的基础上,提取页面的type属性,并将其写入到相应的数组中,随后提交到后端进行处理。
4、服务端在执行xc_identify_next_hook钩子时,现在增加了对type新增属性的识别和处理。在处理完成后,该属性将被写入到token令牌中,以确保后续的业务流程可以捕获并利用这一新的场景标识字段进行进一步的操作。
5、草稿恢复功能中的publish_identify_draft_hook现在已经集成了对type自定义属性的处理。在草稿恢复的过程中,系统会检查令牌中是否包含type属性,如果存在,此属性将被封装到html['type']中,然后返回到前端页面。前端页面在接收到此数据后,会检测是否包含该值,如果包含,则会将页面上的对应参数值进行替换。
6、xc_payment_success_hook支付成功回调钩子用于处理藏品鉴定成功后的业务逻辑。当用户创建藏品鉴定请求并成功完成支付后,系统会进入宫论的统一支付业务逻辑处理模块。此时,支付的标识为固定值“identify”。在支付订单业务完成封装后,系统会通过回调钩子执行相应的业务交互动作,例如通知鉴定师、创建鉴定记录表等。这一过程确保了支付成功后,相关的后续业务能够顺利进行。
7、我们修复了支付过程中藏品鉴定订单的一个严重漏洞,鉴定订单本质上是C2C关系。具体来说,这种关系涉及鉴定师和用户之间的交易。用户发起鉴定请求,并选择一位鉴定师(即卖家),接着支付相关费用。鉴定师在收到鉴定请求后,完成鉴定工作,并最终获取鉴定费。在整个业务流程中,平台则主要负责资金的担保和提供交易技术支持。因此,在构建支付订单时,必须将订单的卖家信息纳入其中,以确保C2C关系的正确绑定。这样一来,平台在进行费用结算时,能够准确地处理和分配交易费用。
8、修复并解决进行草稿恢复的时候,返回错误【Undefined array key "type" in】的问题,该错误是因为草稿恢复过程中新增的【type:鉴定场景】捕获失败,导致的错误。具体原因为token令牌中没有提取到这个属性导致的,目前已排查并解决该问题,现在生成token数组缓存的时候,会正确获取并写入type值。
9、在通过调用add_payment_order_hook构建藏品待支付订单的过程中,系统首先提取identify_token令牌,以便获取鉴定师的详细资料。接着,将鉴定师的UID写入到订单的【seller】字段中。这一步骤确保了在创建待付款订单时,明确地建立起卖家关系,从而实现了鉴定师与用户之间的C2C绑定。这一机制有效地赋予了交易双方明确的角色,使得整个交易流程更加清晰和顺畅。
10、在鉴定支付回调钩子事件中,系统首先通过提权操作访问支付订单表中的【meta】字段。接着,利用 json_decode 函数将该字段内容转换为数组格式。然后,系统使用 get_redis_meta 函数获取 identify_token 令牌,并由此提取出相关参数信息。这些信息包括:$identify['cat'],表示藏品的分类;$identify['type'],表示鉴定的场景;$identify['image'],即藏品的图片列表;$identify['video'],这是一个可选参数,代表藏品的视频地址;$identify['textarea'],用于补充鉴赏描述的信息;以及$identify['user_id'],标识鉴定发起人。通过这些详细的信息提取和处理,系统能够有效管理和追踪每个鉴定支付订单的细节。
11、鉴定支付订单回调处理:在成功从meta获取到token令牌后,系统会对其进行解析,并提取出user_id,即鉴定人身份。接着,将该user_id与当前支付订单的实际付款人进行比对。如果两者不一致,则表明这是一次非法请求。此时,系统会记录错误日志,并拒绝生成鉴定订单。
12、支付订单回调处理:在创建鉴定订单记录前,需要进行最后一次参数核实,以确保所有信息准确无误。首先,检查鉴定师(卖家)的状态是否为可接单状态,如果发现异常,例如状态为暂停或关闭,则立即记录错误信息,并拒绝执行后续操作。其次,核对当前申请的藏品分类是否与鉴定师的专业类目相符,此外,还要确认申请鉴定的藏品分类目前是否开放鉴定服务,最后,审核鉴定收费标准与当前支付订单金额是否匹配,确保支付金额准确无误
0
小小乐
lv.2
实名用户
2024年10月10日
1、对于xc_identif数据表的优化重构规划,这是一个专注于藏品鉴定记录的关键表,因此在系统投入运营后,预计会有大量的数据写入需求。首先,功能上需要进行重构设计,以确保系统的灵活性和可维护性。在性能优化方面,重点在于索引设计的完善,以提高查询效率。此外,结合Redis进行缓存部署减轻数据库的负载压力。通过合理的缓存策略,能够显著提升数据读取的响应速度,即使在处理千万级别的数据时,也能确保系统响应迅速,不会出现延迟情况。
2、重构数据表的第一步是对现有的数据表进行备份操作,将整个数据表完整地复制到xc_identif_bat中。这个备份包括了表的结构以及表中所有的数据内容。由于许多业务与鉴定表记录密切相关,在重构过程中,为了处理和兼容大量业务关联问题,备份显得尤为重要。这一措施可以有效防范在重构过程中可能出现的意外情况。如果业务需要进行调整,借助此备份可以快速切换,从而确保系统的稳定性和连续性。
3、在鉴定表中,需要移除以下字段:【text:藏品文字、img:藏品图片、video:藏品视频】。同时,新增一个名为collection的字段,该字段使用VARCHAR类型,最大长度限制为10000字符。用户在提交藏品鉴定时,藏品的相关信息将以JSON格式存储在这个字段中。当需要读取时,再将数据转换为数组并解析处理。由于藏品的基础信息无需单独字段进行索引,因此通过JSON格式存储能够有效提升数据源表的性能。
4、在鉴定记录表中,我们将移除以下字段:【money:鉴定费用、pay_select:付款方式、pay_order:支付单号】。新增一个字段:payment(VARCHAR 64位),用于存储支付订单的单号。支付方式、支付费用等信息,可以通过支付订单号与相关支付表进行关联查询来获取,无需在鉴定记录表中单列这些字段。此前与鉴定师收益相关的统计工作,也可以直接通过支付表进行查询,以确保数据管理的简洁与高效。
5、以下字段将被保留,但需要对字段类型进行调整,以确保索引的支持:1、cat(藏品分类):原来使用中文分类名存储,现在修改为使用key标识,例如“ciqi”代表瓷器。字段类型调整为VARCHAR(20)。2、era(藏品年代):用于鉴定师对藏品年代进行判断,该字段保留的目的是为了实现年代索引查询,字段类型调整为VARCHAR(32)。3、grade(藏品等级):鉴定师对藏品进行等级划分,保留该字段是为了便于分类筛选,因此字段类型调整为VARCHAR(32)。4、value(价格趋势):字段名修改为price,用于描述鉴定师对藏品价格区位的划分。由于该字段后期也需要进行分类筛查,因此单独列出,字段类型调整为VARCHAR(32)。
6、在订单系统中,“鉴品编号”字段的字段类型将调整为VARCHAR(64),不过该字段将被弃用,仅作为与旧系统兼容的保留项。在设计和开发鉴定功能时,不再使用该字段进行任何数据处理。“查询编号”字段将调整为VARCHAR(32),并将取代“订单号”,成为鉴定藏品的唯一对外标识码。在缓存读取等操作场景中,应尽可能通过ID主键来进行,以确保数据处理的效率和一致性。
7、移除字段【opinion:专家回复】。原字段用于存储鉴定师对藏品的点评,但由于鉴定回复的形式可能多样化,例如既有语音回复又有文字回复,同时除了鉴定藏品外,还有可能涉及其它内容字段的补充,因此需要进行调整。采用JSON格式来存储藏品的鉴定回复信息,新增字段identify(设定为text类型,支持长文本),专门用于保存专家对藏品的详细鉴赏信息,以确保系统能够更灵活地处理不同类型的回复内容。
8、title:藏品的标题保持不变,但其字段类型需要从原来的text文本调整为VARCHAR(200)。这个标题将由专业鉴定师撰写,并在鉴定完成后用作藏品的唯一名称。state:此字段名称需更改为status,并不再使用旧版的存储机制,而是调整为int(11)类型。通过不同的数字编号来区分藏品的状态,例如:0表示待鉴定,1表示已退回,2表示已超时等。这样设置不仅优化了数据库的存储性能,还使状态管理更加直观和高效。
9、移除end_time字段是因为在当前系统中,当鉴定师完成鉴定工作后,这个字段会被填写和记录。然而,在实际应用中,我们需要记录多种时间信息,例如鉴定提交时间、退回时间、超时关闭时间以及鉴定完成时间等。单靠一个单独的字段难以满足所有时间记录的需求。此外,还有许多场景的字段信息需要被写入。为了提高数据表的结构灵活性,我们决定新增一个meta(自定义元字段)作为扩展。通过使用JSON的存储方式,这个meta字段将能够灵活地存储多种时间信息和其他相关内容。这种方法不仅可以实现多样化的信息存储,还能使数据库结构在面对未来可能的需求变化时更加灵活和适应。
10、在鉴定师数据表中新增两个组合索引,以提高查询效率。首先是基础信息查询索引(user_id、expert、cat、number),这是因为通过鉴定用户、鉴定专家、藏品分类和鉴定编号进行查找是一个非常频繁的操作,因此加入该索引可以显著提升这些字段的查找响应速度。其次是藏品类型筛选组合索引(cat:藏品分类、era:藏品断代、price:价格趋势、grade:藏品级别),这四个字段常用于类目筛选,所以提前建立索引能够有效加快筛选的处理速度,优化数据表性能。
11、在xc_identify数据表中新增了一个字段:open,该字段用于控制鉴定订单的状态开关。用户可以选择是否将已完成鉴定的藏品订单设为公开状态。如果用户选择关闭该字段,其值为1;若选择开启,则为0。在关闭状态下,鉴定藏品将无法被索引和查找,可以理解为藏品仅用户本人可见。即使他人输入鉴定编号,也无法查阅相关信息。该字段是一个全局开关。需要注意的是,默认情况下,鉴定订单处于公开状态,用户需手动将其设置为关闭。
12、为适应不同鉴定请求方式的多样性,xc_identify新增了一个【type:VARCHAR(20)】的场景字段,以便更好地区别和处理不同的鉴定请求类型,从而在后期实现更高效的归档处理。例如,普通鉴定通常是通过藏品鉴定入口发起的,但用户也可以直接在鉴定师主页上发起鉴定。此外,还计划允许通过淘货功能一键发起真假鉴定。而对于某些不宜公开的鉴定场景,则可以通过该字段实现更加精确的筛选和管理。
0
小小乐
lv.2
实名用户
2024年10月09日
1、服务端的统一支付钩子:xc_payment_hook,目前已经成功集成了【identify:藏品鉴定】的相关业务流程。当用户进行藏品鉴定时,这个钩子将被调用以发起鉴定费的支付请求。钩子会首先核查用户的环境以及提交的相关参数,确保所有条件都满足后,才会发起支付请求。同时,它会生成一个支付令牌以处理后续的支付事务,确保整个交易过程的安全性和顺利进行。
2、在add_payment_order_hook钩子中增设一个拦截保护机制,用于处理支付订单的来源为鉴定的情况。在这一流程中,将执行以下关键检测:首先,需要验证identify_token令牌的有效性。如果令牌无效,则系统将返回错误提示【订单创建失败:鉴定令牌已过期】。其次,系统将使用xc_is_identify_expert方法判断所选择的鉴定师是否合格,如鉴定师不符要求,则返回提示【订单创建失败:鉴定师不可用】。最后,还需核实订单金额,即鉴赏费用是否与所选鉴定师的收费标准一致。如费用不一致,系统将给出提示【订单创建失败:鉴定费用不一致】。通过以上步骤,确保支付订单的可靠性和准确性。
3、为了确保后续的回调动作能够顺利获取到鉴定藏品所需的提交信息(服务端需要进行支付回调),在使用add_payment_order_hook方法生成订单数据表记录时,会将服务端传递的【identify_token、author_id、amount】这三个参数一并存入meta字段中。后续的业务操作需要使用这些鉴定信息时,只需解析meta字段即可完成提取。这种做法不仅整合了数据存储,还简化了数据获取流程,确保了业务的连续性和数据的完整性。
4、为了优化用户体验,在成功创建待支付的【藏品鉴定】订单后,系统设计了一种令牌延迟机制。此机制的核心目的是防止原有鉴定信息的缓存因为超时而被清理掉。从而在订单生成后,会立即重置令牌的有效期,将其设置为30分钟才会过期。这项措施确保了即便用户延迟付款,也不必担心后续回调失效所带来的麻烦。然而需要注意的是,在极端情况下,可能会因为令牌过期问题,导致订单虽已付款成功但无法创建和生成相应的鉴定订单。
5、修复并解决提交鉴定师申请时,服务端返回如下错误【 Undefined array key "identify_token" in、Undefined array key "author_id" in、 Undefined array key "amount" in】错误的问题。该错误是由于读取变量错误导致的,主要原因是前端传递的是payment对象属性,钩子内部读取需要进行二次解析处理。
6、修复并解决服务端错误返回【 Call to undefined function update_get_redis() 】的问题,在执行缓存动作更新的时候,返回undefined函数不存在的问题。该错误指向函数add_payment_order_hook,在创建生成支付订单的时候,需要更新redis缓存,但是执行方法错误导致出现错误,目前已进行修复处理。
7、支付鉴定订单时,扣款成功后仍旧返回【Undefined variable $shop_order in <b>/ Undefined variable $resul in】这两个异常直接导致页面无法完成回调功能。第一个错误的原因在于:当用户使用余额支付时,系统会触发推送消息通知,构建一个链接以便用户跳转,其中需要包含订单号作为参数。然而,由于之前未正确提取订单号,因而导致此错误出现。第二个错误则涉及余额更新的钩子函数,在这个过程中返回值应该是“result”,但由于变量未定义,所以导致了错误返回。
8、解决在统一支付架构下进行余额支付时始终返回固定错误码【code=1】的问题,该错误是由于xc_update_money_hook的余额更新动作钩子未能正确闭合,进一步分析发现,具体原因在于返回结构体未采用标准化数组格式,导致在消息传递时无法被后续业务正确识别。为此,解决方案:对余额更新钩子的返回方式进行重构,确保返回的数据包符合标准的数组格式。
9、在余额支付过程中,当回调事件被触发时,会返回一个异常错误【require_once(): https:// wrapper is disabled】。这个问题的根本原因是配置中不允许通过 URL 来包含文件 (allow_url_include=0)。也就是说,require_once 引入的路径存在安全隐患,因为使用的是通过短代码生成的网络地址,而并非本地路径。由于系统的安全策略,该操作会被拦截,从而导致支付成功后的回调无法被正常执行。为了解决这一问题,建议调整代码逻辑,确保所有文件引入使用本地路径,避免使用 URL 形式的路径,以提升系统的安全性和稳定性。
10、余额服务号的消息通知得到了优化,之前服务号的站内信消息仅以简单的形式显示【余额支出:30元、余额收入:100元】,无法直接看到余额变动的具体原因,用户必须点击进入聊天对话框才能查看细节。经过调整后,消息的展示方式得到了改进,信息末尾新增了余额变动的原因说明,这样用户即使不进入会话页面,也能够直接看到最近的余额变动原因,从而方便了解每笔支出或收入的详细背景。
11、宫论服务号的消息助理新增了【藏品鉴定助理:identify】这一功能,关联的用户UID为35。服务号的主要职责是发送与藏品鉴定相关的消息通知。目前,该服务号在站内开启了弹窗通知功能,但私信功能暂时关闭。服务号的主要任务包括两个方面:首先,对于鉴定师来说,当收到藏品鉴定请求时,该服务号将会发送相应的消息通知,以便及时处理鉴定工作;其次,对于用户来说,当他们的藏品完成鉴定后,服务号将发送结果通知,让用户了解到鉴定的最新进展与结果。
12、在全局推送通知管理配置组中,新增了一个名为“identify_apply【鉴定师】收到藏品鉴定通知”的场景。当用户发起藏品鉴定请求,并指定了具体的鉴定师且完成付款程序后,鉴定师将受到一系列通知,提醒他们及时处理这些鉴定请求。该消息场景将同时激活以下多种通知方式:短信提醒、邮件提醒、站内信提醒、服务号通知、公众号通知及应用内消息通知。通过这一多渠道通知机制,确保鉴定师能够在第一时间收到信息并作出响应。
0
小小乐
lv.2
实名用户
2024年10月08日
1、在xc_identify_next页面中,现在已经支持通过myApp.onPageBeforeInit访问事件进行处理。用户每次访问该页面时,都会自动触发内部的事件监听器。当用户点击【xc_identify_next_content li】元素时,系统将自动移除其他所有li元素上的on类,同时为当前被点击的li元素添加on类。
2、当用户选择鉴定师时,不再使用绑定onclick事件的方式来触发底部菜单中鉴赏费用的相关处理,而是改为通过监听li元素的点击行为进行触发。当用户点击鉴定师时,除了在元素上新增on类名,还需要从当前元素的this中提取price价格信息,然后将该价格通过具有lock_money_expert类名的元素输出到指定页面区域。请注意,类名的操作将通过使用$(this)进行处理,以确保DOM操作的正确性与灵活性。
3、鉴定师在进行CSS样式优化时,应注意以下几点:首先,将“on”状态下的背景色由浅灰色更改为白色,此举可以有效避免因背景色覆盖而导致的显示差异问题,使界面更为清晰。其次,在原有样式的基础上,增加外部边框效果,能够明显地凸显选中项,从而提升用户的视觉体验。最后,对于鉴赏费用部分的底部菜单进行精细调整,将margin-bottom设定为-2vw,确保空间布局合理,同时将字体大小设置为4.5vw,以确保文字的清晰易读和整体的视觉和谐美观。
4、在鉴定师选择页面上新增一个名为【提交鉴定申请】的按钮选项。当用户选择了一位鉴定师后,可以通过点击此按钮提交鉴定申请。如果用户未选择鉴定师,系统会提醒并返回错误信息【请先选择一位鉴定师】。用户点击按钮后,系统将从页面中获取所选鉴定师的UID,并与token一起封装。这些信息中,token包含了用户提交的鉴定资料,所有数据将被准备好、待提交至服务端进行参数核验。
5、后台支付场景新增了关于【藏品鉴定费用:identify】的配置。支付场景被简化为“鉴定”,支持的付款方式包括支付宝、微信和余额支付。必须登录后才能使用该服务,因为鉴定必须由用户主动发起,游客无法使用。由于鉴定本质上是一个虚拟订单,因此不需要开启收货地址功能,也不涉及物流环节。而订单备注功能则未开启,鉴赏描述即作为备注信息。若订单在30分钟内未完成支付,将被自动关闭。此外,平台会根据统一标准扣除20%的手续费。目前,场景描述备注暂时为空,不作特别说明。
6、前端支付事件:在支付过程中,事件xc_hook_payment_order已经整合了对【identify:藏品鉴定】功能的支持。当用户试图进行支付时,将触发如下基本拦截流程。首先,系统会利用封装的作用域变量选择器【page-content.xc_identify_next_content】来确认页面内对应元素的存在。如果无法成功锁定该元素,则会直接返回提示,指出这是一次非法的请求。其次,系统将核实用户是否已经在页面中选择了鉴定师。如果用户尚未完成选择,则会弹出提示信息【失败:请选择一个鉴定师】。这一系列的步骤旨在确保支付程序的合法和顺利进行。
7、在选择鉴定师页面中新增了三个自定义属性,以便更好地管理和展示鉴定师相关信息。首先,'token'属性用于接收和存储从上级页面传递过来的鉴定师资料令牌,其中包含了有关鉴定申请的详细材料信息,包括文本和图片内容。其次,'author_id'用于标识鉴定师的唯一用户标识符(UID),确保在鉴定流程中准确识别和关联特定鉴定师。最后,'price'属性代表鉴定师的收费标准,即本次鉴定服务的费用金额。这些自定义属性通过鉴定师监听的点击事件主动获取,通过将鉴定师的UID和价格信息传递到相应的属性中,实现信息的自动更新和准确显示。
8、订单生成钩子:xc_hook_payment_order,在处理藏品鉴定支付订单时,系统通过payment对象提取页面的以下三个关键属性:【identify_token:鉴定资料的令牌、author_id:选定的鉴定师、amount:此次支付的金额】。如果任何一个属性缺失,系统将立即返回提示“参数不完整”。一旦所有参数完整,系统将继续进行服务端的业务处理。
9、修复并解决在发起藏品鉴定订单时出现的【支付参数不完整的问题】。这一问题源于amount价格单位获取异常,需要进行排查和调整。此外,将author_id(鉴定师)的名称变更为seller(收款方,包括卖家、鉴定师、商户或转账收款人),这样有助于更加清晰地识别交易参与方。通过这一命名调整,相关参数可以直接写入支付订单数据库,无需再进行二次解析处理,提高了系统的效率和稳定性。
10、在li鉴定师列表容器中,新增一个自定义属性:name,用于存储鉴定师的姓名或昵称。同时,在xc_identify_next_content中也增加一个自定义属性:title。当用户选择鉴定师时,这一属性将接收到鉴定师的昵称和对应的栏目。具体的展示格式为示例中的【(瓷器鉴定) - 小小乐】。注意,这个标题的生成会通过xc_is_config方法获取藏品的分类名称,并结合所选鉴定师的昵称进行构建。
11、目前,藏品鉴定订单生成事件通过使用作用域变量page_content来提取标题的自定义属性,其中包含鉴定师姓名和鉴定栏目名称。这些信息将作为此次藏品鉴定的支付订单商品标题,并一并录入到订单表中。如此一来,当用户打开支付订单页面时,他们能够清晰直观地看到与支付相关的商品标题,从而提高用户体验和识别度。
12、统一支付页面进行细节优化:1、如果支付备注功能未开启,则页面中将不显示付款说明专栏,从而简化用户界面。2、移除title字段内容。之前默认显示商品标题的title字段已经在商品栏中得到展示,因此显得多余,建议将其去除以避免重复。3、付款截止时间现在将增加div容器边框,这一设计不仅优化了视觉效果,也让用户更清晰地看到关键时间信息。
0
小小乐
lv.2
实名用户
2024年10月07日
1、xc_identify_next页面现已在后台设置为仅限用户登录状态访问。未登录用户在尝试访问时,前端会自动重定向至登录页面。此外,该页面通过require_once加载了【xc_local_link('ajax_page.php')】,以确保非法请求和高频率访问行为被有效拦截。值得注意的是,该页面集成了阿里云的验证机制,用于验证人机交互的真实性。
2、在处理【xc_identify_next】页面请求时,xc_order_access会主动传递token令牌。拦截钩子负责验证该令牌的合法性,如果令牌不存在或已过期,将会被拦截。此外,系统还会对token返回的内容进行核验,如果token的创建者与当前用户不一致,则视为非法请求。这一机制不仅防止了token令牌的泄露,还能有效阻止未经授权的直接请求。
3、xc_identify_next功能模块包含以下基础拦截行为。首先,进行令牌检测,如果令牌过期或身份不匹配,将进行拦截处理。其次,从令牌中提取分类标识,并使用is方法进行检测,如果该场景不存在,则进行拦截。接着,检查栏目是否启用了鉴定功能,如果未启用,则返回错误信息。最后,通过内置方法获取鉴定师列表,如果获取失败,同样返回错误。
4、获取鉴定师列表的方式不再通过wpdb处理,而是通过xc_is_identify_expert_list方法来实现。该方法支持缓存设计,可以有效减少数据库的压力。由于鉴定行为非常频繁,因此缓存处理尤为重要。鉴定师列表的结果将赋值给expert_list变量,页面上对鉴定师的所有操作都通过该变量进行处理。例如,如果没有鉴定师,页面将显示【当前栏目暂没有鉴定师】。
5、在选择鉴定师页面中,新增了一个父级类名:xc_identify_next_content。所有的交互动作都通过这个父级容器进行元素锁定,以确保不会与其他页面发生冲突。此外,还新增了一个自定义属性【token】。通过GET请求获取到的令牌名称将直接保存到这个属性中。在后续的支付操作中,页面将利用这个属性获取令牌,从而进行鉴权。
6、在鉴定师页面,通过 xc_is_identify_expert_lis 获取可用鉴定师名单时,没有对返回结果的 code 值进行判断处理,导致在 for 循环遍历输出时出现致命错误。具体表现为:如果返回的鉴定师列表为空,系统仍然会返回 code 值。通过 empty 方法判断时,会误判为有内容,但实际上应该是 false。在 for 循环遍历输出时,由于内容为空,会导致大量报错。解决方案是对 code 值进行验证,并对 data 字段进行检查。只有在存在鉴定师返回结果时,data 字段才会返回。
7、在鉴定师选择页面中,当有可用的鉴定师时,系统会展示其详细资料。展示的内容包括【鉴定师头像、昵称、平均用时、认证信息以及收费标准】,这些信息通过列表项(li)方式呈现。在页面的最下方,有一个菜单用于显示当前选择的鉴定师,并提供一个按钮以便用户进行下一步操作。
8、在移动端开发中,我们设计了一种用户主页跳转方法封装:xc_user_home。该方法需要主动传递用户的user_id,并在内部根据用户的身份属性类别进行判断,从而实现不同的页面跳转处理。具体来说,如果用户是鉴定师,则跳转到鉴定师主页;如果用户属于商户,则跳转到商户主页;如果用户是普通用户,则跳转到个人主页。此方法的设计旨在实现统一化处理,便于后续的维护和开发。不同身份的用户将拥有各自独特的主页设计,以满足其特定需求。
9、鉴定师选择页面的CSS样式已经完成,具体样式设计如下:首先,当列表项被选中时(li.on),其边框颜色会变为绿色,同时背景颜色可以选择变为浅灰色。其次,使用.bui-radios-anim类为背景颜色的变化添加过渡效果,使得视觉效果更加流畅。此外,禁用状态的单选按钮背景会变为灰色(#e8e8e8),而选中时中心的圆点则变为浅灰色(#c1c1c1)。最后,通过隐藏默认的input元素,使用.bui-radios类来创建自定义的单选按钮外观。当按钮被选中时,其背景和边框颜色会变为绿色(#00B066),并在中心显示一个白色的圆点,增强用户的交互体验。
10、在鉴定师列表中新增两个自定义属性:首先是user_id,用于标识鉴定师的唯一ID,通过这个属性可以识别当前选择的鉴定师。其次是price,表示鉴定师的收费价格,这个属性将用于前端页面的交互展示。这两个属性需要直接写入到li容器中。此外,还需新增一个状态类名on,用于标识选中的样式。当存在多个鉴定师时,选中的鉴定师和未选中的鉴定师需要有明显的展示区别。
11、在鉴定师选择页面,当成功获取到鉴定师列表后,系统会遍历并输出这些鉴定师的资料,其中,鉴定师的头像通过调用 xc_get_avatar 方法进行读取。这个方法采用了一种缓存设计,能够非常高效地访问并展示鉴定师的相关资料,从而显著减少对数据库的请求次数及压力,提高页面的加载速度和整体用户体验。
12、在可选鉴定师列表中新增了一个独特类别【identify_next_鉴定师user_id】。当用户点击鉴定师昵称时,通过这一类别来锁定该元素,从而执行相应的页面交互。具体操作包括提取鉴定师的收费标准,并在页面底部进行内容更新,同时对选中的列表项(li)进行标记,将其设置为选中状态,以便于用户的后续操作。这一机制确保了用户在选择时能够方便地了解到鉴定师的相关信息,提升了用户的整体交互体验。
加载更多评论
单栏布局
侧栏位置:
左
你好
天呐
1、在xc_query_identify方法中新增了一个名为“uncache”的变量字段,默认设置为false。当将其设置为true时,本次查询将拒绝使用缓存,强制通过数据库获取最新的有效数据,获取到的数据会更新已有的缓存。在某些特定场景中,数据的敏感性要求较高,通过拒绝缓存的方式确保返回的是真实可靠的信息。
2、在使用 xc_query_identify 查询鉴定订单时,如果将 uncache 设置为 true,且传递的订单号正好是主键ID值,那么在通过 xc_get_sql 发起查询请求时,将会增加一个第三个参数(false)。这一设置表明此次数据查询需要直接通过 wpdb 的原生方法获取数据,而不使用缓存结果,以确保查询结果的实时性和精确性。
3、优化了wpdb查询语句以防止注入风险。在使用wpdb构建查询语句时,通过prepare方法进行SQL查询,从而有效防止SQL注入。同时,将查询方式改为get_row,仅返回第一条记录,从而提升查询性能和效率。此外,表的前缀现在通过$wpdb->prefix动态获取,这使得在后期更新数据表时可以轻松进行一键切换操作。
4、已完成对 xc_query_identify 方法的封装,这一方法将用于未来所有订单类查询的封装处理。其执行逻辑如下:首先,检查给定的 ID 是否为数字。如果是数字,通过主键 ID 进行查询,使用封装的 xc_get_sql 方法来发起数据查询,该方法内置了缓存设计方案。如果缓存被关闭,相同的 xc_get_sql 请求也会被标记为不使用缓存的情况。若 ID 不是数字,则将其视作鉴定编号进行处理。为此,系统会构建一个缓存键名(形式为 query_identify:" . $id),并使用 get_redis_meta 方法检查 Redis 缓存中是否已存在对应的数据。如果缓存中有结果,则进一步判断其内容,如果结果为字符串 "false",则直接返回标记为 false 的结果。对于其他情况,直接返回缓存中的数据。不存在缓存时,系统初始化数据库表名并添加 WordPress 前缀,准备生成 SQL 查询语句以通过鉴定编号查询数据库。查询操作会获取一行结果作为关联数组返回。若查询成功,结果会被缓存至 Redis 中,缓存有效期为一天。若查询失败,则会将结果记为 'false' 缓存至 Redis,防止后续重复查询。
5、function/query.php订单缓存查询脚本库现已集成至宫论核心库中。对于所有使用宫论的项目,这意味着可以直接调用该脚本库的文件和方法,而无需加载任何外部依赖。考虑到订单查询是一个非常关键的环节,后续操作会相当频繁,直接将其继承到核心库中将有效减少频繁引入的麻烦,提升系统性能与操作效率。
6、order_details(鉴定订单页面)基于全新的标准构建,标识命名通过动态化引入实现优化。page-content容器添加了xc_app子类,以明确页面属于APP移动端,从而支持标准组件的集成与监听功能。前端在进行页面交互监听时,可以结合页面标识和content使用,以精准定位和操作元素。此外,该页面还通过is_page方法判断最终页面的位置,提升了页面的响应能力和管理效率。
7、在xc_is_page_open访问拦截钩子处,新增了一项拦截机制。当用户请求访问identify_order_details页面时,将启动xc_query_identify方法检查鉴定订单号是否有对应记录。如果查询结果为不存在(即返回false),系统会立即激活拦截机制,将用户强制重定向至错误页面,并在页面上明显提示【鉴定订单号不存在】。此拦截在页面加载之前便已完成,以确保用户无法访问不存在的鉴定单据页面,从而提升系统的整体安全性与用户体验。
8、为确保鉴定订单列表页面的设计规范明确,使得鉴定师和用户在查看时不会出现功能模块重叠的状况,页面设计需考虑区分两者的不同操作权限。由于该页面既供鉴定师也供用户查看,因此需要根据订单的不同状态(如待鉴定、已鉴定、已退回、已取消)提供相应的操作选项。为此,当用户进入页面时,系统将生成两个变量以明确身份:一个对应鉴定师(expert),另一个则对应申请人(applicant)。如果来访者是鉴定师,则expert变量为true;如果来访者是申请人,则applicant变量为true。页面操作功能的构建将依据这两个变量的状态来判断权限,确保功能模块的操作体验清晰、界限分明,从而避免产生误操作和功能混淆的情况。
9、在订单详情页中新增了一个名为“apply_box”的页面容器,用于展示鉴定申请的基础信息。具体条目包括:鉴定编号(如xxxxxxx)、鉴定栏目(通过key参数鉴权后返回对应分类,如瓷器)、鉴定人(显示站内的昵称信息)、鉴定申请时间(格式为Y-m-d H:i:s)、鉴定状态(根据订单的status字段输出对应内容,例如状态1表示“等待鉴定”)。
10、对鉴定订单表(xc_identify)进行了索引优化处理。首先,将number(鉴品编号字段)设置为主键唯一值,并为其建立单独索引。这是因为许多后续查询都依赖于鉴定编号,为了提升性能,这一优化是十分必要的。其次,将price价格字段的数据类型从varchar(32)调整为decimal(10,2),以便更准确地表示和处理金额,例如2.32元。最后,删除了原有分类索引中的number字段,因为该字段已升级为主键,组合索引已不再需要。
11、新增通用CSS样式规则【box_info】,该样式专用于页面头部容器内容的展示。此前,每次都需要单独编写样式,非常不便,而且这样会导致样式表逐渐变得庞大冗杂。因此,我们引入了一个固定类名,通过此类名统一管理样式。这一新样式将与WeUI组件配合使用,以提升样式美观度,主要用于展示单据和客户信息的基础内容。
12、鉴定订单状态包括以下几种:1. 待鉴定:鉴定订单已完成付款,当前正等待鉴定师进行评估。2. 已完成:鉴定师已对订单完成了鉴定工作。3. 已退回:由于某些原因,鉴定师将订单退回,需进一步处理。4. 已取消:用户在鉴定师开始鉴定前主动取消了申请。5. 鉴定关闭:由于超时、违规操作或其他原因,订单被系统或管理员强制关闭。请注意,状态3和4的订单都会触发退款流程,意味着鉴定订单的关闭,一个是由鉴定师操作关闭,另一个则是由用户操作关闭。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复524楼
1、在infinite_loading页面监听器中新增了一个作用域变量:infinite_content。该变量用于定位到.page-content. + page_name + _content元素的位置,即页面page-content容器的内部。这一调整是因为许多自定义属性无法通过组件模块直接获取,因此在执行AJAX分页加载请求时,需要使用page-content选择器对页面属性进行调整。为了避免重复调用造成的性能浪费,此次优化提前将选择器结果存储在作用域变量中,实现更加高效的页面操作。
2、在xc_template_infinite_page_html模板组件方法中,新增了一个可选变量:meta数组字段,默认为空数组。该变量用于在特定场景下传递自定义属性。例如,在鉴定师订单列表页中,分页加载时需要传递鉴定师的对象UID;或者在查询已完成退款的支付订单时,需要提供status状态字段进行判断。这些需求都可以通过传递meta数组来实现处理。模板内部会解析meta数组,并将相关属性写入待生成的模板HTML中。
3、安全优化:目前,宫论模板组件中的所有字符串信息都会通过esc_attr方法进行转义处理,以有效防止非法字符或恶意脚本的注入,避免可能导致的恶意执行问题。注意,此优化措施适用于所有模板组件中自定义PHP变量的字符串输出,确保每一处都经过esc_attr进行安全处理,避免非法参数写入的情况出现。
4、在后台新版缩略图配置中,新增了一个场景功能,即藏品鉴定的图片缩略图配置(identify)。用户提交藏品进行鉴定时,上传的图片将默认通过缩略图样式进行呈现。只有当用户点击查看大图或使用灯箱浏览时,才会真正加载原图。这一设计有效地减少了不必要的流量消耗,并显著提升了页面的加载速度。缩略图的样式采用:?imageMogr2/thumbnail/300x。值得注意的是,这种缩略图配置将贯穿整个宫论项目,是实施不可或缺的一部分。
5、新增鉴定订单详情页面:module/xc_identify/order_details.php,页面唯一标识:xc_order_details。该页面是一个关键的功能模块,专用于展示鉴定订单的详细信息。默认情况下,此页面的访问权限仅开放给鉴定师和发起鉴定的用户。根据用户权限的不同,他们在查看页面时获得的信息和可操作的选项也会有所差异。鉴定订单具有多种状态,而每种状态下,不同的用户和鉴定师可以执行的操作选项也各不相同。这也使得页面的设计变得相对复杂,但其对于整体业务流程至关重要。
6、访问鉴定订单详情页时,需要通过GET方式传递两个参数变量:1、id,即鉴定订单数据表的主键id值;2、number,指鉴定编号。这两个变量参数用于识别当前用户访问的鉴定藏品订单的唯一标识。通常,只需根据实际情况传递其中之一即可。如果两个参数都为空,页面将返回错误提示。建议优先使用number来传递变量,以避免对外暴露id。
7、鉴定师订单详情页现在按照新标准构建。首先,页面标识采用动态变量进行传递,所有涉及页面操作的地方均通过page_name变量进行输出。其次,在核心库的脚本加载完成后,会立即加载页面访问事件拦截文件(ajax_page),使用内置方法过滤和屏蔽非法及恶意访问行为。最后,引入模板引擎文件,通过引擎生成和处理订单详情页的模板组件。
8、订单详情页集成【xc_is_page_open】访问拦截钩子,当用户访问订单页面的时候,会判断是否有权限进行访问。判断标准如下。通过id或者number来构建wpdb方法去获取鉴定订单表信息,同时使用xc_is_login获取当前用户ID。并与返回的结果进行进一步对比,如果当前用户不是指定鉴定师、不是发起鉴定用户。则视为无权访问。注:拦截钩子执行的时候需要主动传递id或者number,要不然无法获取到相应参数信息。
9、新增了一个名为 xc_get_identify() 的订单读取方法,该方法专门用于获取鉴定订单的信息。其参数需要传递一个变量ID,这个变量支持输入鉴定编码(number)或鉴定表主键ID,函数内部会利用正则表达式来判断ID的类型。借助 WPDB,该方法能够读取并提取鉴定师订单的详细信息。当信息读取成功时,该方法将返回一个包含相应数据的数组结构;如果读取失败,则返回 false。
10、xc_query_identify方法现已支持缓存设计方案,缓存的键值为:get_identify:(鉴定编号或主键)。该方法首先检查缓存中是否有记录,如果存在则直接返回结果,提高了查询效率和响应速度。如果缓存中没有记录,则通过wpdb查询获取相应记录,并在返回结果之前将其存储到Redis缓存中,缓存有效期为86400秒(1天)。需要注意的是,如果wpdb未能查询到结果,方法会返回false,并将此结果以字符串形式写入缓存。当读取缓存时,会首先判断返回结果是否为字符串'false',如果是,则直接返回false。这种处理方式确保了Redis缓存的结果更为精准可靠。
11、宫论项目新增了脚本库【function/query.php】,此脚本专门负责管理和维护订单查询接口的封装。所有订单类型的查询接口按照统一的封装规则命名为:xc_query_订单类型。例如,淘货订单查询接口为:xc_query_tao,保真阁订单查询接口为:xc_query_bzg。传递的参数将根据不同订单类型进行确定。该脚本的核心目标是实现统一管理,提升后期维护的便利性。鉴于订单查询接口通常涉及复杂的缓存管理机制,实施统一管理显得尤为重要。
12、在xc_query_identify执行结果返回前,会首先进行权限验证。如果当前用户未通过xc_is_login验证登录,则直接返回false。若用户已登录,在读取缓存或从wpdb获取结果时,系统会核实用户身份是否为鉴定师或本人账号。如果以上条件均不满足,也会直接返回false。不过,如果用户是管理员,则会跳过这些拦截措施。通过这一验证机制,确保鉴定订单的返回结果仅对相关当事人可见,增强数据的安全性和隐私保护。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复523楼
1、修复并解决了“我的鉴定列表”页面的下拉滚动监听问题。在鉴定师向下拖动页面时,现在能够正确检测页面距离底部的距离。如果该距离超过500像素,则会触发下拉的ajax事件,从服务器请求更多数据以填充页面。之前版本使用的是page_content容器来处理监听事件,而在新版中,改用了模板组件,因此需要调整监听器的位置。通过调整后,监听器能够在页面拖动过程中实时计算距离,确保能够正确触发下拉加载功能。
2、宫论分页数据接口统一化标准:默认页数设定为20,无论是首页还是后续的分页数据请求,皆默认返回20条数据。为了防止兼容性问题,现有的分页请求暂时不做调整,依旧按照原先的页数进行数据返回。然而,对于通过模版组件构建的分页请求和下拉数据,一律采用20条的新默认值。需要注意的是,传统的10条返回可能在后续的大屏和折叠屏处理时出现兼容性问题,可能导致无法触发下拉滚动监听。
3、优化了全局页面的下拉滚动监听事件。现在,在监听当前页面(模板组件)的自定义属性page(页数)时,如果发现该属性为0,将自动触发$('.page-content.' + page_name + '_content').trigger('infinite');事件,从而进行数据初始化请求。通过这种方式,即使在模板分页组件场景中未主动传递初始化数据,也能够在用户访问页面时自动完成数据的初始化装填。
4、分页模板组件现已支持【infinite_loading】全局对象的判断处理,该对象负责管理所有AJAX分页请求。对象键值为【infinite_loading[page_name],其中page_name是页面的唯一标识】。当页面符合分页加载请求条件时,对应的键值为true,不符合分页加载请求时则为false。在实现无尽滚动监听时,需要通过判断infinite_loading对象是否符合AJAX请求,以防止无限加载情况的出现,从而避免性能开销的浪费。
5、为了确保首页内容准确展示,分页模板组件的初始化内容的时,首先会通过page_list.empty()方法清空页面原有内容,避免原来的页面内容与新加载的数据叠加。完成清空操作后,在调用trigger('infinite')方法模拟滚动下拉事件,实现页面数据的重新填充。修复了之前未进行内容清理而导致的数据加载错误,避免了新的分页数据被加载到原来默认错误提示的后面。
6、宫论统一分页接口现在已适配(infinite_paging_api)请求,当收到模版组件构建的分页请求,都将转发到这个接口进行处理。该接口需要传递infinite数组对象,必备的参数有【page:页码,表明当前是第几页、key:场景标识,唯一属性】。可选参数有很多,可以根据场景的需求来传参,比如【sort:请求分类、author_id:用户对象】等等。
7、模板分页接口文件现已调整为返回标准的 JSON 数组结构。由于分页场景多样且各自返回的错误不同,所以不适合采用传统方式来返回数据结构(例如,在无数据时直接返回 false)。这种情况下,前端无法有效处理错误码,因此采用数组结构来处理返回结果。具体而言,code=0 表示数据返回成功,html 已经封装好的前端内容字符串(前端可直接插入);code=1 则表示无记录或有错误,msg 字段提供具体的错误信息。
8、考虑到前端解析存在困难,分页接口在返回数据时,即使没有记录或出现错误,也会包含一个HTML字段。这一字段会通过xc_empty进行转换处理。前端只需专注于对code值进行判断,即可接受结果,将分页接口返回的HTML字段直接插入到相应的容器中。这样既减少了前端的解析和处理负担,也使得后续对返回结果的管理和维护更加简便。
9、前端已完成分页组件模板的结果处理。在服务端完成数据请求后,前端会根据返回的code值执行相应的页面逻辑。首先,如果成功获取到分页数据,则会将生成的HTML内容通过append方法插入到页面底部,并将page变量递增1。接着,通过attr方法将当前页数设置为有效值,同时将infinite_loading[page_name]标记为false,以允许继续触发下拉滚动来加载更多数据。其次,如果未能获取到更多的分页数据(code=1),则会将错误信息通过append方法显示在页面底部,并将infinite_loading[page_name]标记为true,以阻止后续的分页滚动加载。
10、新增前端回调钩子:template_infinite_page_callback()。该钩子将继承模板分页组件中的infinite对象属性值,并在服务端成功返回JSON数据包后被触发,无论code状态如何,都会主动触发此事件。目前,该钩子主要执行两个操作:首先,它会关闭加载动画,以完成页面的交互动作;其次,通过empty方法移除list中可能出现的xc_empty错误提示。
11、为优化前端回调钩子的管理,新增了脚本文件(callback.js),唯一标识为(xc_callbac)。该脚本采用延迟加载的方式,在页面完全加载后执行。通过wp_enqueue_script方法,将其加载到宫论项目中,仅供移动APP端使用。值得注意的是,所有回调事件均被整合到此脚本中,以便后续的维护和更新更为便利。此前使用的HOOK脚本方案非常不便,因此进行了这一改进。
12、宫论服务端同样也新增一个回调动作脚本【function/callback.php】该脚本库负责宫论统一钩子的回调处理,命名规范:xc_钩子的名称_hook_callback($result)在设计钩子的时候,如果需要对返回结果进行后续业务交互处理的时候,就集成一个回调动作脚本,在动作脚本中使用websocket+redis,来完成消息转发功能。注:回调动作,必须是已完成状态,并且不支持任何形式的结果返回监听。只是单纯的触发事件。最好采用异步来处理回调行为,避免阻塞钩子的业务进程。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复522楼
1、在处理媒体文件的回调动作时,当鉴定订单成功建立后,系统会从identify数组中检查是否包含【image:图片列表、video_url:视频地址】等信息。如果存在这些数据,将调用xc_upload_media_ok方法,将相关的图片或视频上传记录更新至对应的鉴定表ID。这一过程确保相关的附件媒体信息与鉴定订单正确关联,防止被系统的计划任务误删或延迟处理。
2、针对xc_upload_media_ok钩子进行了优化,现在第二个变量不仅支持字符串形式的图片或视频地址(切割;),还能够处理数组结构的图片列表。这个方法通过is_array函数来检测变量类型。如果检测到变量不是数组,就会使用explode函数对字符串进行切割处理;如果检测到是数组,则直接跳过切割环节。这一调整有效提升了方法的灵活性和兼容性。
3、在鉴定师获取新订单通知时,系统出现了“Uncaught Error: Call to undefined function get_user_mea()”的错误信息。这个错误的根本原因在于“Undefined variable $id”,具体来说,是因为在通知数组中,当尝试下发消息时,需要提取鉴定订单ID,并获取相应的鉴定信息。然而,在通过xc_get_sql函数读取数据时,由于ID参数缺失,导致了一系列的异常回调错误。目前,所有相关问题已被逐一修复。
4、已修复并解决大量出现的【Warning: Trying to access array offset on value of type bool in 】报错,问题出现在517、527和536行。该错误是由于identify并不是一个数组,试图提取键值时返回异常。这一问题导致短信和邮件消息发送出现异常,而服务号和公众号未受影响。经过排查,发现异常源于xc_identify数据表返回的数据错误,现已完成修正和处理。
5、藏品鉴定助理的UID参数已从19更改为35,以避免鉴定藏品类型订单通知错误地由余额助理下发。正确的服务号消息应由UID 35,即鉴定助理来处理。在创建鉴定师服务号消息通知时,由于疏忽忘记修改这个参数,导致所有鉴定订单的站内信和服务号消息都错误地由余额助理进行处理。
6、今天解决了在通过服务号消息访问订单列表时出现的致命错误问题。该错误具体表现为“Undefined array key 'author_id'”和“Uncaught ArgumentCountError: Too few arguments to”的报错。这一问题源于xc_is_page_open函数在访问拦截时需要传递author_id参数,而用户查看自己的订单时通常不会传递这个参数。为此,采用了三元运算符来处理参数可能为空的情况,从而成功避免了报错现象。
7、在修复访问鉴定师订单列表页面时,发现通过xc_identify_expert_identify_order_list_consult接口返回结果为空,并且出现了致命异常。经过排查,问题出在缺少对author_id的传递。该方法需要两个关键变量:author_id和$status,然而页面中并未主动传递author_id,这导致数据读取失败并引发相关错误。为解决此问题,需要确保在接口调用前,页面正确传递所需的author_id(鉴定师访问,这个值应该是user_id)。
8、修复并解决了【鉴定师订单列表】页面返回的错误问题,包括“Undefined variable $list_consult in”和“Undefined array key 'author_id' in”。由于新版接口已无需通过内置方法主动发起初始数据的加载,因此原来的list_consult数组对象已被移除。新版方法可以自动读取组件数据,从而顺利完成订单初始化的加载,实现了更高效的数据处理流程。
9、在开发分页滚动加载模板组件时,通过使用模板引擎生成该组件,以往流程中author_id(操作对象UID)是通过配置文件设定和提取的。然而,在实际的业务操作中,该变量应通过页面的GET请求参数来获取。如果继续采用固定值提取,可能会导致页面数据加载异常。因此,为了避免错误返回,我们决定取消这一属性的固定配置方式,使其更加灵活地通过页面传参进行动态获取。
10、分页加载组件的初始页数从1调整为0。之前由于初始页数设置为1,自动监听器会误认为页面已有内容输出,从而不会自动触发内置的ajax分页请求接口向服务端发送数据初始化请求。这一数值设置错误直接导致用户在访问订单列表页面时,无法看到相应的订单数据列表,页面显示为空白。
11、前端新增了一个名为is判断方法的xc_is_now_page(),该方法用于返回用户当前所在页面的标识。如果同时打开了多个页面,该方法只会识别出用户当前所处的最后一个页面。方法的判断逻辑如下:首先检索页面元素 page-content.xc_app,并通过last来获取最后一个页面。如果成功获取到相关元素,则直接返回该页面的标识名称(可通过page_name自定义属性来获取)。如果未能成功获取,则返回false。需要注意的是,该方法非常可靠且有效,当需要检测用户所在页面时,基本可以得到准确结果。但需特别留意的是,该方法仅支持新版页面,应避免因不支持旧版页面而错误地返回false。
12、宫论APP端页面路由访问机制新增了方法 xc_page_visit(),用于发起移动端页面访问请求。此前,大多数请求都是通过 xc_mobile_url(link) 方法处理,该方法仅支持通过JavaScript直接访问URL,并仅限于APP内嵌页面,适用于传统页面的跳转。然而,这样的方式无法满足现代页面访问的多样化需求。为了应对这些需求,新的页面访问请求方法需要支持多种操作,包括页面正常向下跳转、页面向上后退访问、刷新当前页面以及在当前页面加载新的内容。因此,我们特地设计了这个新的页面请求方法,以拓展现有功能,提供更灵活的页面访问机制。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复521楼
1、支付成功订单的回调动作进行了新的封装处理。如果支付请求是藏品鉴定请求(identify),那么在完成缓存清理和数据表插入等一系列操作后,会通过xc_notify_hook下发通知给鉴定师。该消息的场景标识为identify_apply,并且附带以下参数:1、user_id:申请鉴定的用户ID;2、id:鉴定订单的主键值。
2、identify_apply消息场景,通用的三个字段变量值分别为:title:新的鉴定订单、content:XXXX,向你发起了藏品鉴定申请,请及时处理、link:这个通过短代码进行生成,指向的地址是用户鉴定师订单列表页(非订单详情页)。具体地址参数为:do_shortcode(' [xc_module type=xc_identify]/expert_identify_list.php')。基本站内信、app、服务号的消息内容,都固定为上述字段。
3、鉴定师在收到新的藏品鉴定请求时,系统会通过xc_notify_hook接口发送短信通知。短信内容为:“{1} 您好,您有一条新的鉴定请求等待处理,请及时前往APP处理!”,其中{1}为鉴定师的名称,采用动态参数传递。为了避免过多打扰,每位鉴定师每天最多接收五条此类短信,超过五条的请求将不触发短信发送。
4、除了短信通知提醒外,新的鉴定订单现在也支持邮件通知提醒。鉴定师如果绑定了邮箱,就可以收到邮件通知。邮件标题为“新的鉴定订单”。邮件正文如下:尊敬的 $user_nickname,您有一条新的藏品鉴定申请,详细信息如下:申请者: $user_nickname,申请时间: " . date('Y-m-d H:i:s') . "订单编号: 。请及时处理该申请。如需帮助,请联系官方客服进行处理。
5、在执行消息通知时,许多参数并未从外部传递到通知数组对象中。因此,需要通过xc_get_sql方法来读取之前建立的鉴定订单,获取如【鉴定编号、鉴定藏品的申请信息,例如分类和鉴赏描述】等详细信息,并将其写入到通知消息事件中,以丰富提醒内容。需要特别注意的是,鉴定编号应从number字段读取,而不是从废弃字段order中读取,order字段将在后续版本中删除。
6、服务号与站内信的通知功能已经完成封装处理,通知的接收对象为【鉴定师助理】。标题为:藏品鉴定申请。正文内容为:xxxx向你发起了藏品鉴定申请,请及时处理。菜单选项包括:菜单1(鉴定编号:ddddddd)、菜单2(申请时间:' . date("Y-m-d H:i"))、菜单3(申请人:' . get_user_mea($author_id, 'nickname', true))、备注部分如有鉴赏描述,则在此处显示。
7、公众号模板消息通知功能已成功部署。若鉴定师绑定了微信且关注了公众号,那么在收到鉴定请求时,系统将自动向对方发送公众号消息。消息的模板标题为【订单处理通知】。其中,keyword1显示鉴定的编号信息,keyword2告知用户有一条新的藏品鉴定申请。使用的模板编号是YRpZrq__R2hb0i1vBoJr1n0snvWcyXoLWpkWJBiXtQA。请注意,公众号模板消息每日发送有30条的限制,超过这一限额后,当天将暂停发送。
8、identify_apply消息通知场景现已全面封装完成。当支付订单触发回调动作时,系统将向鉴定师发送新鉴定订单提醒。这些提醒的内容包括短信、邮件、公众号、站内信、APP通知和服务号消息。其中,短信、邮件和公众号提醒需要鉴定师事先绑定相关信息才能接收,且每天有收发限制。相较之下,站内信和服务号消息则无此限制,确保能及时地传达到每位鉴定师。
9、已修复用户支付藏品鉴定费后,系统生成鉴定订单时出现的两个关键字段缺失的问题。缺失的字段是“cat”(藏品的所属类别)和“collection”(包含所有申请信息,如图片地址、视频地址、鉴赏文字描述)。这些字段的缺失导致订单无法被正确指派。经过排查,问题源于token令牌写入错误。由于安全性考虑,整个交互过程依赖于令牌进行鉴权,鉴权中的意外错误导致信息丢失。目前已修正令牌写入机制,确保鉴权过程的稳定性和信息完整性。
10、在藏品鉴定支付订单回调的优化方面,新增了一项功能:在进行缓存清理时,会主动清理鉴定草稿和鉴权令牌的缓存键值。这一措施旨在避免因令牌未过期而可能引发的安全隐患,即同一令牌可能会被多次用于发起付款请求。同时,我们也移除了草稿记录,以确保在藏品发布时不会误导入已付款的鉴定信息。
11、已修复支付回调接口中返回的异常错误【Attempt to read property "prefix" on null I】。问题的根源在于通过wpdb构建SQL语句进行插入操作时,未提前引入wpdb,导致语法出现异常,从而造成前端接收到意外报错。此外,该错误还导致同步回调接口出现故障,无法主动退出统一支付页面,不过websocket下发的回调通知仍能正常执行。目前,这一问题已经得到有效修正。
12、藏品鉴定支付回调通知已完成封装动作。在用户完成付款后,将依次执行以下步骤:首先,触发统一的回调事件,包括支付订单回调和通过websocket进行消息下发。接下来,系统会创建相应的xc_identify鉴定订单记录,并从令牌中提取相关的图片、视频和文字信息,正确写入对应字段。同时,系统会处理原支付订单中的【shop_order、shop_type】字段绑定回调。为保证数据的可靠性,将执行相关的缓存清理。最后,下发xc_notify_hook消息通知,确保整个流程的完成和数据的一致性。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复520楼
1、服务端新增了一个业务请求:identify_expert_manage。当鉴定师的首席鉴定师(官方)资质被管理员设置或取消时,该请求会被触发。此方法需要传递一个固定参数:status,其中1表示将当前鉴定师设置为首席鉴定师,0表示取消其资质。由于该方法相对简单,因此不需要推送通知消息,以避免可能的误操作(后期如有需要可以补充通知功能)。因此,不需要封装成功钩子,直接在API业务逻辑中进行处理即可。
2、为official_identify_expert_switch元素新增一个自定义属性:author_id(当前鉴定师的UID)。在通过change事件进行状态切换时,将从当前操作对象中提取该鉴定师的ID,并与状态信息一起发送到服务端进行处理。服务端在执行状态变更时,会通过xc_is_identify_expert验证操作用户是否为鉴定师,如果验证失败,则返回相应的错误信息。
3、在前端进行状态切换时,会通过 xc_is_admin 验证用户身份是否为超级管理员。如果用户不是超级管理员,则会弹出错误提示,并将 official_identify_expert_switch 元素的状态恢复到原始状态,同时阻止后续的 AJAX 请求。同样地,服务端也会进行基础规则的拦截。注意:只有超级管理员才有权限设定官方鉴定师的资质。
4、新增了一个服务端钩子:xc_identify_expert_manage_hook。该钩子用于处理鉴定师是否为首席鉴定师的业务逻辑。它需要接收两个变量:author_id和status。在内部,该钩子会执行相应的业务处理,并返回一个标准的数组结构,其中code=0表示操作成功,code=1表示执行失败,msg则提供失败的详细原因。为了便于后期的维护和扩展,我们将其封装为钩子进行处理。
5、设置首席鉴定师是一项极为敏感的操作,即使在超级管理员状态下,也必须进行严格的安全验证,以防止任何非法行为的发生。前端通过user.is_security来检查安全性,如果验证不通过,则会执行xc_hook_jump_page进行页面跳转。服务端则通过xc_is_security进行安全性验证,如果检测到不安全的环境,会提示【设备环境不安全,需要短信验证。】并返回jump=security,要求页面强制跳转以进行处理。
6、在处理首席鉴定师的操作时,服务端首先会进行基础的安全校验,确保所有安全检查完全通过。接着,通过调用 xc_is_identify_expert 方法获取鉴定师数据表的主键ID,然后使用 xc_update_sql 方法更新鉴定师的 official 字段。完成SQL操作后,服务端会返回 code=0 和 msg=操作成功,以便前端进行进一步的响应处理。
7、在进行缓存清理操作时,当超级管理员对鉴定师的资质进行设置或取消(例如首席鉴定师)时,系统会更新xc_expert数据表的结构。为了确保在其他事件中通过xc_is_identify_expert方法获取鉴定师信息时数据的一致性,必须同步更新缓存。缓存的清理键值为identify_expert:加上$author_id。清理操作通过调用delete_redis_meta方法来执行异步清理,以确保缓存中的信息与数据库保持一致。
8、在服务端增加一个额外的验证机制,当鉴定师的状态不正常时,系统应立即返回错误信息:“错误:鉴定师状态非接单状态,不可设置”。只有当鉴定师的状态字段为2(表示可接单)时,才允许进行进一步的操作。这一机制旨在防止那些处于封禁状态或已停止接单的鉴定师被误设为首席鉴定师。需要注意的是,如果是取消首席鉴定师的资格,则可以绕过此限制和拦截。此设计的初衷是避免停用的鉴定师被误操作为首席鉴定师。
9、服务端新增了一个名为xc_identify_expert_manage_hook_ok的回调通知钩子。当首席鉴定师的资质发生变动并且操作成功时,该钩子将被触发。此钩子会接收两个变量:$author_id和$status。如果后续需要集成推送通知消息,或者在为鉴定师写入一些自定义字段时,可以通过这个回调来实现。该钩子不返回结果,也不接受处理请求,仅用于执行相应的操作。
10、当服务端完成首席鉴定师状态变更请求后,会返回一个JSON数据包供前端处理。前端接收到结果后,将根据code值执行相应的交互操作。首先,调用xc_loading_hide函数以关闭加载指示器。接着,使用xc_msg函数触发消息提醒,消息内容由服务端返回,提示操作成功或失败。如果code值为1,则还需额外触发复原按钮的动作事件。
11、在调整首席鉴定师的认证状态时,页面显示“您没有权限执行此操作”的错误提示,这是因为前端使用了错误的判断方法导致的问题。正确的做法应该从user对象来判断用户是否是管理员。同时,还需要修复服务端返回的错误信息,即“Undefined array key 'author_id'”。这个问题是由于前端未能正确获取author_id,导致参数传递异常所致。确保正确地传参以解决这个问题。
12、新增方法xc_is_identify_manage($user_id),该方法接收一个鉴定师ID,用于判断该鉴定师是否为官方鉴定师。如果该用户是官方鉴定师,则返回其详细资料,以数组形式呈现;如果不是,则返回false。需要注意的是,即使是鉴定师,只要不是官方首席鉴定师,此方法同样会返回false。若需判断是否为普通鉴定师,请使用方法xc_is_identify_expert进行处理。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复519楼
1、在xc_hook_subnavbar函数中,第一个变量从key改为page_name。这是因为页面的操作逻辑通常是通过page_name来初始化和管理的,为了保持一致性,提高代码的可维护性,建议在此处也采用page_name作为变量名。由于监听器和钩子的处理逻辑基本保持一致,因此如果代码发生变动,两者都需要做出相应的适配性调整,以确保系统的稳定和功能的连贯性。
2、在完成菜单切换的基础事件处理后,系统将执行一系列操作以触发页面数据的加载。首先,需要将页面组件的sort参数属性更新为从钩子传递过来的参数,以确保菜单状态标识得到及时更新。接着,将page页码重置为0,这样在之后进行ajax请求时,实际请求的页码将会是1,从而确保数据从第一页开始加载。此外,使用empty方法将现有的page_list内容清空,以为即将到来的新数据填充预留空间,确保新的数据能够无误地被加载并显示在页面上。
3、xc_hook_subnavbar 的数据填充模式并没有采用传统的方法,而是通过在内部构建相应的 Ajax 请求,向服务端请求数据,然后在页面上执行插入操作或其他交互动作。这种方法的维护相当不便,要求对监听器和钩子同时进行同步修改。为了提高维护效率,现在采用了一种新的填充模式,即直接通过触发器(trigger)来激活 infinite 元素,从而模拟数据填充操作。这一方法转而利用内置的监听器来实现数据的自动填充。
4、宫论分页数据填充的业务逻辑已经基本完成封装,新版本的下拉数据加载机制已经完全以组件的形式引入,只需在页面上设定对应的参数信息,即可轻松实现滚动条的部署工作,避免了每次执行分页加载请求时都要繁琐地编写大量监听器代码。分页数据填充模式还支持菜单切换功能,并提供了一个前端钩子,用于处理菜单切换时的业务交互。
5、鉴定师订单列表页(identify_expert_order_list)现已顺利集成了下拉滚动组件和菜单切换钩子,极大提升了用户的交互体验。页面的数据加载与切换操作均由内置监听器自动完成。当用户进入页面时,系统首先检测页面中是否包括相应的组件标识;若检测到存在,则会立即构建相应的组件模块,并通过触发器来初始化数据加载。当用户进行下拉动作时,页面能实时监听并迅速响应,实现数据的自动填充,
6、在执行支付鉴定订单的回调动作时,通过xc_insert_sql方法将支付表中已成功付款的单号和收款人信息一起插入到xc_identify鉴定订单表中。这样一来,鉴定订单便可以通过payment字段获取到支付订单数据表的详细信息,例如追踪退款详情、核对支付订单数据等操作。此外,为了简化查询过程,此处写入的单号为ID主键。
7、当用户完成藏品鉴定订单的付款操作后,系统会自动触发一个额外的缓冲清理操作。这一操作通过调用 clean_redis_key 函数,将所有与鉴定师订单列表相关的分页查询缓存彻底清除。由于新的订单产生,之前的缓存内容不可避免地需要更新,因此进行此操作是必需的。缓存的清理按照特定的键值标准进行,具体为 expert_identify_order:*。请注意,这意味着系统将清理掉所有鉴定师订单记录的查询缓存,从而确保数据的最新和准确。
8、在对鉴定师订单缓存机制进行优化时,我们对缓存键值的命名方式进行了调整,新的命名格式为:expert_identify_order_' . $author_id . ':' . md5('consult' . $status . $offset . '-' . $number)。此次调整的关键变化在于将author_id(即鉴定师的UID)从MD5哈希计算中移除,并直接插入到缓存键的前端位置。这一改动的主要好处在于,当需要清理缓存时,我们可以更具针对性地清理特定鉴定师的记录缓存,而无需对所有鉴定师的记录缓存进行全面清理。
9、在鉴定师配置页面,我们增加了一个新的字段:xc_identify_official_list(官方鉴定师)。这个字段用于填写鉴定师的UID,对于多位鉴定师,我们使用分号进行分隔。这个名单中的鉴定师被视为官方首席鉴定师,他们在鉴定藏品为真品时,用户可直接进行送拍或选择寄售回收操作,而无需进一步的官方审核。需要注意的是,这个方法尚未最终确定,此外也可以考虑通过用户资料页面来实现官方身份的设定与绑定。
10、新增的字段“official”(VARCHAR(16))旨在为鉴定专家表(xc_expert)增加一个官方标识功能。当某位鉴定师被认定为官方人员时,此字段将被设为“1”;如果不是官方鉴定师,则该字段保持为空或标记为“0”。如果鉴定师具备官方身份,系统将优先推荐其进行鉴定,而且他们出具的鉴定报告上也会特别注明官方标识。此外,官方鉴定师所鉴定的藏品一旦确认为真品,便可以直接进行拍卖等相关操作。此举可以提升官方鉴定师的权威性和可信度。
11、在鉴定师资料管理页面中,基础资料区块(identify_expert_info)新增加一个切换开关,用于控制当前鉴定师是否具备【官方鉴定师(首席认证)】的身份。当页面加载时,系统将读取鉴定订单表中的official字段,以确定该鉴定师的当前状态。如果该字段显示为官方认证,则开关默认设置为选中状态,即属性为【checked="checked"】。若非官方认证,则开关处于未选中状态,移除checked属性。管理员可以通过切换此开关来轻松设置或取消鉴定师的官方认证状态,从而灵活管理鉴定师的认证资格。
12、在identify_expert_manage页面新增了一个change监听器,用于监控official_identify_expert_switch元素的状态变化。当该选项框的状态改变时,系统会检查其当前的布尔值状态。如果状态为true,则将变量status初始化为1;如果状态为false,则将status初始化为0。随后,程序通过ajax将这个status变量发送至服务器,以便进行相关业务处理。此变量的值用来确定鉴定师是否担任官方首席鉴定师的角色。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复518楼
1、分页API接口现已支持(infinite_paging_api)请求。当监听器自动触发分页请求时,系统会自动解析无限数据包,并构建标准的分页方法以获取当前分页数据。需要注意的是,由于请求的复杂性,服务端的分页接口数据返回将根据不同场景进行自定义处理。整个监听器场景,自动化部署仅是针对前端处理。
2、通过使用xc_template_infinite_page_html模板生成的前端分页滚动加载组件,我们新增了一个自定义属性,即场景的标识名称(也可以理解为页面标识)。在现有的前端触发器中,这个标识名称会被提取到infinite对象数组中,并传递到服务端进行响应处理。服务端将根据这个标识名称来判断请求的来源,从而执行相应的分页请求数据填充操作。
3、服务端分页接口触发器请求现已支持【鉴定师订单列表:identify_expert_order_list】的数据返回处理。当收到该场景的请求时,系统将通过xc_identify_expert_identify_order_list_consult方法获取相应页码的订单数据。如果数据获取失败,系统会返回相应的错误提示;如果数据获取成功,系统将遍历数据并将其赋值到HTML中进行展示。
4、为了优化鉴定师订单的分页方法,将第一个参数从user_id更改为author_id。这是因为分页请求可能由管理员发起以查看鉴定师的订单。如果使用user_id作为参数,传递的用户UID会被内置的xc_is_login覆盖,导致返回的并非指定用户的鉴定订单,而是当前用户的鉴定订单。请注意,函数内部相关的用户参数已经进行了相应的修正处理。
5、模板组件方法:xc_template_infinite_page_html 新增了一个第三个可选变量 author_id。在某些场景下,需要读取指定用户的 UID 来获取分页数据。例如,查看审核日记、用户的鉴定申请记录或淘货的订单交易记录。这些场景都需要传递相应的用户 UID(而非当前用户)以便返回指定的参数。在这些情况下,提取页面的 UID 是完成订单数据源处理的关键步骤。
6、分页模板组件的方法得到了进一步优化,现在仅保留两个变量。第一个变量是key,用于标识场景;第二个变量是infinite,这是一个数组,默认情况下为空。如果不需要传递特殊参数,可以选择将其置空。举个例子:如果我的组件方法需要使用author_id(作者)这个参数,那么可以通过infinite['author_id']来传递参数,这样参数会自动接入到自定义属性中。再比如,在分页场景中需要使用cat(藏品分类)参数,也可以通过infinite['cat']来传递参数。
7、监听器升级优化,当onPageBeforeInit监听进入页面后,如果页面包含元素【.page-content.' + page_name + '_content.infinite_loading】则会触发ajax分页加载的监听。这里有个重要调整,如果page_content.attr('page')元素返回的数字是0,则会主动执行一个动作【page_content.trigger('infinite');】。注:意思是,检查初始页码是否为0,如果是,则主动请求数据。并执行原有的填充机制。换句话就是页面可以选择不提前填充内容,通过内置方法来进行页面初始化填充。
8、如果首页的数据需要通过监听器自动填充,那么在执行触发动作时,应提前使用page_list.empty();方法清空列表容器的所有子元素和文本内容。这样可以避免在插入分页数据后,原有的初始化提示信息(例如:“暂没有相关鉴定订单”)仍然保留在页面中,从而确保页面显示的内容是最新的和相关的。
9、页面标准化处理:目前在【page-content】后面新增了一个通用类名:xc_app。通过使用page-content.xc_app的选择器,可以有效判断页面是否归属于宫论APP。这一元素选择器极其重要,未来所有的页面位置检测和判断将依赖于这个类名组合来实现。对于移动端的页面开发,未来都必须强制将这个类名写入其中,以确保一致性和功能的正确性。
10、除了页面需要通过监听器来执行下拉滚动组件的数据加载填充外,还需要对应的菜单切换事件来完成指定分类的下拉滚动事件的处理。考虑菜单切换的场景也很多,因此单独封装一个前端事件来xc_hook_subnavbar()动态处理数据类型切换。该方法将结合分页组件,实现页面菜单切换,组件也会自动进行参数切换。
11、在进行页面交互时,xc_hook_subnavbar钩子需要提供三个关键变量,以确保功能顺利实现。首先是sort,这个变量用于状态分类,在从A菜单切换到B菜单时,通过sort标识可以实现数据的动态填充和更新。其次是key,该变量主要用作场景标识,通常是页面的唯一标识符。通过key,系统能够识别当前的数据请求来源,从而准确提供相应的数据支持。最后是this,这是一个上下文对象。处理菜单内部事件时,使用this可以便捷地操作和管理当前对象的属性和方法,确保功能逻辑的连贯性和一致性。
12、xc_hook_subnavbar:在进行菜单数据填充之前,该钩子会执行一系列交互操作。首先,会创建一个作用域变量【page_content】,后续所有的页面交互都会使用这个变量作为选择器进行操作。接下来,系统会检查名为.page-content.' + key + '_content'的元素是否存在,如果不存在,则会立即返回一个错误信息【非法请求】。然后,通过animate函数将导航栏的滚动位置重置为顶部,这一操作在菜单切换时尤为必要,以便刷新页面数据。最后,使用obj为当前选中的菜单项添加选中样式,同时确保移除其他菜单项的选中样式。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复517楼
1、新增的模板组件脚本文件库【/global/publish/template.php】旨在简化组件的管理和使用。当项目中涉及到组件的调用时,只需通过require_once加载这个文件,即可实现自动加载所有的组件脚本库,例如:publish_report.php和publish_video.php等。未来扩展的新模板组件也将通过这个统一的脚本库集成进来,大大提升了系统的维护性和管理效率,使得组件调用变得更加方便快捷。
2、模板引擎解析脚本库新增了一个函数方法【xc_template_infinite_page_html】,用于处理分页下拉滚动加载的模板组件。这个方法需要传递两个变量。首先是分页的页面标识参数,这是一个唯一属性,对应后台配置的具体场景,用来防止监听器的错误重复注册。其次是html变量,即容器内的初始化展示内容。这可以是一段xc_empty的提示信息,也可以是已经封装好的li列表内容,具体的内容形式取决于前端的构造方式。
3、在使用模版引擎构造滚动下拉组件的过程中,首先会调用xc_is_config方法,检查验证配置xc_template_infinite_page中是否包含特定的页面标识场景的key。如果该key存在,那么将开始构建设计,并返回生成的HTML内容。这种直接返回HTML的做法是为了方便将内容输出到页面中。如果所需的key不存在,流程则会被跳过,函数会直接返回false,而不产生任何输出或数组结果。这种设计旨在提高页面渲染的效率和灵活性。
4、在修复页面返回功能时,我们发现了一个错误:页面返回时出现了“Uncaught ReferenceError: page_name is not defined”的报错。这种错误导致页面的后退动作异常,无响应的现象第一次发生后,用户很难再进行正常的页面返回尝试,第二次尝试返回时页面直接关闭,所有打开的页面都消失。经过深入分析,问题的根源是page_name这个变量被let声明,因此它的作用域受到限制,导致无法在全局范围内访问。为了彻底解决这个问题,已经将page_name变量移出局部作用域限制,并改为使用全局变量配置,使页面的后退行为恢复正常,避免了异常监听错误的出现。
5、通过模板引擎构造的下拉滚动器功能已经完成封装,这里提供的输出CSS类名结构如下。首先,我们有三个主要的全局class类名。第一个是template_infinite_page,这是父级类名,用作组件的标识。所有元素的操作都是通过这一父级类名来进行的。接下来是第二个类名:$config['key'],通常用作页面标识,根据具体页面场景的不同,可以设定不同的样式和行为。最后一个是自定义的$config['class'],这是由后台进行设定的,可以根据实际应用需求进行调整和适配,以确保组件在各个场景中的正确显示和功能性。
6、模版引擎的自定义属性和正文输出部分:自定义属性主要包括三个方面。首先是page属性,表示当前的页数,默认值设置为1。其次是number属性,指的是每页返回的数据量,这个数量通常由后台场景进行配置,默认值为20。最后是sort属性,这是一个分类状态标识,与页面的菜单切换功能相关,如果页面有切换菜单的功能,这个属性就必须被指定;但如果是单一页面的下拉滚动加载,这个属性可以为空。正文的输出部分通过<div class='list'>" . $html . "</div>来处理,其中$html是可变内容,如果它为空,则通过函数xc_empty($config['info'])生成适当的错误提示信息。这种设计确保了在不同条件下页面内容的动态调整和有效显示。
7、我的鉴定列表(identify_expert_order_list)现在已经升级,通过xc_local_link引用模板引擎库脚本。这种方式使得在页面中能够灵活调用xc_template_infinite_page_html(key,key,html = '')方法,来实现分页滚动加载组件的部署。当用户在页面上进行滚动操作时,系统会自动读取该组件的配置信息,然后通过请求服务端的分页接口,动态加载并填充相应内容到组件中。
8、为了提高滚动监听器的性能,我们对其结构进行了优化。之前的实现方式是利用page-content设置自定义属性,并通过内部统一监听器来读取这些属性信息。然而,这种方法需要将整个页面容器都纳入监听范围,这在处理页面自定义时显得不够灵活。因此,我们决定进行调整。现在,通过xc_template_infinite_page_html方法部署的滚动加载容器,不再依赖原有的page-content页面属性来完成配置读取。取而代之的是,通过其自带的属性来实现相应的处理,使得配置更加灵活,提升了页面的自定义友好性。
9、onPageBeforeInit页面访问监听器的机制进行了一次重要改进。之前通过使用page_name作为父级类名来进行处理(分页滚动加载)的旧方法,现在已经被淘汰。新的方法是通过检测页面中是否存在分页组件来进行选择器的判断【即:('.page-content.' + page.name + '_content .template_infinite_page')】。此外,页面自定义属性的获取方式也发生了变化,不再从page-content中直接提取,而是改为通过具体组件的自定义属性来获取。这种更新不仅提高了页面加载的灵活性,也增强了对复杂页面结构的支持能力。
10、在鉴定师订单列表页面(identify_expert_order_list)中,系统现在利用分页接口函数【xc_identify_expert_identify_order_list_consult】来获取首次加载时的首页数据。如果该请求成功且有订单记录返回,系统会创建一个名为list_consult_html的变量,随后,通过for循环将所有订单记录逐条转换为li元素并添加到list_consult_html中。完成数据的处理后,将赋值的list_consult_html变量传递给分页组件,实现页面的初步加载与展示。如果请求失败并且未返回任何订单记录,则list_consult_html会被标记为false,以反映数据加载的状态。
11、考虑到页面越来越多,组件扩展也越来越丰富。很多文档更新跟不上进度,页面交互动作写入出现重复问题。对于一些特定的页面结构设计,文档中单独列出一个示例文件夹。比如视频组件的调用方法,单独命名一个video.php,里面将会详细演示这个组件的调用使用方法。避免时间久了,忘记页面引入使用方法。造成阅读困难,甚至重写的问题。
12、在对监听器的自动分页递增动作进行优化时,原先的做法是通过读取content容器的page属性,将其值加1后重新写入,以确保页面标记始终处于有效状态。然而,在新版本的方法中,由于放弃了通过page-content作为父级类名的策略,原有方法失效。新的实现不仅更新和读取组件的页数,且引入了parseInt方法,将页数转换为整数后再进行累加,以防止可能出现的错误字符干扰,从而提升操作的准确性和稳定性。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复516楼
1、在实现标准的通用ajax分页加载填充事件时,需要为加载li内容处理指定一个容器类名。这一类名的固定标识为【page_list】,书写格式规定为(page.name + '_list'),其中前者为动态页面标识符,后者则表示为列表的含义。不同页面的容器可以有各自独特的风格设置,支持根据子类进行个性化设定。通过场景标识解析,可以灵活应用不同的CSS样式,确保页面显示效果与其特性需求一致。
2、在page_content中新增了一个名为type的第四个属性,这是一个服务端API接口标识参数。由于封装的需要,对分页接口请求进行type表示处理显得尤为重要。例如,当type被设定为review_identify_expert_api时,系统在执行ajax填充请求时将自动识别并响应此type,从而执行相应的业务逻辑处理。通过在不同的场景下设定不同的type值,能够有效地实现接口业务的分类和优化处理,提高系统的灵活性和响应效率。
3、在通过onPageBeforeInit监听器来触发分页内容的加载时,提交到服务端的请求参数采用对象数组结构进行处理。为防止内存溢出,初始化变量定义为【infinite:作用域变量】。目前,该请求参数具备三个固定的键值:首先是“type”,用于标识具体的场景;其次是“page”,代表页数,默认为1;最后是“sort”,则用于指定分页类型,例如可以传递参数来仅返回已退款的订单或仅返回已通过审核的鉴定师名单等。除了这三个基础值外,还可以根据具体应用场景,动态提取并附加相应的属性值,然后对其进行封装再提交请求。通过这样灵活的参数设计,确保系统在满足多样数据请求场景的同时,维持高效的内存使用。
4、宫论的统一分页接口请求(paging.php)现已增强功能,支持监听器的分页请求功能(标识为:infinite_paging_api)。当监听器成功完成对infinite数组的对象封装时,会在页面的list容器中通过after方法插入一个loading_post动画,然后触发ajax请求以访问分页接口,此时会携带infinite数组一起发送。分页接口在接收到API请求后,首先会对请求的合法性进行验证,若验证通过,则提取infinite数组参数,并进行相应的业务处理。
5、为了优化分页请求的返回数据量,针对不同的场景需求进行调整,某些场景可能需要返回更多的数据内容,而某些场景则需要较少的数据量。为确保这种多样化要求的兼容性,采用了监听器自动化部署滚动加载器的新技术。通过此自动化系统,允许在容器内部设定一个自定义属性:“number”。这个属性的默认值被设置为20。若需要调整返回内容的数量,可以根据具体需求对这个数字进行修改。此属性会被封装成infinite['number'],并通过分页接口传递,实现了灵活的内容加载和用户体验优化。
6、监听器在自动触发分页请求(infinite_paging_api)后,首先进行接口的安全验证。完成验证后,它会从请求的post对象中提取出infinite数组,并对该数组中的值进行基本处理。具体来说,首先处理的是infinite['page'],即请求分页的页码。如果该值为空或不存在,则默认重置为1。接下来是每页设定的内容数量,即number参数。如果number为空或不存在,则默认设定为20。最后,通过设定offset来计算偏移量,具体公式为(infinite[ ′ page ′ ],即请求分页的页码。如果该值为空或不存在,则默认重置为1。接下来是每页设定的内容数量,即number参数。如果number为空或不存在,则默认设定为20。最后,通过设定offset来计算偏移量,具体公式为(page - 1) * $number,从而获取到正确的页码内容。
7、为了实现前端页面的自动化滚动填充功能,通常需要设置多个复杂的容器参数。然而,为了简化这一过程并减少操作步骤,决定采用模块化设计处理方案。通过使用宫论内置的模板引擎,构建一个页面方法来完成容器组件的生成。这样的方法只需要传递一个场景名称,就能完成整个模块的生成。这不仅大大简化了部署工作,还使得后期的维护更加轻松,无需对每个页面进行单独维护,只需专注于模板方法的优化和调整即可。
8、在后台发布设置中,新增了一个名为【xc_template_infinite_paging_config】的配置组,专门用于模版引擎中的分页加载监听器配置。此配置器需要传递以下几个关键参数:首先是name参数,用于提供来源说明和详细文字介绍,以便用户理解该配置的作用。其次是key参数,这是一个为配置项提供唯一标识的标识符,设置后应保持不变,通常采用页面标识名称以确保唯一性。然后是class参数,负责定义样式,以便进行样式适配,确保页面呈现一致性。此外,number参数设定了每页加载的条目数量,默认为2,固定不变,便于保持统一的加载体验。最后是sort参数,其作为分页标识名称,主要用于指定需要状态的分页情况,若无特别需求则可以留空。
9、在xc_template_infinite_page的配置中,特别增加了两个新的字段,以提升其灵活性与用户体验:首先是“header_html”字段,它是一个大文本输入框,当你需要通过ajax加载一个自定义的HTML区域时,可以在此输入具体内容。这不仅支持HTML代码,还允许使用短代码,为用户在开发和设计上提供了更大的自由度。其次是“info”字段,用于显示提示内容。当系统需要告知用户某些信息,比如“没有更多鉴定订单”或“没有更多收藏记录”时,可以在这里自定义相应的提示或错误信息。这些字段都是作为扩展选项添加的,因此可以根据实际的使用场景选择是否进行配置,从而确保页面在加载和提示时的个性化需求都能得到满足。
10、新增第一个模版引擎[分页滚动加载]场景:【identify_expert_order_list:鉴定师的订单页面】。此场景的参数设定如下:自定义样式(identify_expert)被用于指定页面的样式布局,以确保页面显示符合预期。每页加载的订单条目数被设定为20,以便于用户在滚动时能够流畅查看订单详细信息。默认状态标识为0,这意味着在没有特别筛选条件的情况下,页面将返回所有订单,因为该页面支持菜单分页加载,因此默认设定为显示所有订单。加载更多内容时,若无更多订单需要显示,则页面将提示“没有更多鉴定记录”,以明确告知用户当前已浏览完所有可用记录。
11、新增的模板引擎配置文件【configure/template.php】中预设了图标为fa-opencart。在宫论项目中,模板引擎的概念已经被引入,并通过封装不同的组件实现了一键化的页面部署。然而,由于不同组件的配置选项各异,使得维护过程复杂且繁琐。为了解决这个问题,特别设定了一个独立的配置页面,用于存储和管理这些参数信息,从而简化维护流程,提高整体项目的可管理性。
12、以下配置字段已从其他地方迁移至【模版引擎配置页】:1. 模版引擎的[分页滚动加载]配置。2. 文本框表单配置字段:xc_publish_textarea_config。3. 图片上传组件配置:xc_publish_component_image。4. 表单内容填写组件配置:xc_publish_component_textarea。5. 视频上传组件配置:xc_publish_component_video。6. 藏品分类内容组件配置:xc_publish_component_category。7. 视频上传的相关配置:xc_upload_video_config。8. 图片上传的相关配置:xc_upload_image_config。这些字段都是为了优化模块的灵活性而封装的模版组件配置,通过将它们集中到一个配置页,可以更方便地进行管理和维护。此外,所有后续的模版组件也将整合封装到template.php文件中
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复515楼
1、page-content(鉴定雷暴新增两个自定义属性)首先是page:该属性用于记录鉴定订单列表的页码,页面首次加载时默认设置为第一页。其次是sort:用于定义鉴定订单列表的排序类型。這兩個自訂屬性极其重要,無論是在页面的向下滚动加载过程中,還是在菜单切换时,皆潜在需要进行數值的更新與維護。需特别注意的是,在执行分页请求时,前端所传递的信息必须确保其有效性和可靠性,以便系统能够准确无误地响应用户的操作需求。
2、在执行分页菜单数据请求之前,xc_exoert_identify_list_order会进行一系列的页面交互处理。首先,它会将sort参数更新为事件传递过来的status,以确保接下来的AJAX请求可以稳定地获得预期的数据。接着,将page参数设置为1,这是因为菜单切换的操作本身意味着需要重置为第一页的内容。最后,它会在当前选中的菜单项上添加相应的选中样式,同时移除其他菜单项的选中样式。
3、当用户访问鉴定师大厅列表页面时,将会触发onPageBeforeInit监听器。该监听器负责实现一系列页面交互行为。例如,执行AJAX分页加载的初始化,以便动态获取和呈现更多内容,同时,监听滚动事件以确定是否需要进一步加载数据。此外,用户与鉴定订单的交互操作,如查看详情、提交反馈或申请修改等,也会通过此监听器进行处理。只要用户进入该页面,所有主动操作行为都将通过这个内置监听器进行管理
4、鉴定师订单列表页的监听器主要负责监控Ajax请求的滚动事件,以及处理分页数据的加载与填充。在用户进入此页面时,会初始化一个名为identify_expert_order_list_loading的全局变量(非作用域属性)。这个变量的变化用于判断页面是否继续监听无限滚动事件,并决定是否执行后续的数据填充操作。由于有两个不同的地方涉及到内容填充,因此需要依赖全局属性来验证当前状态,以确保填充过程正确,并且避免数据的重复加载或遗漏。
5、在订单列表页面中新增了一个容器,名称为.list.identify_expert_order_list_page_list,用于加载和填充相关的订单列表信息。页面初始化时,通过调用xc_identify_expert_identify_order_list_consult方法函数来获取订单数据。如果数据获取失败,则通过xc_empty显示提示信息【没有更多鉴定订单记录】。在初始化过程中,系统默认会传递参数status:0,以便获取所有相关的鉴定订单。
6、在宫论项目开发中,经常需要处理大量的分页滚动加载页面,这导致每次都要编写复杂冗长的监听处理代码。为了解决这个问题,尝试通过统一化封装的方式,简化并规范化这类操作。具体方法是将所有的类名处理通过新版page_name进行子类元素锁定。无论是点击事件还是滚动监听,所有元素的取值和选择都基于page_name作为父级类名来关联。比如,通过page_name + '_loading'可以作为全局状态参数变量,而使用$('.page-content.' + page_name + '_content')可以精确找到对应的容器位置。
7、全局分页加载统一事件适配处理:当用户所在页面需要支持分页加载功能时,应在page-content页面中添加一个通用类名【infinite_loading】。该值的存在标志着页面支持分页加载动作。接下来,将设置一个访问监听器,以检测当前打开的页面是否存在类名.page-content.infinite_loading。一旦检测到该标识,监听器便会自动启用并处理分页加载的相关逻辑,以确保用户体验的流畅性和功能的实用性。
8、要部署标准的分页加载事件,除了要给元素添加 infinite_loading 类名之外,还必须提前设置三个自定义属性。这三个属性是实现分页功能的关键,无论在何种场景下都不可或缺。此外,如果分页请求需要其他特定的参数,可以在之后新增自定义属性进行配置。这三个必备的属性包括:1. page_name:这是当前页面的唯一标识符,也可以用作全局父级类名。在处理分页请求时,通过这个全局父级类名来确保不同页面间的请求不发生冲突。2. sort:这是分页菜单的状态标识符。由于大多数分页场景中都涉及菜单切换功能,设置这个属性有助于对不同菜单状态进行识别和处理。3. page:表示当前的页数,初始化时将其设定为1。该属性用于跟踪和维护页面加载次数,确保分页顺序及内容加载的正确性。
9、在onPageBeforeInit阶段,增加一个全局监听事件。当访问的页面中包含具有类名【.page-content.' + page.name + '_content'.infinite_loading】的元素时,该事件会被触发。这一元素标志着当前页面需要实现通过AJAX进行分页的下拉滚动数据加载。其中,page.name是当前页面的标识名称,按照标准命名规范,即指代当前页面的容器区域部分。一旦检测到该页面元素的存在,监听事件将把元素的选择器赋值给let作用域变量:page_content。这一变量将在后续的页面交互中,用作父级类名的锁定。
10、onPageBeforeInit在初始化时,会从page对象中提取出page.name,并将其赋值给全局变量page_name,以便后续事件能够方便地进行调用。当成功监听到infinite_loading事件时,将会从页面中顺序提取出【page_name、page、sort】这三个自定义属性。随后,会初始化一个名为infinite的对象,将此对象设置为一个空数组,然后将提取到的三个属性值分别存储到该数组对象的对应键值中。这些值将用于后续的AJAX请求,直接将数组对象传递过去以便于请求的执行。
11、在动态生成变量名称时,通过直接使用page_name + '_loading'这种方式会导致返回Uncaught SyntaxError: Invalid left-hand side in assignment错误,因为它试图在赋值语句的左侧使用一个不合法的表达式。为了解决这个问题,目前的修正方法是借助对象来动态访问属性。首先创建一个超全局变量数组infinite_loading,通过使用infinite_loading[page.name]的方式来进行布尔值状态的管理和处理。这种方法不仅可以避免语法错误,还能更清晰地管理与不同页面状态相关的数据。
12、全局管理函数脚本库【global.js】已成功加载并初始化了infinite_loading对象数组。onPageBeforeInit监听器也已设置完毕,确保支持该数组对象。在分页加载请求被触发时,系统将通过infinite_loading[page_name]来动态更新其值为false或true,以此保证页面能够精准地执行AJAX分页请求并完成数据填充。此外,分页菜单的切换也需要兼容并适应这个对象数组,以确保功能的稳定性和一致性。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复514楼
1、在分页函数脚本库中新增了一个方法:xc_identify_expert_order_list_consult,用于处理鉴定师订单列表的分页请求。该方法需要传递以下固定参数:首先是user_id,即鉴定师的UID参数,用于指定需要查询的用户对象;其次是status,即状态标识,该参数的值对应于数据表中的状态字段。所有涉及到鉴定订单提取的请求都通过此方法进行处理。如果请求失败,该方法将返回`false
2、为了优化鉴定师订单分页接口方法,我们新增了两个变量参数:【offset:结果集的偏移量,默认为0,即从第一条记录开始;number:返回的记录数量,默认为10】。通过引入这两个参数,可以有效地实现返回结果的分页处理。在请求数据时,只需计算offset值,即可实现页数的计算,这样便能精确获取对应的结果集并返回。
3、现在分页函数将加载wpdb方法,通过SELECT查询【xc_identify】数据表,筛选出符合指定状态和鉴定师的所有记录。这个过程中,将使用prepare函数为查询语句指定参数类型,以确保执行安全性。如果查询结果中存在满足条件的记录,则返回相应的数组结果集;如果没有找到符合条件的记录,则返回false。
4、分页接口现在新增了一个名为【uncache】的第五个变量,用于控制缓存机制。默认情况下,该变量为false,表示启用缓存。如果未显式禁用缓存,系统将首先尝试读取缓存记录,缓存键为【'expert_identify_order:' . md5('consult' . user_id .user i d.status . offset . '-' .offset. ′ − ′ .number)】。仅在缓存记录不存在时,系统才会通过wpdb获取相应的数据记录,并同时更新缓存。请注意,缓存记录的有效期被设定为86400秒,即24小时,超过此时间缓存将自动刷新。
5、在将鉴定师订单缓存查询结果写入缓存时,如果查询结果为false(表示没有相关的鉴定订单记录),这种情况下也会触发update_redis_meta缓存更新操作。然而,由于Redis本身不支持存储布尔值,我们会将false以字符串形式"false"写入缓存。当前端从Redis中读取缓存时,如果结果存在,会进行额外的验证,检查返回结果是否为字符串"false"。如果匹配,则实际返回false。这样做确保了系统能够正确识别和处理缓存中代表无订单记录的特定标识符。
6、鉴定师订单查询接口已重新命名为:xc_identify_expert_identify_order_list_consult。此方法现在具备两个基础拦截规则:首先,如果用户未登录,则直接返回false;其次,如果用户不是管理员或鉴定师,也直接返回false。这些规则旨在防止数据的非法请求,确保只有管理员和鉴定师可以查看该分页数据接口的信息。
7、鉴于分页接口已经支持同步返回所有订单的请求,在使用鉴定师订单分页查询接口时,会针对status字段进行灵活性调度处理。目前,除了可以传递特定的数字状态外,该字段还新增了对【all】值的支持。当传递all时,表示此次请求不需要限定特定状态,系统将返回所有关联的订单。
8、鉴定师订单列表大厅页面(identify_expert_order_list)现已改进为通过分页接口函数来初始化鉴定订单记录。具体获取方式为:首先优先从鉴定师对象中读取author_id,若未指定author_id,则将使用当前的user_id。订单状态(status)被设定为ALL,以便获取所有状态的订单。偏移量(offset)设定为0,表示从初始位置开始读取。每次提取数量(number)设置为10,意味着每次返回前十条订单记录。获取到的结果集将会被存储在identify_list字段中。
9、前端新增了一个名为xc_exoert_identify_list_order的方法,用于管理鉴定师订单列表的菜单切换。此方法需要传递两个变量值:首先是status变量,它是一个状态切换字段,用于区分不同类型的鉴定记录。例如,你可以通过设置此字段来查看鉴定师待处理或已完成的鉴定订单记录。其次是thisL,它代表对象的上下文环境,确保方法在调用时的数据准确无误。通过这种参数传递方式,程序可以灵活地根据当前的this上下文读取和处理参数,实现菜单的动态切换和数据的即时更新。
10、无论是前端还是后端,当检索鉴定师的所有订单时,传递的状态参数一直是字符串“ALL”。这种做法缺乏灵活性,并且不符合通常用整型数字表示状态的惯例。因此,增加一个整型的状态值,以便在业务处理时能够更方便地进行参数校验。为了实现更好的统一管理,决定将该状态值变更为0。数值0代表获取所有鉴定记录,即不对状态进行匹配,进而提取与expert相关的所有订单记录。
11、在前端通过xc_exoert_identify_list_order方法读取鉴定类型菜单数据请求时,需要进行以下几项基本验证。首先,系统将通过user和xc两个属性对象来判断用户是否具备管理员权限和鉴定师资质。如果用户不同时具备这两项资格,系统将拦截该请求并进行相应处理。其次,系统会提取page-content.identify_expert_order_list_content元素,并生成一个名为content的作用域变量。在进行后续操作之前,系统将对该变量进行验证,如元素获取失败,则会将该请求视为非法请求。此外,系统还会通过xc.is_login方法验证用户的登录状态,如果用户未登录,系统将强制弹出登录页面以确保操作的安全性和连续性。
12、在鉴定师订单subnavbar菜单中,现新增了一个父级类:$page_name。这个全局唯一的类名主要用于解决多个页面同时存在subnavbar菜单时可能出现的监听异常问题,通过页面标识的方式来处理选择器,从而确保功能的正常运作。此外,subnavbar菜单中的li元素也增加了一个自定义属性【data】,此属性包含了status标识码。在后续的点击事件监听中,可以直接从li对象中提取出该标识码的值,以便于进一步的处理和操作。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复513楼
1、对xc_is_page_open结构方法进行了二次优化。该方法现在支持传递两个变量属性。首先是“name”,这是一个固定且必须的值,用于对每个页面进行唯一标识。其次是“page”,这是一个数组结构参数,为可选内容,默认情况下为空。具体传递的参数由每个页面自行决定。同时,该方法的返回结构体保持不变,依然是标准的数组结构。这种优化提高了方法的灵活性和适应性,更好地满足了不同页面的需求。
2、对xc_is_page_open函数的默认返回值进行了优化处理。在用户访问请求被拒绝或鉴权失败的情况下,除了返回code和msg两个变量参数外,还将额外返回以下内容:1、title:表示被拒绝页面的标题,以便用户明确了解到当前页面访问状态。2、content:描述被拒绝页面的主体内容区域,通常用于提供详细的拒绝原因或后续步骤的简要说明。3、link:指向强制跳转的页面地址,默认为403错误页面,但这个设置并不固定,可以灵活调整,比如将用户重定向至登录页面或注册页面,以促使用户进行认证或注册,从而获得访问权限。
3、对link执行的路径进行必要的调整和处理,目前的执行路径默认设为【403.php】。在路径加载时通过xc_require方法进行处理时,需要特别注意不要在自定义函数内部使用该方法,否则将可能导致异常错误的发生。如果需要跳转至其他页面,只需提供/acocoa/的真实路径。请注意,目前系统仅支持本地服务器路径的访问,对于以域名形式的页面路径访问机制尚不支持,且暂无计划进行支持。
4、xc_is_page_open功能现已支持对identify_expert_order_list页面的访问检测处理。当用户尝试访问鉴定师管理页面时,系统将依次执行以下两步检查:首先,检测用户角色以确定其是否为管理员或超级管理员角色。如果用户满足其中之一,则不会进行访问拦截,系统直接将open标记为true,允许访问。其次,即使用户不是管理员,系统还会调用xc_is_identify_expert方法进一步验证当前用户是否具有鉴定师身份。若验证通过,也将open标记为true,以确保鉴定师可以正常访问相关页面。
5、页面访问拦截器现在具有闭合操作功能,当完成用户的访问鉴权操作后。会在结尾部分对$result['open']进行验证处理。如果等于false,则将result中的code标记为1,msg返回错误【无权进行访问】、如果等于true则将code标记为0,msg返回【拥有访问权限】。然后直接继承result的结果【包括路径指向、标题、正文、等一系列的参数】。进行结果返回处理。
6、目前,xc_is_page_open 方法被临时整合到【ajax_page】页面中,这意味着每次用户访问该页面都会触发此函数的加载。将来,我们计划开发一个单独的脚本库专门用于处理请求验证,以提高整体代码的结构化和可维护性。目前,该方法新增了一个基础验证功能:在对传递的页面名称进行验证时,使用 is_string 和 empty 函数。如果传递的页面名称不存在或者为空,则立即返回错误提示。这种改进有效确保了输入数据的有效性和系统的稳定性。
7、对xc_is_page_open函数的跳转逻辑进行优化,先前版本的实现是通过返回一个标准的数组结构,并根据其中的code值判断用户的访问权限。在用户无权访问的情况下,需调用相应的页面跳转逻辑,以实现页面的强制接管。尽管该方法有效,但操作步骤稍显繁琐。因此,在优化后的方案中,增加了一个验证步骤,在保持原有业务逻辑的基础上,通过内部执行require_once $result['link']; exit();来实现,使得页面跳转和权限控制过程更加简洁流畅。这样一来,系统可以根据用户权限自动判断是拦截跳转还是直接放行,极大地提升了代码的可读性和维护性。
8、服务端的页面访问拦截器已经完成封装,部署方法非常简单。首先,使用require_once加载ajax_page.php,这是每个页面都需要加载的文件,不仅仅是在需要拦截访问事件时才加载。其次,如果页面需要拦截访问事件,只需调用xc_is_page_open($page_name)即可。如果需要传递外部变量,比如GET参数或令牌密钥,可以将这些变量作为数组传递到第二个参数位置。然后,在xc_is_page_open方法中执行相应的页面逻辑,对符合条件的访问进行放行,而对不符合条件的访问进行拦截。
9、考虑到管理员有时需要查看鉴定师的记录,需要提供便捷的访问方式。为此,在【identify_expert_order_list】页面新增一个GET参数(author_id)。当页面被访问时,系统会自动检测该GET参数的存在性。如果该参数存在并且当前用户是管理员,那么页面中的user_id将不再通过xc_is_login读取,而是直接采用GET参数中的值来进行赋值。验证方式的判断逻辑是(xc_is_admin_x() === true && isset($_GET['author_id'])),以确保只有管理员用户能够通过该方式访问鉴定师的订单列表页。这样设计旨在提升后台管理效率,使管理员能够更快速地获取和查看相关信息。
10、在移动APP端,新版页面的头部区域标准结构体已经完成封装,结构如下:1、首先,通过添加注释语句来标明页面名称、页面创建时间、最后更新时间及页面维护员的信息,这样设计是为了便于后续的维护和更新。2、使用require命令加载wp-load.php文件,将页面的核心组件全部集成,以确保功能的完整性和一致性。3、通过xc_is_login函数获取当前用户ID,并将其赋值给user_id变量,为后续的用户相关操作做好准备。4、构建page_name页面标识标量,页面的所有标识处理均通过此参数完成,以保持识别的统一。5、使用require_once加载集成的xc_local_link('ajax_page.php')文件,以实现全局统一的页面访问事件拦截,保障页面交互的可控性。6、根据实际需要加载【xc_is_page_open】访问拦截钩子,以稳定页面的访问逻辑。7、其他自定义区域则根据具体需求执行页面逻辑处理,确保结构的灵活性和扩展性。
11、在鉴定订单列表页面顶部新增了一个菜单选项,菜单内容包括五个鉴定订单状态分类:【所有鉴定订单:all、等待鉴定订单:wait、已完成鉴定订单:ok、已退回鉴定订单:refurn、已关闭鉴定订单:close】。鉴于鉴定订单仅有这五种状态,鉴定师可以通过页面顶部的菜单,方便地筛选和查看不同状态的订单。这样不仅提高了订单管理的效率,还为鉴定师提供了更直观的操作体验。
12、在使用xc_is_page_open方法验证【鉴定师的订单页面】时,该方法会检测页面请求中是否包含author_id参数。如果检测到author_id参数,则会生成第二个page数组,并将author_id作为该数组的元素传递给函数。函数内部负责进行验证操作。具体来说,如果page['author_id']存在,系统会进一步验证此ID对应的用户是否为鉴定师身份。如果此用户不是鉴定师,系统将拦截访问请求并返回相应的错误信息。需要注意的是,author_id的存在意味着管理员正在查看鉴定师的记录,此情况下不应验证user_id的访问权限,而应确认查看操作的用户是否具有鉴定师身份。这一流程确保了管理员可以正常查看鉴定师的记录,而不受一般用户访问限制的影响。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复512楼
1、新增了鉴定师订单页面【identify_expert_list】,其路径为:/module/xc_identify/expert_identify_list.php。通过短代码访问时,路径为:[xc_module type=xc_identify]/expert_identify_list.php。此页面用作鉴定师的订单列表,在此页面上,鉴定师可以查看其所有的鉴定记录,包括已完成和待处理的鉴定记录。页面名称为:“我的鉴定记录”。页面的设计旨在帮助鉴定师更高效地管理其工作进程和任务状态。
2、在identify_expert_list页面中,通过使用xc_local_link机制来实施页面访问的拦截策略。当用户的请求出现异常、环境存在异常或访问频率过高时,系统会自动阻断对该页面的访问。具体的阻断方式包括强制进行人机交互验证或直接进行页面拦截跳转,具体采用哪种方式视拦截处理策略而定。同时,后台系统已设置限制条件,目前该页面仅允许在线用户进行访问。
3、鉴定师订单列表页目前已成功集成了名为xc_order_access的访问拦截器功能,该功能的拦截标识为identify_expert_list。此功能的第二参数默认值为空。当用户尝试访问此页面时,系统首先检查用户的登录状态。若用户未登录,则会直接拦截并阻止其访问。若用户已登录,系统还会进一步核实其身份是否为鉴定师。如果用户并非鉴定师,将被拦截并强制跳转至403错误页面,提示无访问权限。总之,鉴定订单页面仅对具有鉴定师身份的用户开放访问权限。
4、为了实现统一化管理,xc_order_access函数进行了优化拆分。如今,这个函数不再整合集中到全局脚本函数文件中,以减少页面访问开支。相反,它通过ajax_page页面来动态加载。在ajax_page文件中,通过require_once方法引入access.php文件。在access文件中,首先利用function_exists进行检查,确保xc_order_access函数是否已经存在。如果该函数已经存在,则会跳过输出,避免重复执行的问题,提升系统的效率和稳定性。
5、为了进一步优化拦截器机制,页面在加载核心组件之后,将会初始化一个名为page_name的变量,其值对应页面的参数。这样做的主要目的是使ajax_page.php能够获取并继承这个页面属性,从而有效地处理页面的访问行为。同时,page_name现在也被用作页面的标识符,并动态写入到HTML元素的data-page属性中。
6、page页面现在新增了标识类名,便于管理和维护。在原有的特有类名“page”和“no-tabbar”基础上,增设一个动态类名:<?php echo $page_name; ?>。这使得前端在操作页面元素时,可以直接通过组合“page+页面标识”来精确锁定对应元素,而无需再依赖路由功能。需要注意的是,这个新增的页面类名需要在后续逐步适配到以前的所有页面上,以确保整个项目的一致性和可维护性。
7、ajax_page宫论页面访问拦截器,现在已支持【page_name】属性的处理。在进行页面访问时,拦截器会通过检查上级页面是否传递了page_name变量来判断是否进入特定的处理逻辑。如果page_name被有效传递,系统将执行相应的特定操作流程。需要注意的是,目前page_name属性仅在新增页面中才会出现,因此拦截器在大多数情况下仍然遵循现有的处理方法。
8、新增了一种全新的服务端方法:xc_is_page_open($key)。此方法作为xc_order_access的替代品,已被整合到ajax_page拦截器中。通过该方法,可以主动传递页面标识(在新版页面中,可以通过page_name继承获取)。此方法在内部负责验证并处理访问请求的合法性。如果请求不合法,则返回false;若请求合法,则返回true。此设计提升了系统对于页面访问权限的控制与安全性管理。
9、为了进一步优化xc_is_page_open功能,必须充分考虑到页面的复杂性,并设计更健全的错误监听机制,以便在检测到问题时,为用户提供明确的反馈信息。因此,仅仅返回布尔值(true或false)显然不能满足需求。这个方法的返回结构体需要进行调整,采用标准的数组结构将更为合适。新的结构中,code值为0时表示符合访问要求,而code值为1则表示不符合;另外,一个msg字段将用于提供错误的详细信息。
10、xc_is_page_open 方法所传递的参数不再固定为单一的 key 值,而是改为一个 page 数组变量。这一改变使得该方法可以根据不同页面的需求传递不同的数组结构参数,从而实现复杂的页面验证处理。在设置 page 数组变量时,需要依据页面访问机制的不同进行灵活配置。然而,无论任何页面,数组中都必须包含一个固定值:name,即原来的 key 标识,用于表示页面的唯一标识。这是拦截器的核心参数,绝对不可或缺。
11、新版访问拦截监听事件中新增了一个初始变量:open,默认值设置为false。这意味着在默认状态下,用户没有访问权限,系统需要进行拦截事件处理以确保安全性。为此,系统通过xc_is_page_open方法,根据不同的页面类型执行相应的验证逻辑。如果检测到用户符合访问条件,就会将open标记设置为true,从而允许用户正常访问页面。
12、在xc_is_page_open内部,除了初始化【open鉴权变量】参数外,该函数还会预设两个变量的值:【title:访问被拒绝】和【content:你无权访问页面】。如果鉴权过程失败,这两个参数将被用于显示默认信息。当然,开发者也可以选择在代码中针对特定需求动态修改这两个参数的值,以影响跳转页面的标题和正文,否则系统会自动采用这些预设内容进行页面展示。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复511楼
1、鉴定订单回调事件处理:在支付成功并顺利通过基础检测拦截后,系统会自动触发支付回调事件,并执行xc_insert_sql操作,将相关数据写入数据库表中。此过程中,将【user_id:代表鉴定人或付款人、expert:代表卖家或鉴定师、cat:指代藏品的分类标识、time:表示操作发生的时间点、onumber:用于标识的随机唯一编号、type:指明鉴定的场景标识】作为关联参数,生成一条新的记录并写入到xc_identify数据表,以正式完成新的鉴定订单的创建流程
2、写入订单鉴定的时间会处理open字段,该字段的默认值设置为1(公开)。如果订单不公开,则状态标识会更新为2。同时,订单状态status的初始值设置为1(待鉴定),这一调整是为了规范化流程,之前的初始状态为0,显得较为混乱。为确保信息一致性和便于后续处理,这两个字段的修改与更新已整合同步至开发文档中。每次状态的变更都会在开放文档中更新,以便于跟踪审核。
3、在藏品鉴定表中,现已彻底移除order订单字段,不再进行保留处理。鉴定订单现在有两种追踪和锁定的方式。第一种是通过id,也就是数据表的主键ID值。这个值具有唯一性,是主要的单据跟踪方法。第二种方式是通过number字段,即订单编号信息。这一编号是通过uniqid函数生成的随机数,用户在界面上看到的鉴定编号正是这一值。
4、在对藏品信息进行独立封装处理时,首先会初始化一个名为collection的空数组。在插入鉴定订单表之前,该过程开始时会使用empty函数逐一检查是否存在【image、video、textarea】等信息。如果这些信息存在,则将其分别写入到collection数组的相应字段中。完成这一系列的数组封装操作后,在执行xc_insert_sql时,这个封装好的数组将会被存入到数据库中相应的字段中,以确保数据的完整性和结构化存储。
5、在通过 xc_insert_sql 插入鉴定订单后,返回的结果会被赋值给 insert_result。接下来,我们会对这个值进行验证处理。如果返回的值为空,则立即返回错误,并将错误信息写入日志中,以便后续追踪和处理。同时,拒绝后续的执行,以防止异常错误的传播。需要注意的是,在正常情况下,insert_result 会获得一个ID,即插入的主键值。
6、一旦成功获取鉴定订单的插入主键值后,系统会立即触发xc_pay支付订单的回调处理。在此过程中,需要将支付订单表中【shop_order】字段的值更新为获取到的鉴定订单主键ID。同时,将支付订单的场景来源字段【shop_type】设置为“identify”。通过这样的操作,确保支付订单与鉴定订单之间的关联关系得以正确建立。
7、当付款完成后,在触发支付回调业务时,如果涉及鉴定藏品的订单,系统会在插入鉴定订单的过程中捕获本次支付订单的ID主键值,并将其写入到payment字段(支付订单记录)。随后,系统执行插入创建操作,通过这个字段,鉴定表能够反向追踪到对应的付款详情记录,从而实现订单与付款信息的有效关联。
8、缓存清理操作:在成功完成鉴定订单表的写入工作,即【insert_result】有记录返回时,为了避免可能的冲突错误,将主动清理与用户相关的缓存记录【publish_identify:' . md5($user_id)】。这样可以有效预防由于缓存存在而导致的重复付款记录或重复草稿导入的问题。通过这一机制,确保系统运行的稳定性和数据的准确性。
9、新增短信模板ID【1302223:新的藏品鉴定请求】,模板内容为:“{1}您好,您有一条新的鉴定请求等待处理,请及时前往APP处理!”该模板的应用场景是:当用户指定鉴定师进行鉴定并完成付款后,系统会自动向对应的鉴定师发送一条短信提醒,以便对方能够及时处理请求。请注意,该通知通过场景模板触发,且每日发送次数有限制。
10、在后台配置PUSH通知的场景时,将【identify_apply】通知栏目设定为:鉴定订单通知。同时,新增一个公众号模板消息的功能,具体的模板编号设定为:订单处理通知(模板编号:YRpZrq__R2hb0i1vBoJr1n0snvWcyXoLWpkWJBiXtQA)。当用户提交鉴定申请后,如果鉴定师已绑定微信并关注了相关公众号,他们将会收到一条模板消息提醒。需要特别注意的是,该消息通知的发送次数没有上限。
11、藏品鉴定通知系统(identify_apply)现已全面升级,支持通过APP消息、服务号以及站内信三种方式进行通知,进一步提升用户体验。用户在成功支付鉴定藏品订单后,将接收到由"identify鉴定助理"发出的通知。此通知将通过统一的通知接口发送至用户手机,其中在线用户将直接接收来自APP或网页的弹窗消息,这些消息是通过websocket实现的。如果用户处于离线状态,则会通过厂商的离线接口发送APP通知,确保信息的及时传达。同时,所有消息也会在服务号列表中展示,以便用户随时查阅。
12、identify_apply消息通知场景设定了通知上限。短信通知每天最多发送五条,超过五条的提醒将不会再发送,以防止短信包消耗过大。公众号模版消息每日上限为20条,超过此数量的模版消息将不会发送,以防止滥用模版导致举报。邮件通知每天仅发送前十条通知,超过的部分将不再发送。以上参数可以根据具体需求进行自定义调整。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复510楼
1、用户在通过正常渠道发起藏品鉴定时,如果他们主动选择了鉴定师并提交了鉴定请求,该请求的场景标识应被设定为【default:默认请求】。然而,若此请求涉及关联性鉴定,则场景标识需要根据具体情况变更为相应标识,比如tao、bzg等。这样通过不同的场景标识,鉴定请求得以有效进行归档和分类,便于日后的管理和检索。
2、关于status状态标识的处理规划,当用户发起藏品鉴定申请时,订单状态将依据status字段来进行标记。具体状态包括以下几种:【1:待鉴定,表示订单已提交并等待鉴定师进行鉴定;2:超时关闭,指由于用户或系统原因,鉴定流程未能在规定时间内完成,因此订单自动关闭;3:已退回,表示订单被退回到用户处,可能是由于信息不全或其他问题;4:已关闭,表示订单已被管理员或系统操作关闭,无需进一步处理;5:已撤回,指用户主动撤销了鉴定申请,不再进行后续流程;6:已完成,说明鉴定过程已顺利完成并送达结果。请注意,藏品鉴定表只有在完成订单支付后才会生成相关记录,因此不需考虑监听待支付状态的业务流程。
3、在藏品鉴定发布页面【publish_identify】中,新增一个自定义属性type,其默认值为default。该属性用于标识当前的藏品鉴定场景。当用户点击xc_hook_identify_next进行操作时,系统将在现有基础属性的基础上,提取页面的type属性,并将其写入到相应的数组中,随后提交到后端进行处理。
4、服务端在执行xc_identify_next_hook钩子时,现在增加了对type新增属性的识别和处理。在处理完成后,该属性将被写入到token令牌中,以确保后续的业务流程可以捕获并利用这一新的场景标识字段进行进一步的操作。
5、草稿恢复功能中的publish_identify_draft_hook现在已经集成了对type自定义属性的处理。在草稿恢复的过程中,系统会检查令牌中是否包含type属性,如果存在,此属性将被封装到html['type']中,然后返回到前端页面。前端页面在接收到此数据后,会检测是否包含该值,如果包含,则会将页面上的对应参数值进行替换。
6、xc_payment_success_hook支付成功回调钩子用于处理藏品鉴定成功后的业务逻辑。当用户创建藏品鉴定请求并成功完成支付后,系统会进入宫论的统一支付业务逻辑处理模块。此时,支付的标识为固定值“identify”。在支付订单业务完成封装后,系统会通过回调钩子执行相应的业务交互动作,例如通知鉴定师、创建鉴定记录表等。这一过程确保了支付成功后,相关的后续业务能够顺利进行。
7、我们修复了支付过程中藏品鉴定订单的一个严重漏洞,鉴定订单本质上是C2C关系。具体来说,这种关系涉及鉴定师和用户之间的交易。用户发起鉴定请求,并选择一位鉴定师(即卖家),接着支付相关费用。鉴定师在收到鉴定请求后,完成鉴定工作,并最终获取鉴定费。在整个业务流程中,平台则主要负责资金的担保和提供交易技术支持。因此,在构建支付订单时,必须将订单的卖家信息纳入其中,以确保C2C关系的正确绑定。这样一来,平台在进行费用结算时,能够准确地处理和分配交易费用。
8、修复并解决进行草稿恢复的时候,返回错误【Undefined array key "type" in】的问题,该错误是因为草稿恢复过程中新增的【type:鉴定场景】捕获失败,导致的错误。具体原因为token令牌中没有提取到这个属性导致的,目前已排查并解决该问题,现在生成token数组缓存的时候,会正确获取并写入type值。
9、在通过调用add_payment_order_hook构建藏品待支付订单的过程中,系统首先提取identify_token令牌,以便获取鉴定师的详细资料。接着,将鉴定师的UID写入到订单的【seller】字段中。这一步骤确保了在创建待付款订单时,明确地建立起卖家关系,从而实现了鉴定师与用户之间的C2C绑定。这一机制有效地赋予了交易双方明确的角色,使得整个交易流程更加清晰和顺畅。
10、在鉴定支付回调钩子事件中,系统首先通过提权操作访问支付订单表中的【meta】字段。接着,利用 json_decode 函数将该字段内容转换为数组格式。然后,系统使用 get_redis_meta 函数获取 identify_token 令牌,并由此提取出相关参数信息。这些信息包括:$identify['cat'],表示藏品的分类;$identify['type'],表示鉴定的场景;$identify['image'],即藏品的图片列表;$identify['video'],这是一个可选参数,代表藏品的视频地址;$identify['textarea'],用于补充鉴赏描述的信息;以及$identify['user_id'],标识鉴定发起人。通过这些详细的信息提取和处理,系统能够有效管理和追踪每个鉴定支付订单的细节。
11、鉴定支付订单回调处理:在成功从meta获取到token令牌后,系统会对其进行解析,并提取出user_id,即鉴定人身份。接着,将该user_id与当前支付订单的实际付款人进行比对。如果两者不一致,则表明这是一次非法请求。此时,系统会记录错误日志,并拒绝生成鉴定订单。
12、支付订单回调处理:在创建鉴定订单记录前,需要进行最后一次参数核实,以确保所有信息准确无误。首先,检查鉴定师(卖家)的状态是否为可接单状态,如果发现异常,例如状态为暂停或关闭,则立即记录错误信息,并拒绝执行后续操作。其次,核对当前申请的藏品分类是否与鉴定师的专业类目相符,此外,还要确认申请鉴定的藏品分类目前是否开放鉴定服务,最后,审核鉴定收费标准与当前支付订单金额是否匹配,确保支付金额准确无误
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复509楼
1、对于xc_identif数据表的优化重构规划,这是一个专注于藏品鉴定记录的关键表,因此在系统投入运营后,预计会有大量的数据写入需求。首先,功能上需要进行重构设计,以确保系统的灵活性和可维护性。在性能优化方面,重点在于索引设计的完善,以提高查询效率。此外,结合Redis进行缓存部署减轻数据库的负载压力。通过合理的缓存策略,能够显著提升数据读取的响应速度,即使在处理千万级别的数据时,也能确保系统响应迅速,不会出现延迟情况。
2、重构数据表的第一步是对现有的数据表进行备份操作,将整个数据表完整地复制到xc_identif_bat中。这个备份包括了表的结构以及表中所有的数据内容。由于许多业务与鉴定表记录密切相关,在重构过程中,为了处理和兼容大量业务关联问题,备份显得尤为重要。这一措施可以有效防范在重构过程中可能出现的意外情况。如果业务需要进行调整,借助此备份可以快速切换,从而确保系统的稳定性和连续性。
3、在鉴定表中,需要移除以下字段:【text:藏品文字、img:藏品图片、video:藏品视频】。同时,新增一个名为collection的字段,该字段使用VARCHAR类型,最大长度限制为10000字符。用户在提交藏品鉴定时,藏品的相关信息将以JSON格式存储在这个字段中。当需要读取时,再将数据转换为数组并解析处理。由于藏品的基础信息无需单独字段进行索引,因此通过JSON格式存储能够有效提升数据源表的性能。
4、在鉴定记录表中,我们将移除以下字段:【money:鉴定费用、pay_select:付款方式、pay_order:支付单号】。新增一个字段:payment(VARCHAR 64位),用于存储支付订单的单号。支付方式、支付费用等信息,可以通过支付订单号与相关支付表进行关联查询来获取,无需在鉴定记录表中单列这些字段。此前与鉴定师收益相关的统计工作,也可以直接通过支付表进行查询,以确保数据管理的简洁与高效。
5、以下字段将被保留,但需要对字段类型进行调整,以确保索引的支持:1、cat(藏品分类):原来使用中文分类名存储,现在修改为使用key标识,例如“ciqi”代表瓷器。字段类型调整为VARCHAR(20)。2、era(藏品年代):用于鉴定师对藏品年代进行判断,该字段保留的目的是为了实现年代索引查询,字段类型调整为VARCHAR(32)。3、grade(藏品等级):鉴定师对藏品进行等级划分,保留该字段是为了便于分类筛选,因此字段类型调整为VARCHAR(32)。4、value(价格趋势):字段名修改为price,用于描述鉴定师对藏品价格区位的划分。由于该字段后期也需要进行分类筛查,因此单独列出,字段类型调整为VARCHAR(32)。
6、在订单系统中,“鉴品编号”字段的字段类型将调整为VARCHAR(64),不过该字段将被弃用,仅作为与旧系统兼容的保留项。在设计和开发鉴定功能时,不再使用该字段进行任何数据处理。“查询编号”字段将调整为VARCHAR(32),并将取代“订单号”,成为鉴定藏品的唯一对外标识码。在缓存读取等操作场景中,应尽可能通过ID主键来进行,以确保数据处理的效率和一致性。
7、移除字段【opinion:专家回复】。原字段用于存储鉴定师对藏品的点评,但由于鉴定回复的形式可能多样化,例如既有语音回复又有文字回复,同时除了鉴定藏品外,还有可能涉及其它内容字段的补充,因此需要进行调整。采用JSON格式来存储藏品的鉴定回复信息,新增字段identify(设定为text类型,支持长文本),专门用于保存专家对藏品的详细鉴赏信息,以确保系统能够更灵活地处理不同类型的回复内容。
8、title:藏品的标题保持不变,但其字段类型需要从原来的text文本调整为VARCHAR(200)。这个标题将由专业鉴定师撰写,并在鉴定完成后用作藏品的唯一名称。state:此字段名称需更改为status,并不再使用旧版的存储机制,而是调整为int(11)类型。通过不同的数字编号来区分藏品的状态,例如:0表示待鉴定,1表示已退回,2表示已超时等。这样设置不仅优化了数据库的存储性能,还使状态管理更加直观和高效。
9、移除end_time字段是因为在当前系统中,当鉴定师完成鉴定工作后,这个字段会被填写和记录。然而,在实际应用中,我们需要记录多种时间信息,例如鉴定提交时间、退回时间、超时关闭时间以及鉴定完成时间等。单靠一个单独的字段难以满足所有时间记录的需求。此外,还有许多场景的字段信息需要被写入。为了提高数据表的结构灵活性,我们决定新增一个meta(自定义元字段)作为扩展。通过使用JSON的存储方式,这个meta字段将能够灵活地存储多种时间信息和其他相关内容。这种方法不仅可以实现多样化的信息存储,还能使数据库结构在面对未来可能的需求变化时更加灵活和适应。
10、在鉴定师数据表中新增两个组合索引,以提高查询效率。首先是基础信息查询索引(user_id、expert、cat、number),这是因为通过鉴定用户、鉴定专家、藏品分类和鉴定编号进行查找是一个非常频繁的操作,因此加入该索引可以显著提升这些字段的查找响应速度。其次是藏品类型筛选组合索引(cat:藏品分类、era:藏品断代、price:价格趋势、grade:藏品级别),这四个字段常用于类目筛选,所以提前建立索引能够有效加快筛选的处理速度,优化数据表性能。
11、在xc_identify数据表中新增了一个字段:open,该字段用于控制鉴定订单的状态开关。用户可以选择是否将已完成鉴定的藏品订单设为公开状态。如果用户选择关闭该字段,其值为1;若选择开启,则为0。在关闭状态下,鉴定藏品将无法被索引和查找,可以理解为藏品仅用户本人可见。即使他人输入鉴定编号,也无法查阅相关信息。该字段是一个全局开关。需要注意的是,默认情况下,鉴定订单处于公开状态,用户需手动将其设置为关闭。
12、为适应不同鉴定请求方式的多样性,xc_identify新增了一个【type:VARCHAR(20)】的场景字段,以便更好地区别和处理不同的鉴定请求类型,从而在后期实现更高效的归档处理。例如,普通鉴定通常是通过藏品鉴定入口发起的,但用户也可以直接在鉴定师主页上发起鉴定。此外,还计划允许通过淘货功能一键发起真假鉴定。而对于某些不宜公开的鉴定场景,则可以通过该字段实现更加精确的筛选和管理。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复508楼
1、服务端的统一支付钩子:xc_payment_hook,目前已经成功集成了【identify:藏品鉴定】的相关业务流程。当用户进行藏品鉴定时,这个钩子将被调用以发起鉴定费的支付请求。钩子会首先核查用户的环境以及提交的相关参数,确保所有条件都满足后,才会发起支付请求。同时,它会生成一个支付令牌以处理后续的支付事务,确保整个交易过程的安全性和顺利进行。
2、在add_payment_order_hook钩子中增设一个拦截保护机制,用于处理支付订单的来源为鉴定的情况。在这一流程中,将执行以下关键检测:首先,需要验证identify_token令牌的有效性。如果令牌无效,则系统将返回错误提示【订单创建失败:鉴定令牌已过期】。其次,系统将使用xc_is_identify_expert方法判断所选择的鉴定师是否合格,如鉴定师不符要求,则返回提示【订单创建失败:鉴定师不可用】。最后,还需核实订单金额,即鉴赏费用是否与所选鉴定师的收费标准一致。如费用不一致,系统将给出提示【订单创建失败:鉴定费用不一致】。通过以上步骤,确保支付订单的可靠性和准确性。
3、为了确保后续的回调动作能够顺利获取到鉴定藏品所需的提交信息(服务端需要进行支付回调),在使用add_payment_order_hook方法生成订单数据表记录时,会将服务端传递的【identify_token、author_id、amount】这三个参数一并存入meta字段中。后续的业务操作需要使用这些鉴定信息时,只需解析meta字段即可完成提取。这种做法不仅整合了数据存储,还简化了数据获取流程,确保了业务的连续性和数据的完整性。
4、为了优化用户体验,在成功创建待支付的【藏品鉴定】订单后,系统设计了一种令牌延迟机制。此机制的核心目的是防止原有鉴定信息的缓存因为超时而被清理掉。从而在订单生成后,会立即重置令牌的有效期,将其设置为30分钟才会过期。这项措施确保了即便用户延迟付款,也不必担心后续回调失效所带来的麻烦。然而需要注意的是,在极端情况下,可能会因为令牌过期问题,导致订单虽已付款成功但无法创建和生成相应的鉴定订单。
5、修复并解决提交鉴定师申请时,服务端返回如下错误【 Undefined array key "identify_token" in、Undefined array key "author_id" in、 Undefined array key "amount" in】错误的问题。该错误是由于读取变量错误导致的,主要原因是前端传递的是payment对象属性,钩子内部读取需要进行二次解析处理。
6、修复并解决服务端错误返回【 Call to undefined function update_get_redis() 】的问题,在执行缓存动作更新的时候,返回undefined函数不存在的问题。该错误指向函数add_payment_order_hook,在创建生成支付订单的时候,需要更新redis缓存,但是执行方法错误导致出现错误,目前已进行修复处理。
7、支付鉴定订单时,扣款成功后仍旧返回【Undefined variable $shop_order in <b>/ Undefined variable $resul in】这两个异常直接导致页面无法完成回调功能。第一个错误的原因在于:当用户使用余额支付时,系统会触发推送消息通知,构建一个链接以便用户跳转,其中需要包含订单号作为参数。然而,由于之前未正确提取订单号,因而导致此错误出现。第二个错误则涉及余额更新的钩子函数,在这个过程中返回值应该是“result”,但由于变量未定义,所以导致了错误返回。
8、解决在统一支付架构下进行余额支付时始终返回固定错误码【code=1】的问题,该错误是由于xc_update_money_hook的余额更新动作钩子未能正确闭合,进一步分析发现,具体原因在于返回结构体未采用标准化数组格式,导致在消息传递时无法被后续业务正确识别。为此,解决方案:对余额更新钩子的返回方式进行重构,确保返回的数据包符合标准的数组格式。
9、在余额支付过程中,当回调事件被触发时,会返回一个异常错误【require_once(): https:// wrapper is disabled】。这个问题的根本原因是配置中不允许通过 URL 来包含文件 (allow_url_include=0)。也就是说,require_once 引入的路径存在安全隐患,因为使用的是通过短代码生成的网络地址,而并非本地路径。由于系统的安全策略,该操作会被拦截,从而导致支付成功后的回调无法被正常执行。为了解决这一问题,建议调整代码逻辑,确保所有文件引入使用本地路径,避免使用 URL 形式的路径,以提升系统的安全性和稳定性。
10、余额服务号的消息通知得到了优化,之前服务号的站内信消息仅以简单的形式显示【余额支出:30元、余额收入:100元】,无法直接看到余额变动的具体原因,用户必须点击进入聊天对话框才能查看细节。经过调整后,消息的展示方式得到了改进,信息末尾新增了余额变动的原因说明,这样用户即使不进入会话页面,也能够直接看到最近的余额变动原因,从而方便了解每笔支出或收入的详细背景。
11、宫论服务号的消息助理新增了【藏品鉴定助理:identify】这一功能,关联的用户UID为35。服务号的主要职责是发送与藏品鉴定相关的消息通知。目前,该服务号在站内开启了弹窗通知功能,但私信功能暂时关闭。服务号的主要任务包括两个方面:首先,对于鉴定师来说,当收到藏品鉴定请求时,该服务号将会发送相应的消息通知,以便及时处理鉴定工作;其次,对于用户来说,当他们的藏品完成鉴定后,服务号将发送结果通知,让用户了解到鉴定的最新进展与结果。
12、在全局推送通知管理配置组中,新增了一个名为“identify_apply【鉴定师】收到藏品鉴定通知”的场景。当用户发起藏品鉴定请求,并指定了具体的鉴定师且完成付款程序后,鉴定师将受到一系列通知,提醒他们及时处理这些鉴定请求。该消息场景将同时激活以下多种通知方式:短信提醒、邮件提醒、站内信提醒、服务号通知、公众号通知及应用内消息通知。通过这一多渠道通知机制,确保鉴定师能够在第一时间收到信息并作出响应。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复507楼
1、在xc_identify_next页面中,现在已经支持通过myApp.onPageBeforeInit访问事件进行处理。用户每次访问该页面时,都会自动触发内部的事件监听器。当用户点击【xc_identify_next_content li】元素时,系统将自动移除其他所有li元素上的on类,同时为当前被点击的li元素添加on类。
2、当用户选择鉴定师时,不再使用绑定onclick事件的方式来触发底部菜单中鉴赏费用的相关处理,而是改为通过监听li元素的点击行为进行触发。当用户点击鉴定师时,除了在元素上新增on类名,还需要从当前元素的this中提取price价格信息,然后将该价格通过具有lock_money_expert类名的元素输出到指定页面区域。请注意,类名的操作将通过使用$(this)进行处理,以确保DOM操作的正确性与灵活性。
3、鉴定师在进行CSS样式优化时,应注意以下几点:首先,将“on”状态下的背景色由浅灰色更改为白色,此举可以有效避免因背景色覆盖而导致的显示差异问题,使界面更为清晰。其次,在原有样式的基础上,增加外部边框效果,能够明显地凸显选中项,从而提升用户的视觉体验。最后,对于鉴赏费用部分的底部菜单进行精细调整,将margin-bottom设定为-2vw,确保空间布局合理,同时将字体大小设置为4.5vw,以确保文字的清晰易读和整体的视觉和谐美观。
4、在鉴定师选择页面上新增一个名为【提交鉴定申请】的按钮选项。当用户选择了一位鉴定师后,可以通过点击此按钮提交鉴定申请。如果用户未选择鉴定师,系统会提醒并返回错误信息【请先选择一位鉴定师】。用户点击按钮后,系统将从页面中获取所选鉴定师的UID,并与token一起封装。这些信息中,token包含了用户提交的鉴定资料,所有数据将被准备好、待提交至服务端进行参数核验。
5、后台支付场景新增了关于【藏品鉴定费用:identify】的配置。支付场景被简化为“鉴定”,支持的付款方式包括支付宝、微信和余额支付。必须登录后才能使用该服务,因为鉴定必须由用户主动发起,游客无法使用。由于鉴定本质上是一个虚拟订单,因此不需要开启收货地址功能,也不涉及物流环节。而订单备注功能则未开启,鉴赏描述即作为备注信息。若订单在30分钟内未完成支付,将被自动关闭。此外,平台会根据统一标准扣除20%的手续费。目前,场景描述备注暂时为空,不作特别说明。
6、前端支付事件:在支付过程中,事件xc_hook_payment_order已经整合了对【identify:藏品鉴定】功能的支持。当用户试图进行支付时,将触发如下基本拦截流程。首先,系统会利用封装的作用域变量选择器【page-content.xc_identify_next_content】来确认页面内对应元素的存在。如果无法成功锁定该元素,则会直接返回提示,指出这是一次非法的请求。其次,系统将核实用户是否已经在页面中选择了鉴定师。如果用户尚未完成选择,则会弹出提示信息【失败:请选择一个鉴定师】。这一系列的步骤旨在确保支付程序的合法和顺利进行。
7、在选择鉴定师页面中新增了三个自定义属性,以便更好地管理和展示鉴定师相关信息。首先,'token'属性用于接收和存储从上级页面传递过来的鉴定师资料令牌,其中包含了有关鉴定申请的详细材料信息,包括文本和图片内容。其次,'author_id'用于标识鉴定师的唯一用户标识符(UID),确保在鉴定流程中准确识别和关联特定鉴定师。最后,'price'属性代表鉴定师的收费标准,即本次鉴定服务的费用金额。这些自定义属性通过鉴定师监听的点击事件主动获取,通过将鉴定师的UID和价格信息传递到相应的属性中,实现信息的自动更新和准确显示。
8、订单生成钩子:xc_hook_payment_order,在处理藏品鉴定支付订单时,系统通过payment对象提取页面的以下三个关键属性:【identify_token:鉴定资料的令牌、author_id:选定的鉴定师、amount:此次支付的金额】。如果任何一个属性缺失,系统将立即返回提示“参数不完整”。一旦所有参数完整,系统将继续进行服务端的业务处理。
9、修复并解决在发起藏品鉴定订单时出现的【支付参数不完整的问题】。这一问题源于amount价格单位获取异常,需要进行排查和调整。此外,将author_id(鉴定师)的名称变更为seller(收款方,包括卖家、鉴定师、商户或转账收款人),这样有助于更加清晰地识别交易参与方。通过这一命名调整,相关参数可以直接写入支付订单数据库,无需再进行二次解析处理,提高了系统的效率和稳定性。
10、在li鉴定师列表容器中,新增一个自定义属性:name,用于存储鉴定师的姓名或昵称。同时,在xc_identify_next_content中也增加一个自定义属性:title。当用户选择鉴定师时,这一属性将接收到鉴定师的昵称和对应的栏目。具体的展示格式为示例中的【(瓷器鉴定) - 小小乐】。注意,这个标题的生成会通过xc_is_config方法获取藏品的分类名称,并结合所选鉴定师的昵称进行构建。
11、目前,藏品鉴定订单生成事件通过使用作用域变量page_content来提取标题的自定义属性,其中包含鉴定师姓名和鉴定栏目名称。这些信息将作为此次藏品鉴定的支付订单商品标题,并一并录入到订单表中。如此一来,当用户打开支付订单页面时,他们能够清晰直观地看到与支付相关的商品标题,从而提高用户体验和识别度。
12、统一支付页面进行细节优化:1、如果支付备注功能未开启,则页面中将不显示付款说明专栏,从而简化用户界面。2、移除title字段内容。之前默认显示商品标题的title字段已经在商品栏中得到展示,因此显得多余,建议将其去除以避免重复。3、付款截止时间现在将增加div容器边框,这一设计不仅优化了视觉效果,也让用户更清晰地看到关键时间信息。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复506楼
1、xc_identify_next页面现已在后台设置为仅限用户登录状态访问。未登录用户在尝试访问时,前端会自动重定向至登录页面。此外,该页面通过require_once加载了【xc_local_link('ajax_page.php')】,以确保非法请求和高频率访问行为被有效拦截。值得注意的是,该页面集成了阿里云的验证机制,用于验证人机交互的真实性。
2、在处理【xc_identify_next】页面请求时,xc_order_access会主动传递token令牌。拦截钩子负责验证该令牌的合法性,如果令牌不存在或已过期,将会被拦截。此外,系统还会对token返回的内容进行核验,如果token的创建者与当前用户不一致,则视为非法请求。这一机制不仅防止了token令牌的泄露,还能有效阻止未经授权的直接请求。
3、xc_identify_next功能模块包含以下基础拦截行为。首先,进行令牌检测,如果令牌过期或身份不匹配,将进行拦截处理。其次,从令牌中提取分类标识,并使用is方法进行检测,如果该场景不存在,则进行拦截。接着,检查栏目是否启用了鉴定功能,如果未启用,则返回错误信息。最后,通过内置方法获取鉴定师列表,如果获取失败,同样返回错误。
4、获取鉴定师列表的方式不再通过wpdb处理,而是通过xc_is_identify_expert_list方法来实现。该方法支持缓存设计,可以有效减少数据库的压力。由于鉴定行为非常频繁,因此缓存处理尤为重要。鉴定师列表的结果将赋值给expert_list变量,页面上对鉴定师的所有操作都通过该变量进行处理。例如,如果没有鉴定师,页面将显示【当前栏目暂没有鉴定师】。
5、在选择鉴定师页面中,新增了一个父级类名:xc_identify_next_content。所有的交互动作都通过这个父级容器进行元素锁定,以确保不会与其他页面发生冲突。此外,还新增了一个自定义属性【token】。通过GET请求获取到的令牌名称将直接保存到这个属性中。在后续的支付操作中,页面将利用这个属性获取令牌,从而进行鉴权。
6、在鉴定师页面,通过 xc_is_identify_expert_lis 获取可用鉴定师名单时,没有对返回结果的 code 值进行判断处理,导致在 for 循环遍历输出时出现致命错误。具体表现为:如果返回的鉴定师列表为空,系统仍然会返回 code 值。通过 empty 方法判断时,会误判为有内容,但实际上应该是 false。在 for 循环遍历输出时,由于内容为空,会导致大量报错。解决方案是对 code 值进行验证,并对 data 字段进行检查。只有在存在鉴定师返回结果时,data 字段才会返回。
7、在鉴定师选择页面中,当有可用的鉴定师时,系统会展示其详细资料。展示的内容包括【鉴定师头像、昵称、平均用时、认证信息以及收费标准】,这些信息通过列表项(li)方式呈现。在页面的最下方,有一个菜单用于显示当前选择的鉴定师,并提供一个按钮以便用户进行下一步操作。
8、在移动端开发中,我们设计了一种用户主页跳转方法封装:xc_user_home。该方法需要主动传递用户的user_id,并在内部根据用户的身份属性类别进行判断,从而实现不同的页面跳转处理。具体来说,如果用户是鉴定师,则跳转到鉴定师主页;如果用户属于商户,则跳转到商户主页;如果用户是普通用户,则跳转到个人主页。此方法的设计旨在实现统一化处理,便于后续的维护和开发。不同身份的用户将拥有各自独特的主页设计,以满足其特定需求。
9、鉴定师选择页面的CSS样式已经完成,具体样式设计如下:首先,当列表项被选中时(li.on),其边框颜色会变为绿色,同时背景颜色可以选择变为浅灰色。其次,使用.bui-radios-anim类为背景颜色的变化添加过渡效果,使得视觉效果更加流畅。此外,禁用状态的单选按钮背景会变为灰色(#e8e8e8),而选中时中心的圆点则变为浅灰色(#c1c1c1)。最后,通过隐藏默认的input元素,使用.bui-radios类来创建自定义的单选按钮外观。当按钮被选中时,其背景和边框颜色会变为绿色(#00B066),并在中心显示一个白色的圆点,增强用户的交互体验。
10、在鉴定师列表中新增两个自定义属性:首先是user_id,用于标识鉴定师的唯一ID,通过这个属性可以识别当前选择的鉴定师。其次是price,表示鉴定师的收费价格,这个属性将用于前端页面的交互展示。这两个属性需要直接写入到li容器中。此外,还需新增一个状态类名on,用于标识选中的样式。当存在多个鉴定师时,选中的鉴定师和未选中的鉴定师需要有明显的展示区别。
11、在鉴定师选择页面,当成功获取到鉴定师列表后,系统会遍历并输出这些鉴定师的资料,其中,鉴定师的头像通过调用 xc_get_avatar 方法进行读取。这个方法采用了一种缓存设计,能够非常高效地访问并展示鉴定师的相关资料,从而显著减少对数据库的请求次数及压力,提高页面的加载速度和整体用户体验。
12、在可选鉴定师列表中新增了一个独特类别【identify_next_鉴定师user_id】。当用户点击鉴定师昵称时,通过这一类别来锁定该元素,从而执行相应的页面交互。具体操作包括提取鉴定师的收费标准,并在页面底部进行内容更新,同时对选中的列表项(li)进行标记,将其设置为选中状态,以便于用户的后续操作。这一机制确保了用户在选择时能够方便地了解到鉴定师的相关信息,提升了用户的整体交互体验。
Warning: Trying to access array offset on value of type bool in /www/wwwroot/www.acocoa.com/wp-content/module/public/function/acocoa/function/jinsom.php on line 163
拉黑 举报 打赏 回复505楼