-
Posts
41 -
Joined
-
Last visited
About Code Name Jessica
- Currently Viewing Forum: Beta Discussion
Contact Methods
- Website URL
Profile Information
-
Gender
Female
-
Location
Ohio
Recent Profile Visitors
153 profile views
Code Name Jessica's Achievements
-
No, when I said Re-add, I meant that in version 5b10, I would delete the prefix word in this case 'PCI' then re-add 'PCI' back into the word list. and it would work correctly. So, as I explained in the first post, I added in this order: PCI PCIe PCI-DSS PCI-X and it showed PCI over-riding each of them, then I deleted PCI and re-added it to the list. Everything worked correctly. So, for another example, I thought I would try to do it this way: TEST-TOPIC TEST-TOPIC-WORD It's the Hyphen, that is what is screwing it up I tested with TEST, TESTS, TESTED, and TESTING and it works as it should, but if there is a hyphen like this... TEST-TOPIC-WORD, should have the title="THIS IS A TEST-TOPIC-WORD TEST" but it has "THIS IS A TEST-TOPIC TEST" (also ignore the data-original-title="", it also has title="", just didn't capture that part of the screen).
-
Description of the Bug: The Word Expansion feature in Invision Board Community v5 Beta 10 exhibits incorrect matching behavior when multiple word expansions share similar prefixes. The issue arises when word expansions such as: PCI PCIe PCI-DSS PCI-X are added to the Word Expansion list. The system does not differentiate between these variations correctly and applies expansions incorrectly when terms with similar prefixes are used in posts or comments. Steps to Reproduce: Navigate to the Admin Control Panel (ACP). Go to System > Settings > Posting & Editor > Word Expansions. Add the following word expansions: PCI PCIe PCI-DSS PCI-X Save the changes. Create a new forum post or comment with the text: "This server is PCI-DSS compliant and uses a PCIe SSD, a PCI network card and a PCI-X raid card." Observe the applied word expansions in the post. Expected Behavior: Each word expansion should apply only to the exact matching term in the text. For example: PCI should expand only when the standalone term "PCI" is used. PCIe should expand only when the term "PCIe" is used. PCI-DSS should expand only when the term "PCI-DSS" is used. PCI-X should expand only when the term "PCI-X" is used. Actual Behavior: The word expansion logic applies expansions inconsistently. For example: "PCIe" triggers the "PCIe" expansion. "PCI-DSS" triggers "PCI" expansions. "PCI-X" triggers the "PCI" expansion. "PCI" triggers the "PCI" expansion. This incorrect matching behavior causes confusion and unintended text replacements. Impact: Users experience incorrect text replacements in their forum posts. This can lead to confusion, especially in technical forums where precise terminology is crucial. It diminishes the usability of the Word Expansion feature. Suggested Fix: Update the Word Expansion matching algorithm to ensure it matches whole words or specific phrases accurately. Implement a stricter matching mechanism that differentiates between exact terms and terms with similar prefixes. Environment: Platform: Linux (Ubuntu 24.04) Web Server: nGinX PHP Version: 8.2 Database: MySQL 8.0 Browser: Microsoft Edge Attachments: Bug Report Update Title: [Beta 10] Word Expansion Matching (Additional Findings) Description: Following my initial bug report regarding the Word Expansion feature in IC v5 Beta 10, I have discovered that deleting and re-adding the affected word expansion "PCI" temporarily resolves the issue. Once re-added, the system correctly matches each term, such as "PCI", "PCIe", "PCI-DSS", and "PCI-X", without triggering incorrect expansions. This behavior suggests a potential issue with how word expansions are initially cached or indexed. Steps to Verify Fix: Delete the "PCI" expansion from the Word Expansion list. Re-add "PCI" with the same settings. Retest by editing the forum post created with the terms specified. Observe that the system now matches each term correctly. Impact: While this workaround solves the issue temporarily, it may confuse users who are unaware of the need to manually reset word expansions. Suggested Fix: I have no idea... Didn't look 🙂 Reported by: Jessica Date: January 12, 2025
-
Bug Report Update Title: {Bug} IC v5 Beta 10 - Word Expansion Matching (Additional Findings) Description: Following my initial bug report regarding the Word Expansion feature in IC v5 Beta 10, I have discovered that deleting and re-adding the affected word expansion "PCI" temporarily resolves the issue. Once re-added, the system correctly matches each term, such as "PCI", "PCIe", "PCI-DSS", and "PCI-X", without triggering incorrect expansions. This behavior suggests a potential issue with how word expansions are initially cached or indexed. Steps to Verify Fix: Delete the "PCI" expansion from the Word Expansion list. Re-add "PCI" with the same settings. Retest by editing the forum post created with the terms specified. Observe that the system now matches each term correctly. Impact: While this workaround solves the issue temporarily, it may confuse users who are unaware of the need to manually reset word expansions. Suggested Fix: I have no idea... Didn't look 🙂 Reported by: Jessica Date: January 12, 2025 (Sorry just saw the Bug tracker...) - I can move (well create a new one) in there if you like.
-
Description of the Bug: The Word Expansion feature in Invision Board Community v5 Beta 10 exhibits incorrect matching behavior when multiple word expansions share similar prefixes. The issue arises when word expansions such as: PCI PCIe PCI-DSS PCI-X are added to the Word Expansion list. The system does not differentiate between these variations correctly and applies expansions incorrectly when terms with similar prefixes are used in posts or comments. Steps to Reproduce: Navigate to the Admin Control Panel (ACP). Go to System > Settings > Posting & Editor > Word Expansions. Add the following word expansions: PCI PCIe PCI-DSS PCI-X Save the changes. Create a new forum post or comment with the text: "This server is PCI-DSS compliant and uses a PCIe SSD, a PCI network card and a PCI-X raid card." Observe the applied word expansions in the post. Expected Behavior: Each word expansion should apply only to the exact matching term in the text. For example: PCI should expand only when the standalone term "PCI" is used. PCIe should expand only when the term "PCIe" is used. PCI-DSS should expand only when the term "PCI-DSS" is used. PCI-X should expand only when the term "PCI-X" is used. Actual Behavior: The word expansion logic applies expansions inconsistently. For example: "PCIe" triggers the "PCIe" expansion. "PCI-DSS" triggers "PCI" expansions. "PCI-X" triggers the "PCI" expansion. "PCI" triggers the "PCI" expansion. This incorrect matching behavior causes confusion and unintended text replacements. Impact: Users experience incorrect text replacements in their forum posts. This can lead to confusion, especially in technical forums where precise terminology is crucial. It diminishes the usability of the Word Expansion feature. Suggested Fix: Update the Word Expansion matching algorithm to ensure it matches whole words or specific phrases accurately. Implement a stricter matching mechanism that differentiates between exact terms and terms with similar prefixes. Environment: Platform: Linux (Ubuntu 24.04) Web Server: nGinX PHP Version: 8.2 Database: MySQL 8.0 Browser: Microsoft Edge Attachments:
-
Yeah, I am not one of the developers, I completely understand, that is frustrating when the ACP says no limit, but it is limited in SQL. Curious... I am in the middle of an application currently, but I am wondering if... Let me think about this, maybe another application can be made to create a new table for images, videos, large files, etc. Then call that when uploading or viewing that in community. Let me finish my current project, and I will get back to you if I create something like that.
-
I wanted to prove what I was saying, but when I: SHOW COLUMNS FROM core_attachments; +--------------------------+--------------------------------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------------------------+--------------------------------------+------+-----+---------+----------------+ | attach_id | int(11) | NO | PRI | NULL | auto_increment | | attach_ext | varchar(250) | NO | | | | | attach_file | varchar(250) | NO | | | | | attach_location | varchar(250) | NO | MUL | | | | attach_thumb_location | varchar(250) | NO | MUL | | | | attach_thumb_width | smallint(6) | NO | | 0 | | | attach_thumb_height | smallint(6) | NO | | 0 | | | attach_is_image | tinyint(4) | NO | | 0 | | | attach_hits | int(11) | NO | | 0 | | | attach_date | int(11) | NO | | 0 | | | attach_post_key | varchar(32) | NO | MUL | 0 | | | attach_member_id | bigint(20) unsigned | NO | MUL | 0 | | | attach_filesize | int(11) | NO | | 0 | | | attach_img_width | int(11) | NO | | 0 | | | attach_img_height | int(11) | NO | | 0 | | | attach_is_archived | int(11) | NO | | 0 | | | attach_moderation_status | enum('skipped','approved','pending') | NO | | skipped | | | attach_security_key | varchar(255) | YES | | NULL | | | attach_labels | text | YES | | NULL | | | attach_img_rotate | smallint(6) | YES | | 0 | | +--------------------------+--------------------------------------+------+-----+---------+----------------+ attach_filesize is still int(11). That has the 2GB limit... Let me dig into this a little more
-
In IC4, the file size limit was constrained by the int(11) field in the database, which has a maximum value of 2,147,483,647 bytes (~2GB). This is because the int type is a 32-bit signed integer. In IC5, Invision upgraded the relevant database fields to bigint(20), allowing for a maximum file size of 9,223,372,036,854,775,807 bytes (~8EB). This change means the file size limit on the database side is no longer a bottleneck. (At least that is what I understand)
-
Lindy reacted to a post in a topic: Setting up use of Invision Community API with Nginx
-
Yeah. I turned them off. To answer this question, that would probably be too hard to explain what goes through my mind. Honestly, I have no idea, I created a script with several base words: ("programming", "system admin", "development", "scripting", "cli", etc...). Then I added action words: ("help", "pay", "question", etc) and finally I added assist words: ("guide", "tips", "document", etc) This script would then concat each of these into: programming programming help programming guide programming help guide This caused an output of 1800 words: Here are a few base words, then imagine adding each of the action and assist words (which there are about 20 action, and 12 or so assist): academic administrative ai android app application arch automation backup & recovery bash best practices blog c c# c++ career cd/ci centos certification challenge cloud cloud administration coding community comparisons compliance containers cotd css cybersecurity data science database debian deployment development devops discussion distribution distro embedded enterprise fonts forensics frameworks game development gem general discussion girls who code go governance gui hardware hiring html iac incident incident response infrastructure ios iot iot iot help iot requirements java javascript job job board julia kali kotlin kubuntu linux linux servers lounge machine learning macos matlab meet and greet mentorship mint mobile mobile development mobileos monitoring networking nosql open source opensuse operating systems optimization pen test penetration testing performance perl php pipeline plan9 popos powershell professional professional development programming python pytorch r rails response retro reviews rhel rocky ruby scala scalability scripting security server administration software sql sql sql help sql requirements support suse swift system/low-level tensorflow threat threat intelligence tips tools training trends troubleshooting ubuntu unity unix unreal virtualization vm vulnerability web development windows windows server women in technology I guess my overall thought was if they had the forum in list view, they could filter by tag words. (Just thought of that when I went looking)
-
Code Name Jessica reacted to a post in a topic: Q&A Mode?
-
konon reacted to a post in a topic: [Suggestion] Floating Author Column
-
konon reacted to a post in a topic: [Suggestion] Floating Author Column
-
MythonPonty reacted to a post in a topic: [Suggestion] Floating Author Column
-
EliasM reacted to a post in a topic: [Suggestion] Floating Author Column
-
You can use JavaScript to achieve this by calling: this.getElement().findOne('whatever-the-class-is'); With this approach, you can add, remove, or modify the element as needed. Alternatively, you can locate the relevant CSS and include it in your custom.css file. Here are the pros and cons of each approach: JavaScript: Pros: No need to alter the underlying code, making it easy to implement. Cons: If the id or class changes in future updates, the script will no longer work. CSS: Pros: Minimal editing required, and changes will persist even if your template updates. Cons: Similar to JavaScript, if the id or class changes, your modifications will stop working. Each method has its strengths and weaknesses, so choose based on your specific requirements and how likely it is for the element to change in future updates.
-
Yeah, you are correct. Honestly... I think it could be extremely simple. Import/Export probably CSV would be the most understandable for most people. But I think there should be something a little more. So, let's say I have 1872 tags in a csv. I need to change 1 of them, or just add 1, I can edit the spreadsheet, make my changes, and reupload. That way I don't have to have a series of different csv.
-
Someone messaged me asking to post this: Hi ive found a bug in the api system but i can't post on the forum. If i share the info with you could you post it or get it to the correct location? file: system/Dispatcher/Api.php function: _setPath() protected function _setPath() { /* Decode URL */ if (\IPS\Settings::i()->use_friendly_urls && \IPS\Settings::i()->htaccess_mod_rewrite && mb_substr(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_PATH], -14) !== '/api/index.php') { /* We are using Mod Rewrite URLs, so look in the path */ $this->path = mb_substr(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_PATH], mb_strpos(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_PATH], '/api/') + 5); /* nginx won't convert the 'fake' query string to $_GET params, so do this now */ if (!empty(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_QUERY])) { parse_str(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_QUERY], $params); foreach ($params as $k => $v) { if (!isset(\IPS\Request::i()->$k)) { \IPS\Request::i()->$k = $v; } } } } else { $this->path = mb_substr(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_PATH], mb_strpos(\IPS\Request::i()->url()->data[\IPS\Http\Url::COMPONENT_PATH], '/api/') + 5); /* However, if we passed any actual query string arguments, we need to strip those */ if (mb_strpos($this->path, '?') !== false) { $this->path = mb_substr($this->path, 0, mb_strpos($this->path, '?')); } } }