2025年9月17日
1、新增方法xinle_is_areas_province，获取省级行政区列表，该函数用于从数据库中获取所有省级行政区的信息，并缓存到 Redis 中以提高性能。返回包含省级行政区信息的数组，如果没有找到数据则返回 false。屏蔽了（台湾、香港、澳门）地区，仅返回内地31个省、自治区、和直辖市。缓存默认设定时间为30天，不能通过常规方式进行刷新。如果发生变动，需要重置函数来刷新缓存。
2、新增方法xinle_is_areas_query，行政区域匹配查询，通过提供的区域标识符（可能是ID、城市名称或行政代码）来获取对应的下级单位列表。该函数会首先检查Redis缓存，如果命中缓存则直接返回结果。否则，会查询数据库来获取下级单位信息，并将结果缓存30天。$area_code 行政区域标识符，可以是ID、城市名称或行政代码。返回下级单位的数组列表，如果没有找到则返回false。jin'h
3、xinle_is_areas_query的执行流程如下：构建Redis缓存键：函数首先根据提供的区域标识符（$area_code）构建一个Redis缓存键。检查Redis缓存：利用构建的缓存键检查Redis中是否已有对应的缓存数据。如果缓存命中，则直接返回缓存结果，避免数据库查询。数据库查询准备：如果Redis中没有缓存命中，函数会继续执行数据库查询。首先，通过全局变量$wpdb获取表名，该表名由WordPress数据库前缀和xinle_areas组合而成。根据标识符类型查询：ID查询：如果提供的$area_code是一个大于999999的数字，函数假设这是一个ID，并尝试通过xinle_query_sql函数在数据库中查询对应的area_code。如果没有找到对应的area_code，函数返回false。名称查询：如果提供的$area_code是全中文字符，函数假设这是一个名称，并在数据库中查找对应的area_code（仅在省、市、区县级别中查找）。如果没有找到，函数返回false。查询下级单位：一旦获得有效的area_code，函数在数据库中查询所有parent_code等于该area_code的记录，获取对应的下级单位列表。结果处理：如果没有找到下级单位，函数返回false。否则，将查询结果缓存到Redis中，缓存时间为30天（86400秒×30）。返回结果：最后，函数返回下级单位的数组列表。
4、新增页面：address_update，这是一个用于修改或新建收货地址的页面。用户在需要更新或添加新地址时，可以通过该页面进行操作。页面的组件路径为：mobile/settings/address_update.html。在这个页面上，用户将看到几个表单选项，包括：姓名、手机号、地区以及详细地址。这些选项旨在收集必要的信息，以便准确地记录和管理用户的收货地址。
5、当用户进入address_update页面时，会触发一个初始化请求：address_update_initialization。该请求会向服务端发送，以获取相关的数据信息。请求中会携带一个ID，这是因为页面既支持地址的修改也支持新建。如果是修改地址的情况，页面进入时会传递一个ID；如果没有ID，则意味着用户正在新建一个地址。如果传递了ID，这个ID代表当前用户地址的序号，系统会通过这个序号提取用户希望修改的地址信息，从而读取并展示对应的详细收货地址参数。
6、当后端收到地址修改页面的初始化请求时，将执行以下处理步骤：首先，通过empty函数检查用户的登录状态。如果用户未登录，系统将返回错误提示，并通过jump方法强制跳转到登录页面，以确保用户在登录状态下进行操作。接着，系统调用xinle_is_areas_province方法获取直辖市、自治区和省的列表。随后，通过for循环遍历这些数据，构建province_htm用于生成选项卡列表。在生成选项卡 时，会将每个省份的主键ID写入当前选项的自定义属性data-id中，以便后续通过该ID进行身份识别和处理。完成province_htm的构建后，将直接返回code和province_htm到前端响应。这是初始化建立新地址的处理，如果是修改地址则逻辑不同。
7、前端页面在完成初始化请求后，接收到province_htm数据，并将其同步添加到xinle_address_province元素的末尾，完成省份选项卡的生成。与此同时，通过pageInit方法设置一个监听器：当xinle_address_province元素发生change选择事件时，监听器将被触发，以执行相应的业务逻辑。如果用户选择了某个省份，该动作将触发一个新的后端请求，以获取并返回该省份对应的城市列表。
执行对应的业务逻辑。如果用户选择了省份，就会触发另外的后端请求，来返回对应省的城市列表。qizh将主键ID写入到当前选项的自定义属性data-id中，后续将通过ID进行身份识别处理。将IDgf省处理修改地址，则会进入页面的时候传递ID过来，如果没有ID则说明是新建。如果有ID则是当前用户的地址序号，通过序号获取用户要修改的地址。从而读取对应的详细收货地址信息参数。dui'yixsh'hxchu's如果用户需要修改或者新建收货地址，则需要通过这个页面来发起。页面组件地址为：mobile/settings/address_update.html。该页面提供几个表单选项：1、姓名、手机号、地区、详细地址。huo该页面update_来源国家行政区域，截止时间为2024年。关联LV每个cun'zhe、
8、为了提升用户体验，决定对地区选择功能进行重构，以解决页面中可能出现的过多选项卡问题。新的设计方案采用标准的弹出层，使用户能够更方便地进行选择操作。默认情况下，弹出层会展示所有省份的列表，当用户点击某个省份时，界面会自动切换到相应的城市选择界面。完成城市选择后，系统将进一步引导用户进入区县选择界面。通过这种集中在一个弹出层内的设计，用户可以顺畅地完成收货地址的选择过程。弹出层的构建使用$f7.popup.open方法，而tab切换则通过tab-link进行封装处理。
9、对address_update的初始化请求进行了重构。尽管仍通过xinle_is_areas_province来获取所有直辖市、省、自治区的列表，但返回的结构不再是选项卡类型，而是标准的tab列表结构。每一个返回的li元素都会加入list_areas_' . $province_data['id'] . '作为父级类名，以便后期可以通过ID直接定位到元素。在完成后端的数据响应返回后，省份tab结构将直接写入到对应的弹出层级中。这样用户在打开弹出层的时候，会自动完成初始化的处理
10、为提高定位的精准性，用户收货地址的位置的区域选择将从原本的省市区变更为省市区/街道乡镇。区县的跨度较大，尤其是乡镇部分，因此在处理第三方快递接口平台对接时，也需要提供乡镇街道以进行揽收查询处理。目前，xinle_areas数据表拥有七十万多条数据，能够完美覆盖所有乡镇，因此对底层设计进行了重构，以确保满足这一需求。
11、页面新增了四个变量用于控制tab内容的输出处理：selectedProvince（省份选项卡）、selectedCity（城市选项卡）、selectedArea（区县选项卡）以及selectedStreet（街道选项卡）。在进行tab切换时，这四个变量将用于动态控制内容的输出。当用户选择了某个省份后，系统会自动重置城市、区县和街道选项卡的内容；同样，当选择了城市时，区县和街道的选项卡内容也会被重置。通过这种机制，确保用户在完成上级位置选择后，系统能够自动更新和重置下级选项卡的内容，从而提高用户的操作效率和体验流畅度。

2025年9月16日
1、后端新增了一个名为xinle_is_admin_x的方法，用于验证指定用户是否具备前台管理员权限。该方法通过读取xinle_user_admin_x_config配置，来判断用户是否在配置列表中。如果用户在列表中，方法将返回true，表示该用户是前台管理员；如果不在，则返回false。此外，超级管理员默认被视为前台管理员，因而始终返回true。值得注意的是，前台管理员的设置并未通过自定义字段来实现，这样的设计是为了便于后期的维护管理，后台可以灵活地控制管理员名单的成员。此方法不支持缓存特性，确保了实时更新的准确性。一旦某用户的前台管理员权限被撤销，系统将立即反映这一变化，用户将无法继续使用相关权限。
2、在用户资料缓存方法中，xinle_is_profile 现在新增了一个字段 is_admin_x，该字段是一个布尔值，用于标识用户是否为前台管理员。如果对准确性要求不高，可以直接使用此方法返回的字段来判断用户的管理员身份。在前端页面中，也可以通过 user.is_admin_x 进行快速验证，以便在用户界面上显示相应的管理员权限或功能。但需注意的是，出于安全考虑，前端的判断仅供参考，所有涉及权限的验证和重要操作必须在后端进行处理，以确保系统的安全性和数据的完整性。
3、新增了一个头像头像短代码 [xinle_user_avatar user_id="2" size="80"]，通过传递用户的UID和头像的宽高值（size），可以轻松生成对应的HTML模板。这一短代码的设计初衷是用于首页顶部的导航菜单，便于动态展示用户的头像信息。值得一提的是，当用户未登录时，可以将 user_id 设置为空或0，系统会自动处理并返回一个默认头像的HTML模板。这一机制确保了页面的完整性和一致性，无论用户是否登录，导航菜单始终保持美观和功能齐全。
4、xinle_user_avatar_shortcodes函数负责输出用户头像的短代码，其支持的逻辑如下：首先，该函数从传入的短代码属性中读取用户ID (user_id) 和头像大小 (size)。如果未提供 user_id，则默认为空字符串；头像大小默认设置为80。接下来，函数判断用户ID是否为空。如果 user_id 为空，这意味着没有指定用户，函数将返回一个默认头像的 <img> 标签，以显示未登录状态的用户。此默认头像的URL通过 xinle_get_option('xinle_security_login_avatar_default') 获取。若提供了 user_id，函数将调用 xinle_is_profile($user_id) 来获取该用户的头像URL、昵称及认证信息等详细资料。然后，使用获取到的用户头像URL和昵称，函数生成一个包含用户头像的 <img> 标签，并附加用户的认证HTML标识。最终，该函数返回生成的头像HTML内容，以便在页面上进行显示。
5、在构建APP视图过程中，在导航栏的自定义区域巧妙地运用了do_shortcode来处理短代码。这种方法不仅大大提升了系统的扩展性，还为构建复杂元素提供了强有力的支持。通过在脚本库中预先设置好相应的短代码（并确保其安全性），开发者可以在自定义区域中轻松地通过短代码实现各种功能输出。无论是链接、文本、图片还是其他交互事件，这种集成方式都能够有效处理，确保应用功能的多样性和灵活性。这种设计理念不仅让应用开发更加灵活高效，同时也为用户提供了丰富多样的互动体验，使应用更具吸引力和用户友好性。
6、在获取用户资料时，如果需要展示用户头像，会调用xinle_is_thumbnail方法为头像添加样式。这种方式不仅能避免直接显示原图，从而有效降低流量开支，还能确保头像以适当的尺寸展示。由于用户头像的显示通常较小，返回样式化的缩略图已经足够。在大多数情况下，用户头衔信息是通过xinle_is_profile方法读取缓存的，因此在这个环节进行样式追加，不仅能实现全局覆盖，还能确保头像展示的一致性和资源的高效利用。
7、在用户昵称更新时，通过 xinle_update_user_meta_hook 触发清理缓存的机制。此前，该机制仅在常规字段如手机号码（phone）、微信ID（weixin_uid）、头像URL（avatar_url）、VIP到期时间（vip_time）等更新时才会触发。然而，用户昵称的变化同样会直接影响前端显示内容，因此现已将昵称更新纳入触发范围。此调整确保用户昵称变动后，系统能够及时全局同步更新用户缓存，保证前端展示的准确性和即时性。注：只要涉及到xinle_is_profile自定义用户字段的输出处理，都需要对字段进行缓存自动刷新的处理，确保返回数据的一致性。因为xinle_is_profile本身不具备缓存自动清理功能了，需要系统主动刷新。
8、考虑到前端在加载用户头像图片的时候，可能因为网络的缘故加载出现比较慢甚至失败的情况，这个时候前端会出现裂图现象，非常的不美观，因此决定利用background加一个默认背景头像，在头像未完成初始化动作前，系统将通过这个背景图来展示用户的头像。该图片通过后台进行读取，默认头像也进行优化处理，整体大小7KB非常的小，可以确保页面加载前就完成头像的初始化加载行为。
9、新增页面【mobile/settings/address_list.html】收货地址列表页，该页面采用标准APP结构进行构造。用于展示用户的收货地址列表，计划在该页面内支持，添加地址、修改地址、删除地址、复制地址、变更默认地址等选项操作。页面的唯一标识：address_list，支持APP页面选择判断逻辑，允许通过user.page_name来记录页面的位置。
10、新增数据表“xinle_areas”以存储中华人民共和国的行政区域信息。该表包括多个字段，具体如下：level表示行政区域的层级，parent_code为父级行政代码，用以表示上级区域的关联；area_code是当前区域的行政代码，zip_code为对应的邮政编码，而city_code则是区域的电话区号。name字段记录区域的全称，short_name则为其简称，merger_name则是用于展示完整的区域组合名称。pinyin字段提供了区域名称的拼音拼写，方便语音识别和搜索；最后，lng和lat分别记录了区域的经度和纬度信息，支持地理位置的精确定位。这个数据表的建立，将为进一步的数据管理和区域信息查询提供有力支持。
11、经过不懈努力，xinle_areas数据表的采集工作已经圆满完成，成功收录了七十万条详细数据。这些数据全面涵盖了从省、市、区到乡镇、村委的五级行政单位，确保了信息的完整性和准确性。每个区域根据其行政级别被细分为不同的level层级：1级代表省或直辖市，2级为地级市，3级对应县区，4级为城镇，5级则是村委。每个区域不仅拥有独特的行政代码，还关联了其父级行政区域的代码，使得通过层级和父级行政代码可以轻松判断上级所属地。这种结构化的数据设计大大便利了省市区的关联查询处理。所有数据均来源于国家行政区域信息，并且截止时间为2024年，确保了其权威性和时效性，为未来的行政区域数据处理和应用奠定了坚实的基础。

2025年9月15日
1、前端新增了一个重要优化功能，即在xinle对象中新增了属性“xinle.shop_details_thumbnail”，用于定义商品默认缩略图样式。后面APP商品详情页中，所有的商品图片将自动应用这一样式，从而有效避免直接输出原图所带来的高流量消耗问题。集成到对象中，可以通过前端进行读取和调用。部分商品数据是通过前端进行旋绕的，因此需要用这个对象属性来添加样式规格。这一改进不仅显著提升了页面加载速度，还能优化用户的浏览体验，同时降低了服务器资源的使用成本，体现了性能优化与用户体验之间的平衡。
2、在APP项目中，现在将通过handleMessage监听扫一扫请求，如果websocket发送了通讯请求过来，并且对应的扫描请求标识为：QR-Code。那么可以判断本次执行请求的是扫码行为，此时APP会通过uni.requireNativePlugin加载扫码SDK，并将对象保存到mpaasScanModule。在完成SDK的封装处理后，系统会执行mpaasScan来启动扫码组件，进行扫码操作。注：不管什么场景的扫码都是通过这个事件来发起，至于扫码返回的结果，则通过后续的事件进行触发执行。
3、新增xinle_plus_app事件：该函数用于在网页环境中向APP发送通讯事件，只有在APP环境中才能执行成功。如果当前环境不是APP，则会提示用户该操作仅支持在APP环境中进行，并返回false。若传入的数据为空，则默认发送类型为'test'的事件。参数{Object} data是要发送给APP的数据对象，必须包含事件类型。操作成功时返回true；如果不在APP环境中，则返回false。通讯请求，会使用xinle_is_plus来验证是否完成了plus加载行为。如果加载失败则会直接返回false。注：通过UA来判断容易发生伪装，并不可靠。通过PLUS初始化可以确保APP环境是可靠的。因为绝大部分的事件本身就依赖PLUS来执行。
4、APP项目中新增了一个内置通讯事件：app_h5，该事件用于将APP中的数据转发给webviews进行处理。主要执行流程如下：首先获取当前页面的AppWebview对象（该操作仅在App端有效），接着获取Webview的第一个子Webview（适用于页面存在多层Webview嵌套的情况）。在Webview中执行一段JavaScript代码，由原生层执行并传递参数。为了防止数据中包含特殊字符导致JavaScript语法错误，需将data对象序列化为字符串，并进行URL编码。在执行通讯请求前，会对需要处理的字符串进行格式化处理，避免因为传递参数过于复杂，导致传参异常。
5、新增xinle_hook_app_evaljs事件：用于APP与webviews的通讯。当APP需要发送消息给webviews页面中时，会通过app_h5来触发通讯处理，最终消息会转发到这个钩子进行处理。一些底层原生SDK的处理（不支持PLUS）动作，将通过xinle_hook_app_evaljs来进行交互处理。这种交互是实时的，通讯过程中的数据处理，也是通过对象传参。注：这是APP与前端的唯一通讯接口，后续会集成一个token令牌，来确保双方通讯的安全可靠性。APP中转发过来的交互数据，都需要通过内部解码处理再进行对应的业务逻辑。
6、新增了scan.js脚本，专门用于处理与扫码相关的核心逻辑。该脚本设计旨在实现统一的扫码功能处理，并为后续的功能扩展提供便利。未来将支持多种扫码场景的集成，包括APP扫一扫、微信扫一扫、小程序扫一扫以及PDA设备扫码等，覆盖多个业务需求场景。具体应用包括单据识别、证书识别、发货识别、验收识别等一系列操作。所有与扫码相关的事件均通过该脚本进行集中调用和执行，从而实现统一管理和处理逻辑。该脚本的核心思路是将摄像头扫码识别的结果统一转发到scan.js进行处理，无论来源是APP、微信、小程序或其他设备，都能够通过脚本完成后续的数据解析和业务处理。
7、新增了一个名为xinle_hook_scan_result的方法，专门用于处理扫码结果的业务逻辑。该方法接收一个包含了多个属性的data对象，其中包括了关键的code属性，代表扫码的结果。方法会通过user.page_name来获取当前页面的名称，并根据这个页面名称以及扫码结果code，来执行相应的业务逻辑处理。这一设计确保了扫码结果能在不同的页面环境下被正确地解析和应用，提升了系统处理扫码事件的灵活性和准确性。
8、在处理加载请求的过程中，xinle_infinite_hook会对与扫码相关的参数进行精准的校验和处理。首先，系统会检测scan_click对象是否包含自定义属性code。如果该属性被检测到，系统将构建一个名为infinite.scan的参数，用于将扫码结果传递到后端进行进一步处理。与此同时，为了避免在后续搜索操作中出现因残留数据导致的错误或冲突，系统会立即清空scan_click的自定义属性。后端接收到infinite.scan参数后，会使用内置的方法对其进行严格验证，以确保扫码结果符合预定的验证标准。
9、已修复苹果APP中出现的“初始化PLUS内部钩子失败”这一异常问题。此错误直接影响了几个核心功能的加载，包括一键登录、支付通道和开屏管理机制。在APP启动阶段，通常会在PLUS加载成功后，立即触发xc_hook_app_plus以进行初始化。然而，由于执行优先级的问题，HOOK的回调失败导致无法找到执行方法，从而引发了整个异常。为了彻底解决这一问题，将调整执行优先级，确保钩子能够正确回调，并顺利完成初始化过程，以保障核心功能的正常运行。
10、苹果APP的底层基座已成功升级至V1.60版本，此次更新涵盖了所有扩展SDK的最新版本，包括微信登录、APP一键登录、分享组件以及相册功能等底层接口的全面更新。此次版本升级的核心亮点在于为iOS设备引入了全新的扫一扫组件。用户现在可以通过页面控件便捷地调用这一功能，享受与安卓设备相同的高效识别和解析机制。这一改进不仅显著提升了用户体验，还确保了跨平台功能的一致性，确保苹果手机用户在使用扫一扫功能时能够获得同样高效和准确的结果。此外，未来扫一扫组件还计划集成小程序扫一扫功能，为用户带来更加丰富的使用场景和便捷的操作体验。
11、新增字段xinle_user_admin_x_config：该字段用于存储前台管理员名单。通常情况下，前台管理员权限是分配给员工账户，员工可以通过此权限执行一些基础的管理操作。然而，为了确保系统安全性，在员工离职后，必须及时将其账户从配置组中移除，避免可能出现的安全隐患。需要注意的是，前台管理员与超级管理员的权限范围存在显著差异：前台管理员仅限于操作APP页面相关的行为，而无法访问后台管理系统。同时，为了进一步强化资金安全管理，前台管理员的权限也被严格限制，禁止涉及资金处理的相关操作。

最低多少钱？最低多少钱？

测试看看最低多少钱？

内容测试出